Gradually Reduce the Number of ESLint Problems in Your Codebase

John Karahalis
Jul 23, 2020 · 3 min read

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: 57

FAIL: Number of ESLint problems > max
NOTE: Recent changes may have introduced new ESLint problems

or:

Running…

Max ESLint problems: 50
Num ESLint problems: 48

PASS: 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 may be a bit more error-prone and it may not be updated in the future, but in some ways I do 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.

Reflections

Thoughts on software development

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store