8000 Improve upgrade migrations by RobinMalfait · Pull Request #18184 · tailwindlabs/tailwindcss · GitHub
[go: up one dir, main page]

Skip to content

Improve upgrade migrations #18184

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

Merged
merged 5 commits into from
May 30, 2025
Merged

Improve upgrade migrations #18184

merged 5 commits into from
May 30, 2025

Conversation

RobinMalfait
Copy link
Member
@RobinMalfait RobinMalfait commented May 30, 2025

This PR fixes 2 issues with the migration tool where certain classes weren't migrated. This PR fixes those 2 scenarios:

Scenario 1

When you have an arbitrary opacity modifier that doesn't use %, but is just a number typically between 0 and 1 then this was not converted to the bare value equivalent before.

E.g.:

<div class="bg-[#f00]/[0.16]"></dv>

Will now be converted to:

<div class="bg-[#f00]/16"></dv>

Scenario 2

Fixes a bug when a CSS function was used in a fallback value in the CSS variable shorthand syntax. In that case we didn't migrate the class to the new syntax.

This was because we assumed that a ( was found, that we are dealing with a CSS function.

E.g.:

<div class="w-[--spacing(1)]"></div>
                        ^  This indicates a CSS function, we should not be 
                           converting this to `w-(--spacing(1))`

But if a function was used as a fallback value, for example:

<div class="bg-[--my-color,theme(colors.red.500)]"></dv>

Then we also didn't migrate it, but since the function call is in the fallback, we can still migrate it.

Will now properly be converted to:

<div class="bg-(--my-color,var(--color-red-500))"></dv>

Test plan

  1. Added a test for the first case
  2. Added a test for the second case
  3. Also added an integration-like test that runs all the migration steps to make sure that the theme(…) in the fallback also gets updated to var(…). This one caught an issue because the var(…) wasn't handling prefixes correctly.

Before this, the moment we saw a `(` we stopped trying to convert
`bg-[--foo()]` to `bg-(--foo())`. This is because it doesn't make sense
to wrap a CSS function in another `var(…)`.

However, if that `(` exists in the fallback value, then it's fine and
we can still perform the conversion:

- `bg-[--my-color,theme(colors.red.500)]` → `bg-(--my-color,theme(colors.red.500))`
+ fix issue when you are using a CSS variable. In that case you do need
  the `--tw-` prefix for variables defined in the Theme.
@RobinMalfait RobinMalfait requested a review from a team as a code owner May 30, 2025 10:42
Comment on lines +196 to +199
if (designSystem.theme.prefix) {
return `--${designSystem.theme.prefix}-${variable.slice(2)}`
}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When adding the test to the migrate.test.ts file that runs all the migrations (with variants, prefix, ...) it caught an issue where we didn't handle the --tw- prefix properly when reading from theme values, which is actually necessary when you have a prefix.

See https://play.tailwindcss.com/BlXfDMDtZz

@RobinMalfait RobinMalfait enabled auto-merge (squash) May 30, 2025 13:29
@RobinMalfait RobinMalfait merged commit 31c0a21 into main May 30, 2025
7 checks passed
@RobinMalfait RobinMalfait deleted the feat/upgrade-improvements branch May 30, 2025 13:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0