-
-
Notifications
You must be signed in to change notification settings - Fork 929
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add selector-combinator-*list rules #3088
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good job!
Some things are controversial.
}); | ||
}); | ||
it("descendant (double child)", () => { | ||
return rules("a >> b {}", func => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't find it in a specification. Doesn't look like a standard one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a level 4 one. I'll take it out though
``` | ||
|
||
```css | ||
a >>> b {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not a standard combinator. Maybe it's better not to add it to readme?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point
return (root, result) => { | ||
const validOptions = validateOptions(result, ruleName, { | ||
actual: blacklist, | ||
possible: [_.isString] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should also check for _.isRegExp
according to readme. It would be great to have RegExp in tests as well. Both as a string and as RegExp.
The same comment applies to the second rule.
|
||
## Options | ||
|
||
`array|string|regex`: `["array", "of", "unprefixed", "pseudo-elements" or "regex"]|"pseudo-element"|/regex/` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These rule about combinators.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops
|
||
## Options | ||
|
||
`array|string|regex`: `["array", "of", "unprefixed", "pseudo-elements" or "regex"]|"pseudo-element"|/regex/` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These rule about combinators.
``` | ||
|
||
```css | ||
a >>> b {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not a standard combinator. Maybe it's better not to add it to readme?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
General points:
Can we add a couple tests for combinators without spaces and where " " is not specified as a combinator?
I'm thinking that POSSIBLY -whitelist
should assume " " is a valid combinator and add it automatically to the config? As a user, it's so common that I'm not even sure I think about it. Could be a source of confusion resulting in bug reports we have to sift through later ... (this may go against the core values of stylelint and I'm good on it either way, just wanted to throw it out there ...)
I'm going to push back a bit on allowing RegExp's ... most combinators are just a single special character (+, ~) and I don't see this feature being all that useful. Puts cognitive load on the user and maintainers for possibly not much gain. I could be convinved otherwise, I just don't see a real use for it.
That's a fair point. I originally intended to add RegExps for controlling what whitespace is allowed for descendant combinators. I've updated the tests and examples to show this, rather than use the child and piercing combinators.
I think there is a use case for not allowing the descendant combinator e.g. a completely flat specificity graph or when (exclusively) using CSS Modules' Having said all that, perhaps it is better to split this up:
The latter two would ignore whitespace descendant combinators and not accept RegExp. What do you think? |
Fair. I'm sold on this the way it is. Having to create another rule and to handle an exception to this one seems like a waste. Maybe just make sure the README specifically mentions that " " is itself a combinator and needs to be whitelisted explicitly.
Yeah, this seems like a different concern to me. Stylistic rather than functional. |
Ummm... I think you've (despite your conclusion) talked me out of not breaking the rule up.
This rule is unique amongst the
That's a good point. Keeping support for the descendant combinator in makes this rule half functional and half stylistic. |
I agree with @CAYdenberg. RegExp here might be redundant.
I believe these rules should be functional and not about the style of code. To avoid using RegExp and avoid stylistic concerns we could replace |
|
||
## Options | ||
|
||
`array|string|regex`: `["array", "of", "unprefixed", "combinators" or "regex"]|"combinator"|/regex/` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are prefixed combinators? :)
That's a great idea. It does away with the need for the I'll make the change now. |
@hudochenkov & @CAYdenberg This is ready for review again. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good job, @jeddy3!
Good catch on rule complexity and scope, @CAYdenberg!
@CAYdenberg please, add a changelog item when PR merged https://github.com/stylelint/stylelint/blob/master/docs/developer-guide/pull-requests.md |
I did ... just took a few extra minutes because I also have kids 🤕 |
@CAYdenberg sorry, man. Saw you started answering other issues, and though you forgot. Sorry. |
NP ... appreciate the respect for our process. |
Changelog: 741cd6e#diff-4ac32a78649ca5bdd8e0ba38b7006a1e
|
Closes #3013