docs: Give advice on when to use warn #16753
Conversation
eslint-github-bot
bot
added
triage
|
|
✅ Deploy Preview for docs-eslint ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
| @@ -20,6 +20,8 @@ To change a rule's severity, set the rule ID equal to one of these values: | |||
| * `"warn"` or `1` - turn the rule on as a warning (doesn't affect exit code) | |||
| * `"error"` or `2` - turn the rule on as an error (exit code is 1 when triggered) | |||
|
|
|||
| The `"warn"` severity is meant to be used as a temporary measure. It can be used to enable a rule so that new reported issues can be addressed, without breaking the build due to existing ones. It is recommended to keep the number of these issues low so that new issues get more easily noticed and don't get ignored. | |||
There was a problem hiding this comment.
I think we haven't decided yet whether this should be the only advice for using warnings: #16696
There was a problem hiding this comment.
Ah I hadn't seen that issue. Thanks.
There was a problem hiding this comment.
I feel we can add usually here to address that this is not with every case but most of the cases.
| The `"warn"` severity is meant to be used as a temporary measure. It can be used to enable a rule so that new reported issues can be addressed, without breaking the build due to existing ones. It is recommended to keep the number of these issues low so that new issues get more easily noticed and don't get ignored. | |
| The `"warn"` severity is usually meant to be used as a temporary measure. It can be used to enable a rule so that newly reported issues can be addressed, without breaking the build due to existing ones. It is recommended to keep the number of these issues low so that new issues get more easily noticed and don't get ignored. |
There was a problem hiding this comment.
I'm fine with that, but then I think we should also indicate the other potential uses (just like @bmish said in a comment below)
There was a problem hiding this comment.
Let's not make this change piece-by-piece. I'll take a stab at writing up what I think is the best advice for using "warn".
|
I'm in favor of mentioning several potential/common use cases for warnings like this, as well as hinting at potential drawbacks of warnings like becoming noisy and easily ignored. |
snitin315
added
evaluating
|
Hi everyone, it looks like we lost track of this pull request. Please review and see what the next steps are. This pull request will auto-close in 7 days without an update. |
|
We have another PR that will close this one when merged: #16882 |
eslint-github-bot
bot
added
the
archived due to age
Prerequisites checklist
What is the purpose of this pull request? (put an "X" next to an item)
[X] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofix to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:
What changes did you make? (Give an overview)
I added an explanation of when to use the
"warn"severity, as I often feel like it's being misused and misunderstood. I asked what they were used for in this Twitter thread and @nzakas repliedwhich I used as the basis of the explanation.
Is there anything you'd like reviewers to focus on?
I have been using and contributing to ESLint and linters for years, and had never known that this was the intent behind them. I imagine this will actually surprise people. I for a long time thought it was about more or less important rules.
I don't necessarily agree that warnings are a good use for this considering that it will easily lead a large wall of errors, which is why I have added some advice on keeping the number of these issues low.
I think it's important to give good advice here so I'm open to suggestions to improve the message.