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.
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.