feat: warnings in eslint #366
Conversation
| @@ -1,5 +1,3 @@ | |||
| const SEVERITY = 2 | |||
There was a problem hiding this comment.
This was always a useless magic number, swapping it out for a sane string.
| // unignore implicit rules about what types of files can be linted | ||
| ignorePatterns: ['!.*'], |
There was a problem hiding this comment.
By default ESLint ignores all dot-files and dot-folders and node_modules/.
We lint our configuration files, so the former implicit ignore rule needs to be disabled. This does it for the common configuration, so it is still possible to override from an config that extends this one if need be.
We agree with the rule about not linting node_modules.
Allow d2-style to print warnings from ESLint.
Set a zero tolerance on warnings by making ESLint exit with a non-zero
code if there are any warnings.
A developer is required to either:
a) fix the warning
b) explicitly mark the code that triggered the warning with an
eslint-disable comment.
A good disable directive uses the comment syntax for ESLint:
/* eslint-disable [rule] -- [comment] */
E.g.
/* eslint-disable-next-line no-console -- we need to log here */
| @@ -9,8 +9,8 @@ exports.eslint = ({ files = [], apply = false, config }) => { | |||
| '--no-color', | |||
| '--report-unused-disable-directives', | |||
| '--ignore', | |||
| '--quiet', | |||
There was a problem hiding this comment.
This made ESLint ignore all warnings and not print them.
| '--format=unix', | ||
| '--max-warnings=0', |
There was a problem hiding this comment.
This makes ESLint exit with a non-zero exit code when there are warnings, which will make e.g. CI and Git hook fail the lint job if there are warnings.
There was a problem hiding this comment.
We could make this configurable by a flag that flips between 0 (no warnings) and -1 (infinite warnings) through e.g. --[no-]warnings-allowed.
I don't see the point of doing so?
There was a problem hiding this comment.
Another option is to enable/disable the --quiet flag through e.g. --[no-]warn with --no-warn being the default.
That means that if a user wants to see the warnings, she would run d2-style js check --warn. It would be useful for seeing what warnings there are, but wouldn't force any actions to be taken.
It gives us the ability to introduce new rules as warnings, and then upgrade them to errors when we want to.
We could call the flag something like --future-errors.
Allow d2-style to print warnings from ESLint.
Set a zero tolerance on warnings by making ESLint exit with a non-zero
code if there are any warnings.
A developer is required to either:
a) fix the warning
b) explicitly mark the code that triggered the warning with an
eslint-disable comment.
A good disable directive uses the comment syntax for ESLint:
E.g.