Extending ESLint is not supporting overrides
See original GitHub issueExtending ESLint got introduced originally in https://github.com/facebook/create-react-app/pull/7036 by @mrmckeb. It’s stated that this is limited currently to users configuring their ESLint in package.json:
- this ain’t quite true - because used
eslintCli.getConfigForFile
is not limited to package.json configs - there is no such mention in the docs - not a biggie but brought a little bit of confusion for me.
What is actually stated in the docs and what doesn’t actually hold true is that overrides
can be used to support TS rules etc (there is example of that).
This is not quite true, because whatever config gets loaded & resolved through that eslintCli.getConfigForFile
call (with paths.appIndexJs
as argument) gets set as “global” config for the whole eslint-loader.
So depending on what paths.appIndexJs
is we either can get:
- all TS-related rules being applied to ALL files (including JS) - when
paths.appIndexJs
is TS - no TS rules are applied at all - when
paths.appIndexJs
is JS
For this to work correctly it would be the easiest to allow ESLint to load configs on its own - without passing explicit single config to the eslint-loader.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:13
- Comments:12 (9 by maintainers)
@Andarist, sorry I think we were confused about what you were reporting.
I’ve managed to reproduce now and understand. Sorry for the inconvenience.
So, in short:
undefined
tobaseConfig
whenprocess.env.EXTEND_ESLINT === 'true'
.useEslintrc: false
touseEslintrc: process.env.EXTEND_ESLINT === 'true'
.How do these changes sound to everyone? I’ve tested them by modifying the Webpack config (in
node_modules
directly) - if others can do the same and report back, I can make the change this weekend.Hi @Andarist. Sorry this fell through the cracks. Let me try to address your comments:
Agreed. This should be clarified in the docs.
Yeah this should be explicitly stated in the language above that example.
Can you confirm this? I seem to remember when testing this that
getConfigForFile()
resolves the entire configuration (both TS, and JS) irrespective of the file extension. That would be the intent anyways so that we support mixed JS/TS code bases.Thanks for bringing this up. We’d gladly accept PRs to improve the documentation for points you raised.