eslint: Help us know when we have conflicting rules: 10 passes should throw an error
ESLint version
v8.5.0
What problem do you want to solve?
Between eslint, prettier, import, and @typescript/eslint, it’s really easy to accidentally include rules with fixes that overlap or conflict with other rules we have enabled.
This can cause eslint --fix significantly longer to run as keeps re-fixing the same files up to 10 times.
It might also means users are not necessarily getting the output they desired if the wrong rule is the last to run in that loop of 10 attempts.
What do you think is the correct solution?
If eslint --fix needs to do 10 passes, then throw error and say which plugins are possibly conflicting.
- Baseline: Throw an error and say which plugins are possibly conflicting.
- Even nicer: Show the rule names and their options.
- Even more helpful: Show the HTML after each pass so we can visually see what’s going on.
- Super helpful but not necessary: Show the differences as a diff.
- Might be nice: In the fix loops, cache the previous versions, so we can detect as soon as we see a repeating pattern.
Participation
- I am willing to submit a pull request for this change.
Additional comments
This is the code where I am seeing the 10 passes not be treated as an error: https://github.com/eslint/eslint/blob/main/lib/linter/linter.js#L2079-L2105
Also, I’m not sure if this is considered a breaking change, so it might need to wait for v9. Maybe a compromise is to warn in v8 but throw an error in v9?
I’ve made contributions to open source projects, but not eslint. I’m not sure if this is a good first issue, but I’m happy to try.
About this issue
- Original URL
- State: open
- Created 9 months ago
- Comments: 21 (18 by maintainers)
@DMartens I’m sorry, I was actually addressing @mdjermanovic with my comment. I think your comment posted just before I hit the button. 😃
I don’t think a solution that requires constant updating of metadata is a good idea. We need something that works automatically.
Hi @nzakas - Here’s a working reproduction that you can test in your browser.
https://stackblitz.com/edit/node-ugx5i6?file=module.ts,.eslintrc.js,index.tsx
Run
yarn lintornpm run lintin the terminal to see the results.Results from terminal
Hi @nzakas, thanks for the quick response and helpful questions!
Culprit
The culprit when I created the issue was two conflicting rules both from the
importplugin, caused by a a bug withprefer-inline.The repo that I noticed the slow linting had this happen in about about 7000 files, and it was happening in nearly all of them (our React patterns monorepo).
Debugging the issue
I was using
DEBUG="eslint:linter"but the output was verbose for me, especially with that many files, so it was hard to notice the pattern of repeating passes. I stopped usingDEBUGand just added my own console logs that included the filename, which plugin caused thefix, and the changed code. TheDEBUGmade it easy to figure out where I should look to add my own console logs.What output would I expect?
Ideally, something like this, though the fix comparison might be impractical or need to be trimmed to make sure it’s readable.
Also, maybe it doesn’t need to throw a fatal error, but as a lint error, so this can be visible in IDE’s.