stylelint-config-standard: All rules have default "error" severity

Telling the users visually which rule violations will actually break their code versus which rule violations are purely stylistic errors

That’s one use of the severity levels, but it’s not the only one. As an example, this config currently works perfectly for the following use case:

“I want my CI to fail on any stylistic errors (along with errors caught by the likes of string-no-newline and color-no-invalid-hex, and along with subtle mistakes caught by the likes of declaration-block-no-ignored-properties and declaration-block-no-shorthand-property-overrides) because I only want clean code committed to the project repo. However, I don’t want the CI to fail when the linter detects someone has used an unsupported browser feature.”

And as a config:

// .stylelintrc
{ 
  "extends": "stylelint-config-standard"
  "rules" {
    "no-unsupported-browser-features": [ true, { "severity": "warning" }]
   }
}

Which, incidentally, is how the team I’m with at the moment uses stylelint 😃

So, the question we’re asking is… which use case is better to support out-of-the-box?

Additionally, there are over 130 diverse rules in stylelint. Rules that can’t be neatly categorised into either “break your code” or “stylistic” ones (e.g. selector-class-pattern, unit-blacklist etc…). As such, this config was designed to provide a foundation to get started with stylelint and it has been designed to be built on.

Your suggestion is very valid though and provides a great opportunity to revisit/clarify the role of this config.

I don’t think there’s a clear cut correct answer here. Is there a clear benefit to severity levels in stylelint? Yes, absolutely. Is there a clear benefit to changing how rules are classified within this particular config? Umm, I’m not sure. I think we’ll need to think carefully about that 😃

Now that I see the defaultSeverity idea in a config, I think it’s probably worth looking into! It might actually be fairly trivial to implement, and @thomas-darling is certainly right that it would make things easier for him and people with similar warning-vs-error preferences.

Sorry to revive this one, davidtheclark, but I’m with @jeddy3 on this - flexibility would be nice 😃 Linting should generally produce only warnings, and errors should be reserved for issues where the code cannot possibly be correct. Just because someone put extra whitespace somewhere, it does not mean my code is any less correct, and it should not prevent my critical hotfix from being built and deployed. And I don’t buy the argument that warnings would slip through the cracks - you’ll see them every time you lint your codebase and in every CI build report. It’s then a team decision how serious you are about cleaning those up, and when to do so.

I understand that some of this may be subjective, but if you won’t provide sensible defaults, I would very much appreciate at least an option to change the default severity to warning, so I don’t have to set that for (almost) every single rule - instead, we can selectively promote the rules we feel represent actual errors. This is how linting works almost everywhere else 😃

Sorry to revive this one, @controversial, but I’m with @jeddy3 on this 😃

I’m a bit confused. Did you get those names the wrong way around? I was in favour of keeping things the way they are because deciding on a per-rule basis is too subjective.

If @jeddy3 wants it, @jeddy3 gets it 😃

Ha 😃 I’m not in favour of maintaining another config. A suggestion of a second config might be moot though if…

so having the option to set the default severity would be much appreciated.

I can see how such a option would reduce the verbosity of your configuration object. There could be a default severity setting in the configuration object, and then the severity secondary option could be used to explicitly set something other on a per-rule basis e.g.

{
  extends: "stylelint-config-standard",
  defaultSeverity: "warning"
  rules: {
    "color-no-invalid-hex": [ true, { severity: "error" } ]
  }
}

However, I’m not sure how technical feasible such an option will be. Please consider creating an issue in the main stylelint repo and investigating the feasibility of adding this option (via a Pull Request etc), as this is something that I doubt the core team will have time to spend on as it’s a nice-to-have and there’s a growing list of other issues.

Trust me, I’m not a fan of unresolved warnings myself, and we will certainly fail on some of them 😃 But each team has their own way of dealing with those things, and I think it’s only fair that the tools we use respect that. In this case, the syntax for setting the severity for each individual rule makes the configuration really verbose and hard to maintain, so having the option to set the default severity would be much appreciated.

Oh, and you’re right that most open source projects see all linting issues as errors, but remember that not everything is open source, with many contributors from all over the world 😉 In our team, you can be pretty sure someone will walk over and poke you pretty hard if you don’t resolve your warnings - but you would be poked much harder if the site was down and your hotfix got delayed because of some insignificant whitespace 😉

Oh, and just noticed this is in the stylelint-config-standard repository - I guess I see this as more of a feature request for stylelint itself, as we maintain our own rule configuration 😃

Yeah, that’s my suggestion.

I think there’s a definite benefit to the user. For things like the Atom package, it’s decidedly more useful to have the distinction. Telling the users visually which rule violations will actually break their code versus which rule violations are purely stylistic errors is way more useful.

What reasons can you think of why not having default severities is good or beneficial?