Should typescript-eslint switch its strict config from warnings to errors? #16512
Replies: 3 comments 4 replies
-
|
This is really up to you. Warnings were intended to be used temporarily. My belief is that using warnings long term results in people tuning them out as just console noise, so I don’t believe you are getting much benefit with long-term warnings. That said, warnings are a tool in the toolbox that you can use however you’d like. It’s hard to say in the abstract if it’s a good idea or not, so if you’d like to discuss a particular example it might help narrow the discussion. |
Beta Was this translation helpful? Give feedback.
-
Hmm, this is what I was hoping to switch away from. It's confusing to at least me -and I think much of the community- that the ESLint docs don't establish a precedent for how to use warnings. I strongly agree with your preference on using them temporarily 😄. Putting forward: would you accept an issue/PR adding the preference of using warnings to the docs? I.e. adding a warning callout after the list of rule severities on https://eslint.org/docs/latest/user-guide/configuring/rules#configuring-rules:
(is there a better place?)
Backing context on our Within the strict rules (as filtered on https://typescript-eslint.io/rules), For a while, we saw many users use warnings as an indication that a rule should ideally be treated but isn't necessary to fix. So we set all |
Beta Was this translation helpful? Give feedback.
-
|
I'd be supportive of adding a suggestion to the website about when to use Regarding bug vs. stylistic rules, I don't think |
Beta Was this translation helpful? Give feedback.
-
Interesting! My first reaction was that I don't want to add even more configs for people to use. My second was that it makes a lot of sense to separate them out. Once typescript-eslint/typescript-eslint#5251 lands we'll really only be increasing from 1 to 2 choices:
I also like the word stylistic because it's not the same as formatting. We aggressively recommend against formatting rules (in our definition, those that would conflict with formatters such as Prettier). Filed in typescript-eslint/typescript-eslint#5964. |
Beta Was this translation helpful? Give feedback.
-
|
My concern with updating the docs to be more explicit about recommendations for warnings is that I don't want people to think there is only one correct way to decide whether to use a warning or an error. While my original intention was for warnings to be temporary, I don't think that needs to be the case all the time. I'm doing more Rust programming now, and the compiler shows both errors, which are things that prevent the program from running, and warnings, which are things that aren't what are expected but don't prevent the program from running. If we were to map this onto ESLint, I'd say that warnings could be things that won't cause runtime errors while errors are things you should definitely address (and will block CI). In either case, I do thing shareable configs should start out with rules at the "error" severity if you believe it's important for people to follow. Circling back to the docs -- I'm open to a PR so long as we aren't overly prescriptive. I'd rather give a few different scenarios for when warnings are useful rather than nailing down on one. |
Beta Was this translation helpful? Give feedback.
-
|
Personally, I would advocate switching from |
Beta Was this translation helpful? Give feedback.
-
|
Closing this out: yes, we did in v6. Thanks! https://typescript-eslint.io/blog/announcing-typescript-eslint-v6/ |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
https://twitter.com/slicknet/status/1579527957491564544:
The
@typescript-eslint/eslint-pluginstrictconfig uses warnings for all its rules. We set it up that way because those strict rules tend to be more opinionated than what most developers want.What is the recommendation from the ESLint team on this?
I see also #16365 is in-progress. Is this discussion and/or backing "don't keep warnings long-term" preference something that would fit into that project's scope?
Beta Was this translation helpful? Give feedback.
All reactions