In ESLint 9 the ignore is set in the config and not inherited by other configs.
This poses an issue when a second config wants to use a rule from the first config if the second config includes files that the first config ignored. A solution could have been to load the plugin in both the first and second config – but every plugin name is only allowed to be referenced once, so one has to either opt to load it oneself with a new name and then have entirely new rules, or opt for the same name to be able to override the rules, but then run the risk of a mismatching ignore making that plugin not always be loaded.
Hence why we currently use the config() command from typescript-eslint to merge our ignore into all the rules:
|
const resolved = config({ |
|
...resolvedGlobals && { |
|
languageOptions: { |
|
globals: resolvedGlobals, |
|
}, |
|
}, |
|
ignores, |
|
extends: [ |
|
base, |
|
modernization, |
|
...styleConfigs, |
|
], |
|
}) |
But there's a catch with that:
Any config that wants to extend our config and modify or disable rules then needs to try and match our ignores, or else run into errors where the rule they are referring is not loaded.
I see two possible solutions:
- Always load plugins in a separate config that has no
ignore, making them globally available
- Expose the default ignores so that a config extending this config can be sure to use the very same ignore and not get a mismatch
I'm myself torn a bit on this. Loading all the plugins separately feels like a bit of a hack. Exposing the ignores and relying on people using that across the board also feels a bit so-so though.
Ran into this with my own superset that I'm currently adapting to neostandard, and with 0.6.0 it started complaining about not finding rules and I quickly realized that was because of #26 / #29 where we added default ignores, as my modifications are of course then not adding the very same ignores
In ESLint 9 the
ignoreis set in the config and not inherited by other configs.This poses an issue when a second config wants to use a rule from the first config if the second config includes files that the first config ignored. A solution could have been to load the plugin in both the first and second config – but every plugin name is only allowed to be referenced once, so one has to either opt to load it oneself with a new name and then have entirely new rules, or opt for the same name to be able to override the rules, but then run the risk of a mismatching ignore making that plugin not always be loaded.
Hence why we currently use the
config()command fromtypescript-eslintto merge our ignore into all the rules:neostandard/lib/main.js
Lines 78 to 90 in 6443327
But there's a catch with that:
Any config that wants to extend our config and modify or disable rules then needs to try and match our ignores, or else run into errors where the rule they are referring is not loaded.
I see two possible solutions:
ignore, making them globally availableI'm myself torn a bit on this. Loading all the plugins separately feels like a bit of a hack. Exposing the ignores and relying on people using that across the board also feels a bit so-so though.
Ran into this with my own superset that I'm currently adapting to neostandard, and with
0.6.0it started complaining about not finding rules and I quickly realized that was because of #26 / #29 where we added default ignores, as my modifications are of course then not adding the very same ignores