Plugin candidates for 8.0.0

[jeddy3]

There are over 170 rules in stylelint.

There are the 48 *-before, *-after and *-inside variants of the *-space-*, *-newline-* and *-unspaced-* rules.

There are the 11 *-empty-line-before and *-max-empty-line rules.

And there is the indentation rule. I think these rules work together to allow the enforcement of most whitespace code styles. More so than any CSS linter has done before.

Then there are:

• 10 *-case rules.
• 4 *-quotes rules.
• 4 number-* and length-* rules.
• 2 *-notation rules.
• 2 *-length rules.
• 2 *-no-redundant-* rules:
  • declaration-block-no-redundant-longhand-properties
  • shorthand-property-no-redundant-values
• no-eol-whitespace
• no-missing-end-of-source-newline

I think these 26 rules cover off most other code style requirements.

Next, there are 49 rules for (dis)allowing language constructs:

• 20 *-whitelist and *-blacklist rules.
• 19 applicable *-no-* rules:
  • 7 selector-no-* rules.
  • 2 *-no-important rules.
  • 2 color-no-* rules.
  • 5 *-no-vendor-prefix rules.
  • 3 *-no-empty rules discussed in Rule idea selector-pseudo-class-no-empty-parentheses #2047 (comment).
• 10 *-pattern rules.

I think the breadth of these rules is excellent and covers nearly all of the language constructs available in CSS.

There are these 4 additional limiting rules:

• declaration-block-single-line-max-declarations
• max-nesting-depth
• selector-max-compound-selectors
• selector-max-specificity

And these 5 rules that check valid but likely unintentional code:

• 3 *-duplicate-* rules:
  • declaration-block-no-duplicate-properties
  • font-family-no-duplicate-names
  • no-duplicate-selectors
• 2 "overrides"
  • declaration-block-no-shorthand-property-overrides
  • no-descending-specificity

I'm confident all the rules listed above adhere to the criteria (and therefore facilitate a sustainable core). Although, please do shout if you spot anything contentious in there!

Having identified the rules that match our criteria first, I was left with the following rules:

• block-no-single-line
• color-no-invalid-hex
• no-browser-hacks
• no-extra-semicolons
• no-indistinguishable-colors
• no-invalid-double-slash-comments
• no-unknown-animations
• no-unsupported-browser-features
• root-no-standard-properties
• selector-root-no-composition
• string-no-newline
• stylelint-disable-reason
• time-no-imperceptible

And the 7 other *-no-unknown rules.

I intend to break each into a separate issue so we can discuss its adherence to the criteria and whether it is better as a plugin. I hope to document where each rule does not meet the criteria, so that the process of discussing each rule is as least time consuming as possible for everyone else. As an example, the first rule, block-no-single-line, was made redundant by the block-*-brace-newline-* rules. Does this sound like a plan?

As I said in #2068 (comment), I think we have a much better understanding of plugins and rules now than we did six months ago and that 8.0.0 presents a great opportunity for us to build on that understanding to ensure stylelint excels in its approaching third year :)

[alexander-akait]

@jeddy3
Agree:

• color-no-invalid-hex - we are not a parser (validator)
• no-browser-hacks - sgtm for plugin
• no-invalid-double-slash-comments - we are not a parser (validator)
• no-unsupported-browser-features - sgtm for plugin
• string-no-newline - we are not a parser (validator)

Not agree:

• no-extra-semicolons why?
• stylelint-disable-reason why?

CSS does not stand still, and I see in the future that we have to consider a lot of things that come from cssnext not see anything wrong with these rules.

• root-no-standard-properties
• selector-root-no-composition

@jeddy3 i think we it would be much better than do in 9.0.0. In the new version we remove a set of rules and have to give people more plans to move to a new version, and the transfer rules will take time, we can not just pick up and remove the rule is, we have to move someone (or someone has to take responsibility for the transfer) rule(s). I agree that that part of the rules do not meet the criteria, I just suggest to make it more smoothly as possible for the community.

[alexander-akait]

@stylelint/core I would like to add to the above written, that most used scss, less and other preprocessors and postprocessors and all the support for it in the plugins are often not provided, virtually removing the rules, we will lose the opportunity to be responsible for a stable plugins, and it is a real hell. I almost could not make it work most of the available plugins. I can tell myself that I have to stop many projects to version 7, because I cannot afford to deprive themselves of the rules. Especially difficult is that we do not export many utilities that have written a very long time and decided to have most of the problems with non-standard syntax. We should think twice about whether to do it now, it might be worth it to postpone or reconsider a number of points for us. Otherwise, we will lose a number of community.

[davidtheclark]

@jeddy3 Opening separate issues sounds fine to me.

[ntwb]

I have concerns on removing a couple of these, but yes, lets discuss each them on separate issue👍

[jeddy3]

This has been broken into separate issues.