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 end positions to warnings #5694
Comments
@ChillyBots Thanks for the report. I've edited the description to use 3 backticks for clarity. |
@ChillyBots Could you please provide a reproduction code with CLI? |
@ybiquitous This isn't really a bug; I think this should be a feature request. The original discussion is in stylelint/vscode-stylelint#315, but I'll summarize here. Stylelint's API only returns a single position for warnings, unlike, for example, ESLint (see Additionally, we can't supply fixes per problem since Stylelint doesn't provide fix edit information per warning, unlike ESLint. So it's not really a bug per se, more a feature request to supply ranges instead of single positions for warnings when possible, and also to provide edits for individual fixes. |
@adalinesimonian Thank you for the helpful summary! I understand it well. 😄 |
Since Stylelint relies on PostCSS, and PostCSS does not have range support, we won't be able to add end position information since the extra data would be ignored by the PostCSS result I've opened a PR for PostCSS which adds support for ranges: postcss/postcss#1669 |
The upstream PR has been merged and will most likely make it into PostCSS 8.3 per postcss/postcss#1669 (comment). Once released, we'll be able to make the necessary changes to support ranges in Stylelint! |
WIP implementation for ranges in #5725 |
Range support in PostCSS has been released in 8.4. End indices are needed in postcss-value-parser, a PR has been opened at TrySound/postcss-value-parser#83 |
I've completed all the tasks! 🎉 @jeddy3 @mattxwang @Mouvedia |
Legendary effort y'all! I'm really looking forward to this, it's a huge improvement. Thanks a ton. |
Great work wrapping this up @ybiquitous! Apologies for not being more of a help - work really has picked up recently 😓 @adalinesimonian, what else can we do to help support vscode-stylelint here? I recall a couple of comments about other work to enable error reporting similar to what ESLint provides, but I can't seem to find it now - is it providing edit info per warning? Edit: I see there's some activity in stylelint/vscode-stylelint#358, apologies for the ping then! |
@ybiquitous FYI here's a list of the rules that were missing from the OP:
|
@Mouvedia Thanks for finding what I missed! When I re-check them, the following rules need to be addressed:
I think the other rules have been fixed already. 🤔 |
I've opened the follow-up PR #6278. |
Avoid errors:
Enforce conventions:
What steps are needed to reproduce the bug?
Run Stylelint! It doesn't provide enough information back to plugins in order for them to effectively show warnings in editors:
Please note in the debug log above, the start and end line characters are the same, despite this being an entire word causing the error. This means errors in editors can only show a single character error underline:
Which in turn means an editor cannot show a dialog with error information. See discussion here from the dev over at vscode-stylelint.
What Stylelint configuration is needed to reproduce the bug?
How did you run Stylelint?
vscode-stylelint & CLI
Which version of Stylelint are you using?
13.12.0 & 14.0.1
What did you expect to happen?
Full start and end word & line information should be passed from stylelint AST parser and back to consuming resources
What actually happened?
Nothing, nada, no dice!
Does the bug relate to non-standard syntax?
SCSS (although I assume all supported syntax)
Proposal to fix the bug
No response
The text was updated successfully, but these errors were encountered: