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
Fix end positions for no-duplicate-*
#6047
Conversation
Unsure of what the highlighted positions should be / what's the most useful for the VSCode extension. Right now, it just highlights the first duplicate selector. I believe this is because of the implementation of the `word` parsing. Is it more useful to highlight each duplicate selector? The last one? etc.
Two concerns: - not sure if calling `atRule.toString()` is the appropriate use; should I be using `raws`? - in this case, my suggested start/end positions are larger than the message rejection, but it aims to match the positions indicated in the README
@@ -81,8 +85,10 @@ testRule({ | |||
warnings: [ | |||
{ | |||
message: messages.rejected('a', 1), | |||
line: 1, | |||
line: 2, |
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 believe this line
was previously incorrect; both a
selectors are on lines 2
and 3
respectively, so I'm not sure how 1
would be reported.
If that is true, what does this mean for the test process? Is it because we didn't report a start index either?
no-duplicate-*
no-duplicate-*
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.
@mattxwang Thank you. Your implementation has no problems 👍🏼
Maybe, we could improve end positions for no-duplicate-selectors
(see #6075), but this pull request is enough for now.
Changelog entry added:
|
Part of the umbrella issue #5694.
I have a couple of questions on how to implement the end positions for these two rules, mostly due to my lack of experience. Would like some opinions!
For
no-duplicate-at-import-rules
:@import ...
). I've currently opted for the latter, since it seems more useful for editor support.atRule.toString()
correct? I feel a bit strange writing this. Should I be recreating it withraws
instead?For
no-duplicate-selectors
:Once these are clarified, I can add
endLine
andendColumn
to each of the test cases for standard CSS syntax.