Open alisonailea opened 6 years ago
@alisonailea Sound great idea for rule for me
Looks like a good idea! And it meets our criteria for inclusion. Let's wait for @jeddy3, because he usually sees what other miss :)
Even if it won't make to the core, it would make a good plugin.
Does https://github.com/csstree/stylelint-validator detect this?
Looking at https://csstree.github.io/docs/validator.html many of the examples in the test cases above do throw Parse error: Identifier is expected
warnings.
Does https://github.com/csstree/stylelint-validator detect this?
In its current form, it:
calc
, url
and var
etcmedia
and supports
etcCSSTree throws a parse error for the former.
It looks like the PostCSS parser itself will throw a Unclosed bracket
or Unknown word
parse error for any extra parenthesis outside of the params of an at-rule or the value of a declaration.
In the VISION we have:
Invalid code is best handled by emerging dedicated tools e.g. csstree - a language parser with syntax validation. As a stop-gap, while these tools mature, provide invalid code rules for the simplest of cases.
As the parser itself covers off most instances, I think this will be one of those "simplest cases" and we can add this rule as a stop-gap for the extra parenthesis in the:
@alisonailea Thank you for offering to contribute this rule. You'll find guidance on how to do this in the Developer Guide.
I think you can strip the tests right back, though. Just focus on standard CSS syntax e.g. extra parens in @media
, @support
, calc
, url
and var
. You can throw in a couple of SCSS syntax tests for @include
and @mixin
, though.
no-extra-parenthesis
true
Having thought a little more about this, I think we should limit the scope of this rule to unbalanced parentheses. This is the use case @alisonailea originally describes.
The word extra implies redundant, which would broaden the scope of this rule to include balanced but unnecessary parentheses, e.g. calc((10px) + (10px))
, and that isn't viable. This wasn't an issue with semicolons, hence the name no-extra-semicolons
.
We should also pluralise the rule name to be consistent with no-extra-semicolons
:
no-unbalanced-parentheses
true
Would this fix the following synthetic case, which just hit me in real code, where I copy/pasted part of a $0.querySelector(....)
call I did in chrome devtools as a test, but copied a ')' by mistake and didn't notice?
$ echo ' ) {
background: red;
}
' | npx stylelint
$
Stylelint didn't flag an error, and the rule didn't apply - took me a while to see that it was a typo.
Would this fix the following synthetic case
PostCSS parses this as a selector of )
.
We can expand the scope of the rule to include selectors, so the complete scope becomes:
Please consider contributing the rule if you have time.
There are steps on how to add a new rule in the Developer guide.
This issue is older than one month. Please ask before opening a pull request, as it may no longer be relevant.
Hi
I’d like to work on this issue. Could you assign it to me?
The Problem
Developers on my team occasionally add extra parenthesis to the end of custom-properties, media-queries, and urls which are not caught by other linting rules and which can cause errors when that CSS is used in other projects.
The Solution
A new rule that checks for extra parenthesis at the end of media queries and custom-properties
Notes
I have a branch in my local clone of Stylelint with this rule already partially written if it is something the community wants I'm happy to finish and submit the PR
Tape test (based off no-extra-semicolons)