-
Notifications
You must be signed in to change notification settings - Fork 5
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
Potential support for double-slash comments. #11
Comments
Hesitance comes from few points:
I agree messaging is not clear. It is comming directly from PostCSS default parser. I tried to change as minimal as possible in the parser. Because I'm not a parser expert, and I would rather rely on PostCSS authors experience. Even for future updates of a parser. Stylelint with default parser also shows “Unknown word” error.
I'm not sure it worth the effort to complicate parser with double-slash comments. As history showed us, it is not a big deal that they are not supported. Also, adding support for it will make future update to parser harder. As the idea is to backport changes from PostCSS default parser back to this parser as CSS spec evolves. |
-1 for this feature request. We are so happy this is a default rule in the checker because all minifiers strip out whitespace and if there are any Obvious example: body {
color: red;
}
// override body color
body {
color: blue;
} gets minified to: body{color:red;}// override body color body{color:blue;} and as you can imagine doesn't have the desired effect. |
Hello! I see in the readme that there is hesitancy to adding support for double-slash comments within styled components, but with it being a syntax error rather than a rule, it can create some roadblocks in the developer experience. Because they aren't parsed properly, the developer doesn't have an explicit explanation of what caused the error (for example the no double slash comments rule). In larger organizations where it might not be widespread knowledge that we should not be using double-slash comments in styled components, there is unclear messaging on how to move past this issue. As a workaround currently (in my own fork), I'm modifying the tokenizer to classify double slash comments the same as block comments so developers don't encounter this. Is this, or a similar solution where we can have the double-slash moments parsed normally, something you would consider merging? I'd be happy to write a PR. Thanks!
The text was updated successfully, but these errors were encountered: