Hi HN! I built @runespoorstack/eslint-cli to solve the painful process of adding ESLint to existing projects or migrating to stricter ESLint rules.
The Problem: Adding ESLint to an existing codebase (or upgrading to stricter rules) typically means:
1) Thousands of errors to fix manually
2) Weeks of work while the team keeps adding new violations
3) Broken git blame history (every line now shows you as the author)
4) Getting assigned as reviewer on every future PR
5) Merge conflicts galore as you try to keep up with ongoing development
The Solution: Instead of the big-bang approach, this CLI enables smooth migration:
1) Temporarily disable ESLint on all files with violations: npx lintspoor disable
2) Set up prevention for new violations: pre-commit hooks that catch any new /* eslint-disable */ comments
3) Gradual cleanup: As developers touch files during normal work, they remove the disable comment and fix violations in that file
4) Zero disruption: Team continues working normally while codebase gradually becomes compliant
This works for:
1) Adding ESLint to legacy projects for the first time
2) Migrating to stricter rules (new plugins, configs, custom rules)
3) Adopting new linting standards without stopping development
The result? ESLint adoption becomes a pleasant, gradual process instead of a painful big-bang migration. No broken git history, no team disruption, and files get cleaner over time as part of natural development flow.
I like the spirit of this! Here’s what I would need (and have implemented in eslint)
- rule level migration. Full files is too coarse. Further, i dont want to punish eslint disables—some are correct and needed (react hooks, generic constraints, etc).
- …well actually, rule level migration is it i suppose, but all of the tooling to operate at that level (e.g. the disable CLI command)
We wrote to a report file and tracked it, ensuring maxWarnings for incrementally adopted rules didnt exceed their limit per file. Everyone got a a due date. If you changed file X, the due date was exceeded, and you still had warnings? Youd eventually fail CI
Hi HN! I built @runespoorstack/eslint-cli to solve the painful process of adding ESLint to existing projects or migrating to stricter ESLint rules.
The Problem: Adding ESLint to an existing codebase (or upgrading to stricter rules) typically means:
1) Thousands of errors to fix manually
2) Weeks of work while the team keeps adding new violations
3) Broken git blame history (every line now shows you as the author)
4) Getting assigned as reviewer on every future PR
5) Merge conflicts galore as you try to keep up with ongoing development
The Solution: Instead of the big-bang approach, this CLI enables smooth migration:
1) Temporarily disable ESLint on all files with violations: npx lintspoor disable
2) Set up prevention for new violations: pre-commit hooks that catch any new /* eslint-disable */ comments
3) Gradual cleanup: As developers touch files during normal work, they remove the disable comment and fix violations in that file
4) Zero disruption: Team continues working normally while codebase gradually becomes compliant
This works for:
1) Adding ESLint to legacy projects for the first time
2) Migrating to stricter rules (new plugins, configs, custom rules)
3) Adopting new linting standards without stopping development
The result? ESLint adoption becomes a pleasant, gradual process instead of a painful big-bang migration. No broken git history, no team disruption, and files get cleaner over time as part of natural development flow.
I like the spirit of this! Here’s what I would need (and have implemented in eslint)
- rule level migration. Full files is too coarse. Further, i dont want to punish eslint disables—some are correct and needed (react hooks, generic constraints, etc). - …well actually, rule level migration is it i suppose, but all of the tooling to operate at that level (e.g. the disable CLI command)
We wrote to a report file and tracked it, ensuring maxWarnings for incrementally adopted rules didnt exceed their limit per file. Everyone got a a due date. If you changed file X, the due date was exceeded, and you still had warnings? Youd eventually fail CI
What's the advantages over using bulk suppression in eslint (https://eslint.org/blog/2025/04/introducing-bulk-suppression...) or ignoring revisions in git blame (https://gist.github.com/kateinoigakukun/b0bc920e587851bfffa9...)?