Stylelint: Fix false positives for trailing combinator in selector-combinator-space-after

Created on 7 Feb 2020  路  3Comments  路  Source: stylelint/stylelint

Clearly describe the bug

This is valid SCSS:

.foo ~,
.bar {
  .baz {
    display: none;
  }
}

It will compile to the following CSS:

.foo ~ .baz,
.bar .baz {
  display: none;
}

However, stylelint is complaining about the first selector, because the _general sibling_ combinator, ~, is not followed by a single whitespace.

Which rule, if any, is the bug related to?

selector-combinator-space-after

What stylelint configuration is needed to reproduce the bug?

{
  "rules": {
    "selector-combinator-space-after": "always"
  }
}

Which version of stylelint are you using?

11.1.1

How are you running stylelint: CLI, PostCSS plugin, Node.js API?

stylelint **/*.scss

via @wordpress/scripts

Does the bug relate to non-standard syntax (e.g. SCSS, Less etc.)?

No.

What did you expect to happen?

No error to be flagged.

What actually happened (e.g. what warnings or errors did you get)?

stylelint is complaining about the first selector, because the ~ combinator is not followed by a single whitespace:

Expected single space after "~"   selector-combinator-space-after

If I were to add a whitespace (which would look strange anyway), stylelint, of course, complains about a stray whitespace before the comma:

.foo ~ ,
.bar {
  .baz {
    display: none;
  }
}
Unexpected whitespace before ","   selector-list-comma-space-before

This assumes "selector-list-comma-space-before": "never" to be included in the rules.


This issue is not specific to the ~ combinator, but all of them. When linting SCSS, stylelint should allow for any combinator to be directly followed by a comma, for example, ~,.

good first issue ready to implement scss bug

Most helpful comment

Looks like this is inactive, I should be able to take this!

All 3 comments

Thank you for reporting and using the issue template. I can reproduce it on the demo site so it looks like a bug.

@tfrommen Thanks for the clear explanation.

I can reproduce it on the demo site so it looks like a bug.

I agree.

The rule should ignore any selectors with a trailing combinator as standard selectors explicitly use the _nesting selector_ (&).

I suggest we add a conditional to isStandardSyntaxSelector to return early if the selector has a trailing combinator. We'd then make use of that util in selectorCombinatorSpaceChecker.

I've labelled the issue as ready to implement. @tfrommen Please consider contributing a fix if you have time.

Looks like this is inactive, I should be able to take this!

Was this page helpful?
0 / 5 - 0 ratings