Make decodeArbitraryValue overridable
#14717
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @RobinMalfait and the rest of your teammates on |
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @RobinMalfait and the rest of your teammates on |
|
Phew yeah this is ugly. I do think maybe hard-forking
@RobinMalfait I wonder if this maybe is simpler in the long term? Assume we add a new feature to the parseVariant, the way we reuse the code means that we now also support this new feature in the v3 => v4 migration where as we never did support this in v3 probably so it's starting to migrate candidates that aren't supposed to be migrated? It also means we can make changes to the "core" |
|
Going to close this in favor of #14720 — I think that's the cleaner way to approach this problem 👍 |
This PR will optimize and simplify the candidates when printing the candidate again after running codemods. When we parse a candidate, we will add spaces around operators, for example `p-[calc(1px+1px)]]` will internally be handled as `calc(1px + 1px)`. Before this change, we would re-print this as: `p-[calc(1px_+_1px)]`. This PR changes that by simplifying the candidate again so that the output is `p-[calc(1px+1px)]`. In addition, if _you_ wrote `p-[calc(1px_+_1px)]` then we will also simplify it to the concise form `p-[calc(1px_+_1px)]`. Some examples: Input: ```html <div class="[p]:flex"></div> <div class="[&:is(p)]:flex"></div> <div class="has-[p]:flex"></div> <div class="px-[theme(spacing.4)-1px]"></div> ``` Output before: ```html <div class="[&:is(p)]:flex"></div> <div class="[&:is(p)]:flex"></div> <div class="has-[&:is(p)]:flex"></div> <div class="px-[var(--spacing-4)_-_1px]"></div> ``` Output after: ```html <div class="[p]:flex"></div> <div class="[p]:flex"></div> <div class="has-[p]:flex"></div> <div class="px-[var(--spacing-4)-1px]"></div> ``` --- This is alternative implementation to #14717 and #14718 Closes: #14717 Closes: #14718
This PR allows us to override the
decodeArbitraryValuefunction used when parsing candidates and variants.I'm not 100% happy with this (open for suggestions!) but it was either this, or introducing some class where we mock a method or as a last resort, copy the whole
parseCandidateimplementation and make the necessary changes there when running codemods.While the last one seems to be the cleanest, I'm afraid that the implementation will diverge over time.