No-duplicate-selectors doesn't find error, when there're grouping selectors
Which rule, if any, is the bug related to?
no-duplicate-selectors
What CSS is needed to reproduce the bug?
.first-selector, .second-selector {
background: #eee;
}
.second-selector {
background: #000;
}
What stylelint configuration is needed to reproduce the bug?
e.g.
{
"rules": {
"no-duplicate-selectors": true
}
}
Which version of stylelint are you using?
^9.7.0
How are you running stylelint: CLI, PostCSS plugin, Node.js API?
stylelint "*/.css" --config myconfig.json
Does the bug relate to non-standard syntax (e.g. SCSS, Less etc.)?
No
What did you expect to happen?
Warning to be flagged:
Unexpected duplicate selector ".second-selector", first used at line 22 (no-duplicate-selectors) [no-duplicate-selectors]
What actually happened (e.g. what warnings or errors did you get)?
There's no warning
@devsnice Thanks for the report and for using the template.
This is the expected and documented behaviour of the rule:
The same selector _is_ allowed to repeat in the following circumstances:
- It is used in different selector lists, e.g. a {} a, b {}.
This is because grouping common declarations into a group is a common pattern e.g.
input,
textarea,
select {
border: 1px solid black;
}
textarea {
height: 10rem;
}
However, I have seen code bases which discourage this type of grouping and I suspect that's what you're trying to disallow too.
We could add an option, perhaps disallowInSelectorList, which would make this rule stricter. I'll label up for discussion in case anyone else has thoughts on this.
@devsnice Thanks for the report and for using the template.
This is the expected and documented behaviour of the rule:
The same selector _is_ allowed to repeat in the following circumstances:
- It is used in different selector lists, e.g. a {} a, b {}.
This is because grouping common declarations into a group is a common pattern e.g.
input, textarea, select { border: 1px solid black; } textarea { height: 10rem; }However, I have seen code bases which discourage this type of grouping and I suspect that's what you're trying to disallow too.
We could add an option, perhaps
disallowInSelectorList, which would make this rule stricter. I'll label up for discussion in case anyone else has thoughts on this.
I think it will very convenient. For example our team use css-modules and in the common we write a simple class selector for every html-element, but in a process of supporting old functionality (refactoring), we can get problems with redefinition styles, which was defined through a grouping selector somewhere in the above styles
As there are no further thoughts, I'll label this up as a new option.
Let's call it disallowInList for brevity. It accepts a boolean and its default is false.
@devsnice Feel free to contribute this option. There's a section in the Developer Guide on how to get started. If you're looking for a blueprint, selector-class-pattern has an option that makes the rule detect more violations.
Most helpful comment
I think it will very convenient. For example our team use css-modules and in the common we write a simple class selector for every html-element, but in a process of supporting old functionality (refactoring), we can get problems with redefinition styles, which was defined through a grouping selector somewhere in the above styles