Gradually reduce the number of ESLint problems in your codebase
I have come to appreciate ESLint very much in recent years. A robust and reliable JavaScript linter, ESLint can be used not only to detect common programming mistakes, but also to enforce a consistent code style. Its utility cannot be overstated. Your teammates and your future self will thank you for using it.
I recommend that ESLint be enabled before any code is written, but what about existing projects? A developer who runs ESLint on an existing codebase will certainly be overwhelmed; it will warn about scores of issues which had not been noticed until that point. Is there any way to gradually adopt its recommendations? More importantly, is there any way to prevent the number of problems from growing? Running the linter on CI is no solution. It will simply fail and annoy others.
I considered this dilemma when I began working on GLAM, a self-service product metrics dashboard from the wonderful Hamilton Ulmer. GLAM is not currently easy to install for external use, but it’s gaining popularity within Mozilla.
For a while, I would manually run ESLint against pull requests and let my teammates know when they introduced new problems. I would document exactly which problems were added and exactly which lines they appeared on. That worked, but it was a manual and slow process. My teammates might not know about new ESLint problems until I got around to reviewing the code.
To address the weaknesses of this manual solution, I wrote a little Node script which warns if the number of ESLint problems exceeds some configured limit. If the number of problems is lower, the script encourages the developer to lower the configured limit to prevent regressions. Simple, but effective.
Run the script with node eslint-health. Upon doing so, one will see:
Running…
Max ESLint problems: 50
Num ESLint problems: 57FAIL: Number of ESLint problems > max
NOTE: Recent changes may have introduced new ESLint problems
or:
Running…
Max ESLint problems: 50
Num ESLint problems: 48PASS: Number of ESLint problems <= max
NOTE: Considering lowering config.maxProblems to 48 in the eslint-health script to prevent regressions
I know what you’re thinking: it would be even better for developers to highlight ESLint problems in their editors. I agree, but when there is such a large backlog of ESLint problems, developers may habitually ignore the problems they see. Plus, nothing beats blocking merge with this kind of check, assuming the script is run automatically on CI.
I think this will motivate our team to gradually reduce our number of ESLint problems to zero. At that point, the script can go away, having served its purpose. It’s working so far: we reduced our limit twice in just the past 24 hours.
If you prefer using a Bash script, I actually wrote one before re-writing the logic in Node. It’s more likely to break because it does not have direct access to the ESLint API, but I find it to be more readable.
Please feel free to use either of these scripts wherever you think they would be helpful; all of my public Gists are shared under the terms of the the MIT License.
