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 function-url-quotes
autofix
#6558
Conversation
🦋 Changeset detectedLatest commit: 853d2ba The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
function-url-quotes
autofixfunction-url-quotes
autofix
Good point. I think it will be more readable to split into 2 functions with a single purpose. For example: if (context.fix) {
if (node.type === 'atrule') {
addQuotesForAtRule(node, trimmedArg, complaintIndex);
} else {
addQuotesForDecl(node, trimmedArg, complaintIndex);
}
return;
} The same is true for |
I think the solution makes sense and will not degrade performance much. But benchmarking is beneficial. Please consider sharing benchmark results via the stylelint/docs/developer-guide/rules.md Line 267 in b4fd2d5
|
…specific functions
…xable Co-authored-by: Masafumi Koba <473530+ybiquitous@users.noreply.github.com>
Thanks @ybiquitous for the quick review, I appreciate it! I believe I've addressed all the comments. In addition, thanks for suggesting benchmarks! I ran them (results below), and it seems like there's no sizeable impact on the rule behaviour with or without autofix. I'm unsure if I'm using the commands correctly, small timescale, or variance on my local machine (M1 macOS) represents all other use cases, but it seems reasonable. BenchmarksWith Autofix
Without AutofixNote: we should expect no change, since this PR doesn't touch non-autofix behaviour. HEAD of this PR:
|
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.
Thank you for addressing the reviews and sharing the performance results. LGTM! 👍🏼
@mattxwang does it use the If not, that fix will require multiple runs. |
Ah - no, it doesn't. I implemented this similar to the behaviour in the other two quotes rules ( Is there past precedence / a blueprint for a rule inspecting the value of another rule? It may make sense to simply fix all of these at once in one PR (I am happy to contribute this if desired). |
If you don't I probably will. Either way, it needs to be discussed in an issue: #6577 |
Closes #6500.
Two possible code smells I want to call out. In both cases, I opted to pick a "dirty" solution that doesn't change existing behaviour and minimizes/localizes the changed code. However, there are probably more correct/elegant ways to do this. Advice is welcome!I was able to address these thanks to code review, but I'll leave the comments for posterity.
First, this rule operates on both declarations and at-rules. It seems like in
checkArgs
, this type information is "erased". To resolve this, I have my utility functionsaddQuotes
andremoveQuotes
take in a union type, and then use a crude'params' in node
to differentiate the type.This ... feels wrong? I was a bit unsure if there's a better way for me to do this (either from a TS perspective, or perhaps a Stylelint util that I'm missing).
Secondly, the previous iteration of this rule lowercases declarations and at-rule parameters before passing them in as arguments to
functionArgumentsSearch
. This ensures that the rule matchesUrL
and the like.However, this has the side effect of lowercasing the declaration value and/or at-rule parameters. Then, when I apply the autofix, I propagate this lowercase change (which means that the autofix also inadvertently lowercases the code).
To resolve this problem, I pass in a case-insensitive regex to
functionArgumentsSearch
. I don't think this is technically wrong, but it is likely a performance regression; I didn't want to changefunctionArgumentsSearch
implementation instead. With that in mind, any suggestions on better ways to do this?Thanks in advance - implementing this autofix was trickier than I thought!