Fix false negatives for CSS-In-JS in color-no-invalid-hex #3945 #3957
Conversation
There was a problem hiding this comment.
@fogost Thanks for making start on this and for your first-time contribution.
I've made some requests.
Your best bet is to add a failing test for css-in-js, and then migrate to postcss-value-parser to see if that fixes it. Here's an example of an css-in-js test.
| @@ -28,9 +28,6 @@ testRule(rule, { | |||
| { | |||
| code: "a { padding: 000; }" | |||
| }, | |||
| { | |||
There was a problem hiding this comment.
This test needs to stay as we need to prove that this rule doesn't check the contents of strings.
| return; | ||
| } | ||
| styleSearch( | ||
| { source: declString, target: "#", strings: "check" }, |
There was a problem hiding this comment.
I suspect the way to fix this is to migrate the rule away from styleSearch and to postcss-value-parser. There wasn't a value parser around when this rule was created, but now we have one and it is proving a more robust way of dealing with the values of declarations.
There an example of the value parser in use in the color-named rule.
e.g.
root.walkDecls(decl => {
valueParser(decl.value).walk(({value, type, sourceIndex) => {
if (type !== "word") return;
const hexMatch = /^#[0-9A-Za-z]+/.exec(value);
..
}
}
|
I changed |
There was a problem hiding this comment.
@fogost Thanks very much for making the changes. It's great to see this rule (one of the first to be added to stylelint) get some love and be updated to use the value parser.
The changes look good to me.
There are a few pretty-printing changes to unrelated files in this PR. I suspect this is because they somehow slipped through the net in the past, and you (correctly) ran npm run prettier:fix before pushing your commit. I'm happy for these changes to be bundled in this PR for the sake of keeping things simple.
I'll create an issue to run npm run prettier:check as part of our CI tests.
<!--- Please read the following. Pull requests that do not adhere to these guidelines will be closed. Each pull request must, with the exception of minor documentation fixes, be associated with an open issue. If a corresponding issue does not exist please stop. Instead, create an issue so we can discuss the change first. If there is an associated open issue, then the next step is to make sure you've read the relevant developer guide: - Creating a new rule: https://github.com/stylelint/stylelint/blob/master/docs/developer-guide/rules.md#creating-a-new-rule - Adding an option to an existing rule: https://github.com/stylelint/stylelint/blob/master/docs/developer-guide/rules.md#adding-an-option-to-an-existing-rule - Fixing a bug in an existing rule: https://github.com/stylelint/stylelint/blob/master/docs/developer-guide/rules.md#fixing-a-bug-in-an-existing-rule Once you've done that, then please continue by answering these two questions: --> > Which issue, if any, is this issue related to? Ref: #3957 (review) > Is there anything in the PR that needs further explanation? We should use the CI to make sure everything is pretty-printed. This will fail until #3957 is in and rebased.
Closes #3945
This solves the problem, but I'm not sure about tests.