Meet my new codemod, ignore-lint-errors. It helps us ignore lint errors from eslint, stylelint, and typescript (glint for Ember projects).
A. Why should we ignore errors
In large production projects, ignoring lint errors for existing code is the most pragmatic, quickest approach to complete these tasks:
- Introduce a new lint rule.
- Update a linter to the next minor or major version.
- Migrate code to a different format, e.g. convert
*.{gjs,js}(JavaScript) to*.{gts,ts}(TypeScript).
For the sake of reducing noise, some prefer disabling linting for the entire file. They do so by adding a global directive (e.g. eslint-disable) or creating a special file to "suppress" files with many errors.
Instead, ignore-lint-errors takes the honest approach: It adds a local directive (e.g. eslint-disable-next-line) for every line that has an error. This way, we can easily see and show others (including non-engineers and AIs),
- How bad our code is to increase the urgency to fix issues. The number of local ignores (1 per line) will always estimate the actual number of errors better than the number of global ignores (1 per file).
- Which parts of our code are good and should be replicated, and which parts are bad and to be avoided. When there is a global ignore, a linter won't check the file for the given rule(s).
B. How to use ignore-lint-errors
1. Run codemod.
cd <path/to/your/project>
pnpx ignore-lint-errors --linter eslint
2. Fix formatting.
# Run prettier
pnpm prettier . --write
To speed things up, the codemod uses eslint's multithreading and allows you to specify which files to consider. For more information, see Usage > Arguments.
Top comments (0)