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 --fix=lax
and --fix=strict
#7497
Comments
I've labeled the issue as ready to implement. Please consider contributing if you have time. |
I looked into the introduction of
$ echo 'a {' | npx stylelint
<input css 1>
1:1 ✖ Unclosed block CssSyntaxError
1 problem (1 error, 0 warnings)
$ echo 'a {' | npx stylelint --fix
a {
}% Of course, this package cannot fix some syntax errors like $ echo '// comment' | npx stylelint
<input css 1>
1:1 ✖ Unknown word CssSyntaxError
1 problem (1 error, 0 warnings)
$ echo '// comment' | npx stylelint --fix
// comment For now, I cannot find a solution, but let us know if anyone has some information. |
For reference, an incomplete comment like $ echo '/* comment' | npx stylelint --fix
/* comment
*/% |
What about some heuristics based on the previous iteration that switch between |
That heuristics use file extensions supporting the stylelint/docs/developer-guide/rules.md Line 13 in 382961f
|
The alternative of not using The worst that can happen with the partial revert is having someone using CSS-compatible code in a scss file that would trigger the warning erroneously. In that case it's just a matter of detecting the absence of CSS syntax error and adding a hint regarding the possibility of changing the extension. The list maintenance is not a strong argument against it IMHO. |
Hum..., I'm still concerned that the file extension list based on heuristics may grow at people's request. In addition, if we'd like to remove the list itself or some extensions from the list, we must care about backward compatibility. First of all, performing autofix first is an edge case, right? I believe normal use cases are below:
Furthermore, we encourage using the stylelint/docs/user-guide/get-started.md Line 57 in 382961f
So, I doubt the worth of this heuristic, though ideally, the bug should not exist. |
We can wait for the resolution of stylelint/vscode-stylelint#490 and reevaluate then. |
For reference, we previously removed an inaccurate syntax inference (heuristic) with PR #6645. |
That one looks more like something I wouldn't recommend we maintain, I agree for that list. |
Agree. We can revisit this issue if many people complain. |
Also, we can revisit if a better solution is found. |
What about a new flag? We could use a different validator for that flag or simply |
If most people don't care about this bug, I guess adding a new flag is too much. |
It's elegant because it doesn't require a new flag.
I don't have an opinion. As long as it's configurable I am satisfied. |
At this time, what is "a stricter parser"? |
--fix
--fix
fix
option
Let's say that as a prerequisite, it should take into account the values. It's a can of worms if the dependency is not well maintained but if |
I would narrow the scope as much as possible so that it doesn't overlap with any other rule. |
That would either
I would prefer 1. but I am pretty sure we won't find one, so 2. will be a hard requirement if we want to avoid overlaps. |
I see what you mean, but I fear that this stricter parser would in a way become an entirely new Stylelint :D I am sure that there will be some overlap and that is fine, but I would still like to minimize this as much as possible. You could see it as a layer cake:
For me a strict parser would only check layers 1 and 2. |
I also want to keep things simple. And, if the current |
Let's split this proposal into 2:
Concerning 2. I think that it's simpler to handle value position/type/enum validation when it matters (i.e. before |
Please read #7497 (comment) |
fix
optionfix
flag type to "string"
with choices: ['strict', 'lax']
I am dropping my related: sindresorhus/meow#44 |
fix
flag type to "string"
with choices: ['strict', 'lax']
--fix="lax"
and --fix="strict"
--fix="lax"
and --fix="strict"
--fix=lax
and --fix=strict
@Mouvedia Thanks for sharing the Meow issue. Is there any workaround for the problem if Meow doesn't address it? |
There is, if you switch to ready to implement I will show you. |
Alright. I've labeled the issue as ready to implement. Please consider contributing if you have time. |
What minimal example or steps are needed to reproduce the bug?
Analyzing a CSS file with an invalid syntax raises a syntax error expectedly, while doing the same specifying
--fix
succeeds unexpectedly.test.css
:For reference, this behavior difference depends on
postcss-safe-parser
:stylelint/lib/getPostcssResult.mjs
Line 127 in 382961f
Note: we found this problem in #7494.
What minimal configuration is needed to reproduce the bug?
{"rules": {}}
How did you run Stylelint?
Run the following commands in my console.
Which Stylelint-related dependencies are you using?
package.json
:What did you expect to happen?
Expect to raise a syntax error. E.g.
What actually happened?
A syntax error does not happen, and then Stylelint exits normally. E.g.
Do you have a proposal to fix the bug?
do something similar to https://github.com/noahbrenner/xo/blob/8e4f4355c4b8e62bc28f37e3673bb6872e693bb0/main.js#L119-L133
update fix option
true
maps to"lax"
false
doesn't change"lax"
aliases totrue
"strict"
addedThe text was updated successfully, but these errors were encountered: