Migrate arbitrary values to built-in values #14841

RobinMalfait · 2024-10-31T10:44:00Z

This PR adds a migration where we detect arbitrary variants and try to upgrade them to built-in variants.

For example, if you are using [[data-visible]]:flex, we can convert it to data-visible:flex. We can also upgrade more advanced examples such as has-[[data-visible]]:flex to a compound variant which becomes has-data-visible:flex.

A table of example migrations:

Before	After
`[[data-visible]]:flex`	`data-visible:flex`
`[&[data-visible]]:flex`	`data-visible:flex`
`[[data-visible]&]:flex`	`data-visible:flex`
`[[data-url*="example"]]:flex`	`data-[url*="example"]:flex`
`[[data-url$=".com"_i]]:flex`	`data-[url$=".com"_i]:flex`
`[[data-url$=.com_i]]:flex`	`data-[url$=.com_i]:flex`
`[&:is([data-visible])]:flex`	`data-visible:flex`
`has-[[data-visible]]:flex`	`has-data-visible:flex`
`has-[&:is([data-visible])]:flex`	`has-data-visible:flex`
`has-[[data-slot=description]]:flex`	`has-data-[slot=description]:flex`
`has-[&:is([data-slot=description])]:flex`	`has-data-[slot=description]:flex`
`has-[[aria-visible="true"]]:flex`	`has-aria-visible:flex`
`has-[[aria-visible]]:flex`	`has-aria-[visible]:flex`

We can also convert combinators from [&>[data-visible]]:flex to just *:data-visible:flex and [&_[data-visible]]:flex to **:data-visible:flex.

Before	After
`[&>[data-visible]]:flex`	`*:data-visible:flex`
`[&_>_[data-visible]]:flex`	`*:data-visible:flex`
`[&_[data-visible]]:flex`	`**:data-visible:flex`

Additionally, if you have complex selectors with :not(), we can convert this to a compound not-* variant in some cases as well:

Before	After
`[&:nth-child(2)]:flex`	`nth-2:flex`
`[&:not(:nth-child(2))]:flex`	`not-nth-2:flex`

If some of the values in nth-child(…) are a bit too complex, then we still try to convert them but to arbitrary values instead.

Before	After
`[&:nth-child(-n+3)]:flex`	`nth-[-n+3]:flex`
`[&:not(:nth-child(-n+3))]:flex`	`not-nth-[-n+3]:flex`

This also implements some optimizations around even and odd:

Before	After
`[&:nth-child(odd)]:flex`	`odd:flex`
`[&:not(:nth-child(odd))]:flex`	`even:flex`
`[&:nth-child(even)]:flex`	`even:flex`
`[&:not(:nth-child(even))]:flex`	`odd:flex`

Some examples that stay as-is:

has-[&>[data-visible]]:flex we can't upgrade this one because has-* is not a valid variant.
has-[[data-visible][data-dark]]:flex we can't upgrade this one because [data-visible][data-dark] has to be on the same element. If we convert this to has-data-visible:has-data-dark:flex then this condition will be true if an element exists with data-visible and another element exists with data-dark but we don't guarantee that they are the same element.

Running this on the Catalyst codebase results in some updates that look like this:

thecrypticace · 2024-10-31T18:48:08Z

packages/@tailwindcss-upgrade/src/template/codemods/modernize-arbitrary-values.ts

