-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
Canonicalization constant folding and handling zeros #19095
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
Conversation
Typically each math operator is parsed as a separate word and that's because it's also typically surrounded by spaces. In case of `/`, this was parsed as a separator instead of a word including the whitespace (if any). The use case we had was to parse `theme(colors.red.500/20%)` where we don't want `colors.red.500/20%` to be a single word, but we want 3 parts instead. This normalizes this a little bit such that all math operators (+, -, *, /) are just the `word` nodes and any surrounding whitespace will be a separator node instead.
This is essentially the same as `walk`, but depth first so we handle leaf nodes first. This helps in situations like constant folding where we can work our way up.
We will use those in the constant folding logic. We could use `ValueParser.parse` but we already know we want `word(…)` values so no need to do the extra work.
This doesn't operate on a declaration, but a declaration value right now. Could extend this in the future by also passing in the declaration property if we want more smart fold logic.
This will rely on 2 things: 1. That we properly constant fold length units into `0` 2. That we prefer the "positive" version (`mt-0`) over its negative version (`-mt-0`)
Given they have the same signature.
packages/@tailwindcss-upgrade/src/codemods/template/migrate.test.ts
Outdated
Show resolved
Hide resolved
// | ||
// TODO: Ensure it's safe to do so based on the data types? |
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.
I think this is fairly safe, and feels like something we only have to add support for when running into actual issues 🤔
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.
Let me see if I can break this
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.
Probaaaably, but once you do, the questions is: how common / real is the actual issue.
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.
I think normalizing things with units to without could cause problems (like rem, em, etc… should probably normalize to 0px instead) but then how would you know margin-left: 0
normalizes to 0px
without encoding data type info and that'd be annoying.
All that to say… I think this is fine for now. We can improve this later if need be.
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
The main goal of this PR was to support canonicalization of zero like values. We essentially want to canonicalize
-mt-0
asmt-0
, but alsomt-[0px]
,mt-[0rem]
, and other length-like units to justmt-0
.To do this, we had to handle 2 things:
0px
and0rem
fold to0
. We only do this for length units. We also normalize-0
,+0
,-0.0
and so on to0
.mt-0
over-mt-0
if both result in the same signature.Moved some of the constant folding logic into its own function and added a bunch of separate tests for it.
Test plan
Added more unit tests where we normalize different zero-like values to
0
.Running the canonicalization logic: