The most underutilized linters feature: severity levels

— 3 minute read

Linters have many rules. Not all rules are equally helpful. Some rules prevent bugs in the code, some enforce good practices, some enforce code style. Our configured linters usually are very vocal about “errors” in our code, while our code is perfectly working. Just its style doesn't follow specified guidelines. It results in constant unproductive noise from linters. Didn't add a space — error. Added extra empty line — error. Have console.log during debugging — error. Didn't sort something in any particular way — error. This is ridiculous! These rules do not solve problems at the moment you're changing code. These rules are meant for keeping the codebase clean and tidy when you're done changing code, not while you're actively changing it.

Would it be great if linters did bother developers only with real problems during development? There is a solution for this built-in into every linter for a long time: severity levels! Specifically — “warning” level. It is rarely used. In most configs I've seen, almost every rule is enabled with the highest severity level — “error”.

Rules that prevent errors, should be enabled with the highest severity level. Because it's the main purpose of linters: prevent errors and reduce time finding bugs. All other rules should be as least distracting as possible.

Use the “error” severity level, when fixing violation will change how your code works. Use the “warning” severity level, when fixing violation will not change how your code works. If the linter rule has an auto-fix — use the “warning” level. There are many rules, though, which doesn't have auto-fix, but should be at “warning” level, e. g. no-unused-vars.

stylelint and ESLint process won't fail (e. g. CI build), if the linting result has “warning” level violations only. To make them work the same way as if the result had “error” level use --max-warnings 0 CLI parameter (both for stylelint and ESLint). This will fail the process if there are any violations.

Another handy CLI parameter for this setup is --quiet (both for stylelint and ESLint). It will ignore all violations with the ”warning” level. It is convenient to enable in an editor. E. g. for stylelint and ESLint VS Code plugins it could be enabled like this:

{
"stylelint.configOverrides": {
"quiet": true
},
"eslint.quiet": true
}

I use the “warning” severity level in my stylelint config and ESLint config for more than half a year, and it's being great!