+        ast.nodes[0].nodes[2].type === 'attribute'
+      ) {
+        ast.nodes[0].nodes = [ast.nodes[0].nodes[2]]
+        addChildVariant = true


Only thing I can think of is that *:data-visible:{utility} is technically something like :where(& > [data-visible]) but it might be fine to ignore that detail.

If we're cool with that this all looks good.

Thinking about this, I think the new value is more correct because with just [&>[data-visible]] you run into more issues: https://play.tailwindcss.com/aPcIgi2nc5

I'm fine with making the change. Maybe should output a small note when we find it in case the old behavior is being relied on?

I'd also be fine with doing that in a follow up PR honestly.

That's an option. We technically already mention to verify the changes. What are your thoughts on this /cc @philipp-spiess @adamwathan

Yeah that's fair. Maybe that's fine.

Tricky one since the specificity is different, not sure. We probably can change it but trying to think of cases where it would matter. Should test in Catalyst which does a lot of this sort of thing.

There are indeed cases in Catalyst where it would break if we do this conversion sadly. We could go through Catalyst and make sure that this isn't an issue, but that doesn't solve it for our users.

I'll revert this particular change.

Revert this back because we made * use :is(…) instead of :where(…).

CHANGELOG.md

RobinMalfait · 2024-11-08T11:49:25Z

I was working on a separate PR for additional conversions similar to this. Since this is not yet merged, I think it's better to just push this one commit here as well.

RobinMalfait · 2024-11-08T11:50:07Z

cb87473?diff=split&w=1

E.g.: from Catalyst

RobinMalfait · 2024-11-08T16:07:22Z

Re-introduced the [&>[data-visible]]:flex to *:data-visible:flex change. Also added a new [&_[data-visible]]:flex to **:data-visible:flex conversion.

A bunch of changes happened since this review, so I think it's best to re-review.

E.g.: `has-[[data-visible]]` can be converted `has-data-visible`

Co-authored-by: Adam Wathan <[email protected]>

And add support for: - nth - nth-last - nth-of-type - nth-of-last-type

This reverts commit 14b1854.

philipp-spiess

Amazing what we can do with the codemods! I did find two of the examples in the test plan slightly confusing, however I don't think they make anything worse than it is right now so LGTM

philipp-spiess · 2024-11-11T11:40:48Z

packages/@tailwindcss-upgrade/src/template/codemods/modernize-arbitrary-values.test.ts

+  ['[[data-url*="example"]]:flex', 'data-[url*="example"]:flex'],
+  ['[[data-url$=".com"_i]]:flex', 'data-[url$=".com"_i]:flex'],
+  ['[[data-url$=.com_i]]:flex', 'data-[url$=.com_i]:flex'],


None of these seem to work in v3, but it is valid in v4 alpha. However I think the codemods currently are not intended to run on the alpha b/c of the variant reordering so may be able to rm support for this

https://play.tailwindcss.com/lbxFdmRt0Z

Ah true, in v3 you need the &, but the main thing I was testing here is the flag placement and strings vs no strings.

E.g.: [&[data-url*="example"]]:flex

philipp-spiess · 2024-11-11T11:42:14Z

packages/@tailwindcss-upgrade/src/template/codemods/modernize-arbitrary-values.test.ts

+
+  // Compound arbitrary variants
+  ['has-[[data-visible]]:flex', 'has-data-visible:flex'],
+  ['has-[&:is([data-visible])]:flex', 'has-data-visible:flex'],


has-[&:is([data-visible])]:flex has a specificity of 0, 3, 0 in v3 but [has-[&:is([data-visible])]:flex](has-data-visible:flex) is 0, 2, 0 in v4.

HOWEVER has-[&:is([data-visible])]:flex is also 0, 2, 0 in v4 so keeping this wouldn't fix it either.

Yeah exactly, it's a side effect of the implementation in v4 unrelated to this change. If you want to be 100% the same, we should switch to arbitrary variants instead but that makes it worse.

RobinMalfait requested a review from a team as a code owner October 31, 2024 10:44

RobinMalfait force-pushed the feat/modernize-arbitrary-values branch from cf849fb to 1500ca7 Compare October 31, 2024 16:45

thecrypticace reviewed Oct 31, 2024

View reviewed changes

RobinMalfait force-pushed the feat/modernize-arbitrary-values branch 2 times, most recently from 5ce36a4 to c23cdcb Compare November 6, 2024 15:54

thecrypticace previously approved these changes Nov 6, 2024

View reviewed changes

RobinMalfait force-pushed the feat/modernize-arbitrary-values branch 2 times, most recently from 60b5b25 to ddf193d Compare November 7, 2024 12:26

adamwathan reviewed Nov 7, 2024

View reviewed changes

CHANGELOG.md Outdated Show resolved Hide resolved

RobinMalfait force-pushed the feat/modernize-arbitrary-values branch from 3d1df7f to bffd222 Compare November 8, 2024 10:00

RobinMalfait requested review from thecrypticace and adamwathan November 8, 2024 11:50

RobinMalfait force-pushed the feat/modernize-arbitrary-values branch from c092898 to b846470 Compare November 8, 2024 16:00

RobinMalfait force-pushed the feat/modernize-arbitrary-values branch from 224cdc7 to 65922e3 Compare November 8, 2024 16:09

RobinMalfait force-pushed the feat/modernize-arbitrary-values branch from 65922e3 to 9919924 Compare November 8, 2024 19:04

RobinMalfait enabled auto-merge (squash) November 8, 2024 19:04

RobinMalfait and others added 9 commits November 9, 2024 01:56

migrate arbitrary values to modern values

44cabf1

E.g.: `has-[[data-visible]]` can be converted `has-data-visible`

update changelog

50f0a01

Co-authored-by: Adam Wathan <[email protected]>

do not convert [&>…] to *:…

4805466

migrate :first-child, :last-child, :nth-child(…) and so on

4875832

add most staticVariants

a712e62

And add support for: - nth - nth-last - nth-of-type - nth-of-last-type

Revert "do not convert [&>…] to *:…"

127860e

This reverts commit 14b1854.

convert [&_[data-visible]] to **:data-visible

7663a79

rename variables

5dac720

compute variant ahead of time

642fa95

RobinMalfait force-pushed the feat/modernize-arbitrary-values branch from 9919924 to 642fa95 Compare November 9, 2024 00:56

philipp-spiess approved these changes Nov 11, 2024

View reviewed changes

RobinMalfait merged commit 0d3e13e into next Nov 11, 2024
1 check passed

RobinMalfait deleted the feat/modernize-arbitrary-values branch November 11, 2024 11:44

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Migrate arbitrary values to built-in values #14841

Migrate arbitrary values to built-in values #14841

RobinMalfait commented Oct 31, 2024 •

edited

Loading

thecrypticace Oct 31, 2024

RobinMalfait Nov 6, 2024 •

edited

Loading

thecrypticace Nov 6, 2024

thecrypticace Nov 6, 2024

RobinMalfait Nov 6, 2024

thecrypticace Nov 6, 2024

adamwathan Nov 7, 2024

RobinMalfait Nov 8, 2024

RobinMalfait Nov 8, 2024

RobinMalfait commented Nov 8, 2024

RobinMalfait commented Nov 8, 2024

RobinMalfait commented Nov 8, 2024

philipp-spiess left a comment

philipp-spiess Nov 11, 2024

RobinMalfait Nov 11, 2024

philipp-spiess Nov 11, 2024

RobinMalfait Nov 11, 2024

Migrate arbitrary values to built-in values #14841

Migrate arbitrary values to built-in values #14841

Conversation

RobinMalfait commented Oct 31, 2024 • edited Loading

Choose a reason for hiding this comment

RobinMalfait Nov 6, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RobinMalfait commented Nov 8, 2024

RobinMalfait commented Nov 8, 2024

RobinMalfait commented Nov 8, 2024

philipp-spiess left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RobinMalfait commented Oct 31, 2024 •

edited

Loading

RobinMalfait Nov 6, 2024 •

edited

Loading