feat(linter)!: support plugins in oxlint config files

[DonIsaac]

Closes #5046
This PR migrates the linter crate and oxlint app to use the new LinterBuilder API. This PR has the following effects:

1. plugins in oxlint config files are now supported
2. irons out weirdness when using CLI args and config files together. CLI args are now always applied on top of config file settings, overriding them.

Breaking Changes

Before, config files would override rules set in CLI arguments. For example, running this command:

oxlint -A correctness -c oxlintrc.json

With this config file

// oxlintrc.json
{
  "rules": {
    "no-const-assign": "error"
  }
}

Would result in a single rule, no-const-assign being turned on at an error level with all other rules disabled (i.e. set to "allow").

Now, CLI arguments will override config files. That same command with the same config file will result with all rules being disabled.

Details

For a more in-depth explanation, assume we are running the below command using the oxlintrc.json file above:

oxlint -A all -W correctness -A all -W suspicious -c oxlintrc.json

Before

Note: GitHub doesn't seem to like deeply nested lists. Apologies for the formatting.

Here was the config resolution process before this PR:

Before Steps

1. Start with a default set of filters (["correctness", "warn"]) if no filters were passed to the CLI. Since some were, the filter list starts out empty.
2. Apply each filter taken from the CLI from left to right. When a filter allows a rule or category, it clears the configured set of rules. So applying those filters looks like this
   a. start with an empty list []
   b. ("all", "allow") -> []
   c. ("correctness", "warn") -> [ <correctness rules> ]
   d. ("all", "allow") -> []
   e. ("suspicious", "warn") -> [ <suspicious rules> ]. This is the final rule set for this step
3. Apply overrides from oxlintrc.json. This is where things get a little funky, as mentioned in point 2 of what this PR does. At this point, all rules in the rules list are only from the CLI.
   a. If a rule is only set in the CLI and is not present in the config file, there's no effect
   b. If a rule is in the config file but not the CLI, it gets inserted into the list.
   c. If a rule is already in the list and in the config file
   i. If the rule is only present once (e.g. "no-loss-of-precision": "error"), unconditionally override whatever was in the CLI with what was set in the config file
   ii. If the rule is present twice (e.g. "no-loss-of-precision": "off", "@typescript-eslint/no-loss-of-precision": "error"),
   a. if all rules in the config file are set to allow, then turn the rule off
   b. If one of them is warn or deny, then update the currently-set rule's config object, but leave its severity alone.

So, for our example, the final rule set would be [<all suspicious rules: "warn">, no-const-assign: "error"]

After

Rule filters were completely re-worked in a previous PR. Now, lint filters aren't kept on hand-only the rule list is.

After Steps

1. Start with the default rule set, which is all correctness rules for all enabled plugins ([<all correctness rules: "warn">])
2. Apply configuration from oxlintrc.json first.
   a. If the rule is warn/deny exists in the list already, update its severity and config object. If it's not in the list, add it.
   b. If the rule is set to allow, remove it from the list.

The list is now [<all correctness rules except no-const-assign: "warn">, no-const-assign: "error"].

3. Apply each filter taken from the CLI from left to right. This works the same way as before. So, after they're applied, the list is now [<suspicous rules: "warn">]

[graphite-app]

Your org has enabled the Graphite merge queue for merging into main

Add the label “0-merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “hotfix” to add to the merge queue as a hot fix.

You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link.

[DonIsaac]

• refactor(linter): remove OxlintOptions #6098
• feat(linter)!: support plugins in oxlint config files #6088 👈
• fix(linter): rule and generic filters do not re-configure existing rules #6087
• fix(linter): disable all rules in a plugin when that plugin gets turned off #6086
• fix(linter): category filters not re-configuring already-enabled rules #6085
• test(linter): add OxlintRules::override_rules tests #6081
• test(linter): add filter parsing test cases #6080
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @DonIsaac and the rest of your teammates on Graphite

[codspeed-hq]

CodSpeed Performance Report

Merging #6088 will degrade performances by 3.79%

_{Comparing don/09-26-feat_linter_support_plugins_in_oxlint_config_files (8ea51af) with main (2090fce)}

Summary

❌ 1 regressions
✅ 28 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	main	don/09-26-feat_linter_support_plugins_in_oxlint_config_files	Change
❌	linter[checker.ts]	2.4 s	2.5 s	-3.79%

[DonIsaac]

CodSpeed Performance Report

Merging #6088 will degrade performances by 3.72%

Comparing don/09-26-feat_linter_support_plugins_in_oxlint_config_files (d08cf2c) with don/09-26-fix_linter_rule_and_generic_filters_do_not_re-configure_existing_rules (6edcd5c)

Summary

❌ 1 regressions ✅ 28 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

Benchmark don/09-26-fix_linter_rule_and_generic_filters_do_not_re-configure_existing_rules don/09-26-feat_linter_support_plugins_in_oxlint_config_files Change
❌ linter[checker.ts] 2.4 s 2.5 s -3.72%

It looks like some rules are not running that weren't before. This either means this PR fixed a bug that caused them not to run, or ...run() is now taking longer, so those spans are showing up?

TBH I'm not quite sure what to make of this.

[Boshen]

I suggest manually test this setup on some of the oxlint-ecosystem-ci projects and see if the rule numbers match.

[DonIsaac]

We'll need to allow for category-based rule configuration in oxlintrc.json files before our next release in order for this PR to be viable. Otherwise there's no way to get that broad-level configuration, followed by rule-by-rule tweaking, that people were getting before using the CLI. Working on a PR now.

[DonIsaac]

Waiting on #6120 to land before merging this.