fix(linter)!: override plugins array when passed in config file

[camchenry]

• fixes linter: default plugins are always enabled in config file #6896

When the plugins config property is specified, it will overwrite the default plugins array. This allows the plugins list to be easily customized and allows for disabling default plugins at the same time as enabling non-default ones.

• example: { "plugins": [] } will enable no plugins.
• example: { } will enable default plugins.
• example: { "plugins": ["typescript", "import"] } will enable only the import and typescript plugins.

[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.

[camchenry]

• fix(linter)!: override plugins array when passed in config file #7303 👈 (View in Graphite)
• main

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

[codspeed-hq]

CodSpeed Performance Report

Merging #7303 will create unknown performance changes

_{Comparing 11-15-fix_linter_override_plugins_array_when_passed_in_config_file (20d9080) with main (d135d3e)}

Summary

🆕 30 new benchmarks

Benchmarks breakdown

	Benchmark	main	11-15-fix_linter_override_plugins_array_when_passed_in_config_file	Change
🆕	codegen[checker.ts]	N/A	24.6 ms	N/A
🆕	codegen_sourcemap[checker.ts]	N/A	77.4 ms	N/A
🆕	isolated-declarations[vue-id.ts]	N/A	397.5 ms	N/A
🆕	lexer[RadixUIAdoptionSection.jsx]	N/A	24 µs	N/A
🆕	lexer[antd.js]	N/A	22.3 ms	N/A
🆕	lexer[cal.com.tsx]	N/A	5.5 ms	N/A
🆕	lexer[checker.ts]	N/A	13.3 ms	N/A
🆕	lexer[pdf.mjs]	N/A	3.6 ms	N/A
🆕	linter[RadixUIAdoptionSection.jsx]	N/A	2.4 ms	N/A
🆕	linter[cal.com.tsx]	N/A	1.1 s	N/A
🆕	linter[checker.ts]	N/A	2.5 s	N/A
🆕	minifier[antd.js]	N/A	437.2 ms	N/A
🆕	minifier[react.development.js]	N/A	2.9 ms	N/A
🆕	minifier[typescript.js]	N/A	545.4 ms	N/A
🆕	parser[RadixUIAdoptionSection.jsx]	N/A	77.7 µs	N/A
🆕	parser[antd.js]	N/A	106.5 ms	N/A
🆕	parser[cal.com.tsx]	N/A	24.6 ms	N/A
🆕	parser[checker.ts]	N/A	53.5 ms	N/A
🆕	parser[pdf.mjs]	N/A	17.4 ms	N/A
🆕	semantic[RadixUIAdoptionSection.jsx]	N/A	97.8 µs	N/A
...	...	...	...	...

ℹ️ Only the first 20 benchmarks are displayed. Go to the app to view all benchmarks.

[Sysix]

Thanks for working on this. ❤️ With the new overrides property there is a new discussion to make :)

{
  plugins: ["typescript"],
  overrides: [
    {
        files: ["*.tsx"],
        plugins: ["react"]
    }
  ]
}

with this config I expect to enable ts and react plugin for .tsx files. Maybe someone other expect it differently :)

[camc314]

if i specify an empty array. but have a rule in the rules list that uses a plugin does it get reported as an unknown rule?

[Sysix]

That is a also a topic 👍 Let not block this PR, perrsonally im fine at the moment.

if i specify an empty array. but have a rule in the rules list that uses a plugin does it get reported as an unknown rule?

existing rules in the project should always be known and can be enabled/disabled in the rules block.
plugins + categories enables the base rules, rules block should adjust the last needs.

That what I expect as a user, don't know what the core team says about it :)

[camchenry]

Thanks for working on this. ❤️ With the new overrides property there is a new discussion to make :)

{
  plugins: ["typescript"],
  overrides: [
    {
        files: ["*.tsx"],
        plugins: ["react"]
    }
  ]
}

with this config I expect to enable ts and react plugin for .tsx files. Maybe someone other expect it differently :)

Good point, I forgot to consider the overrides property here. I think that making the plugins array append when inside of overrides feels the most intuitive to me? I can update the tests and behavior accordingly.

if i specify an empty array. but have a rule in the rules list that uses a plugin does it get reported as an unknown rule?

Yes, I think this should report as an unknown/disabled rule warning. I can imagine a case where you remove a plugin that is no longer needed and want to be warned of config that is no longer useful. Or, like in the case above with overrides, you need to explicitly enable the plugin to use the rule.

[Sysix]

I think that making the plugins array append when inside of overrides feels the most intuitive to me?

Feels for me too, but I do not know how it is currently with categories.
When overrides really overrides and not append. I think my expection is wrong and we should keep it consistent.

[camchenry]

I checked the behavior with the legacy .eslintrc setup in ESLint, and it this config will append so that .ts files have the react and typescript plugins enabled:

{
  "plugins": ["@typescript-eslint"],
  "overrides": [
    {
      "files": ["*.ts", "*.tsx"],
      "plugins": ["react"]
    }
  ]
}

So, I think this is the way to go for compatibility. And specifying an empty array here does not disable all of the plugins.

[Boshen]

Merge activity

• Nov 16, 12:41 AM EST: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Nov 16, 12:41 AM EST: A user added this pull request to the Graphite merge queue.
• Nov 16, 1:00 AM EST: A user merged this pull request with the Graphite merge queue.