Default Severity

The version of ESLint you are using. 7.28.0

The problem you want to solve. Now both real code errors and ESLint errors appear at the same level in IDEs with red squiggles. I can see an option to change all error severity to warn. It would be nice to have yellow squiggles on ESLint ones (Now we have to manually list every rule and change its severity to warn)

Your take on the correct solution to the problem.

{
  severity: 'warn',
  ...
}

[mdjermanovic]

Now both real code errors and ESLint errors appear at the same level in IDEs with red squiggles. I can see an option to change all error severity to warn. It would be nice to have yellow squiggles on ESLint ones (Now we have to manually list every rule and change its severity to warn)

If the goal is to differentiate errors coming from ESLint and those from other sources in IDEs, that sounds like something IDE-ESLint integrations should do.

vscode-eslint provides this feature with eslint.rules.customizations option:

• eslint.rules.customizations (since 2.1.20): force rules to report a different severity within VS Code compared to the project’s true ESLint configuration. Contains two properties:

  • "rule": Select on rules with names that match, factoring in asterisks as wildcards: { "rule": "no-*", "severity": "warn" }
    • Prefix the name with a "!" to target all rules that don’t match the name: { "rule": "!no-*", "severity": "info" }
  • "severity": Sets a new severity for matched rule(s), "downgrade"s them to a lower severity, "upgrade"s them to a higher severity, or "default"s them to their original severity

  In this example, all rules are overridden to warnings:

  "eslint.rules.customizations": [
    { "rule": "*", "severity": "warn" }
  ]
  

  In this example, no- rules are informative, other rules are downgraded, and "radix" is reset to default:

  "eslint.rules.customizations": [
    { "rule": "no-*", "severity": "info" },
    { "rule": "!no-*", "severity": "downgrade" },
    { "rule": "radix", "severity": "default" }
  ]
  

[bmish]

Just trying to make sure I understand this proposal. I’m assuming the current proposal is:

• Shareable configs can set 'some-cool-rule': 'default'
• End-users can set defaultSeverity: 'error' / defaultSeverity: 'warn' to choose the severity of any rule that specifies default

So far, I have the following concerns:

1. Wouldn’t it create a huge amount of work for shareable configs to have to update all of their rules to use default instead of error/warn? This proposal seems like it’s solving the problem by pushing work onto all of the thousands of shareable ESLint configs, instead of the alternative solution of just letting the individual end-user apply severity overrides when needed.
2. How would shareable configs decide when default is appropriate to use vs. more specific settings like error/warn? Seems like there would inevitably be disputes here, as some config owners would still want to choose specific severities, but some end-users might want them to specify default.
3. What about shareable configs that never get around to adopting default? Seems like we would still need to have the severity override solution given that we’d never get to full adoption of default anyway.
4. If we end up in a situation where configs just use default for everything, then that potentially conveys less information than today where config owners can use error / warn to distinguish stronger vs. weaker rule suggestions. Not the end of the world, but it’s another downside to the severity override solution where end-users could override error / warn rules differently.

So a severity override solution that end-users could configure as needed makes much more sense to me at this point than an ecosystem-wide default severity migration.