Migrate aria-*, data-* and supports-* variants from arbitrary values to bare values
#14644
Conversation
|
This brings me such joy 🥳 I think we can migrate |
| variant.kind === 'functional' && | ||
| variant.root === 'aria' && | ||
| variant.value?.kind === 'arbitrary' && | ||
| variant.value.value.endsWith('="true"') |
There was a problem hiding this comment.
Is it valid to pass all CSS attribute selectors here? e.g. :!= or *= etc. This would match more often than we want it in that case
There was a problem hiding this comment.
The goal here is to match what the user would've typed in the variant in v3 that is equivalent to the variant in v4 so anything other than ="true" would be wrong because ="true" is what v4 uses.
There was a problem hiding this comment.
Ah but I see what @philipp-spiess means. If we have aria-[foo*="true"] then this could will match, but it should not match because we can't safely migrate that. Will adjust and add a test.
There was a problem hiding this comment.
Haha yeah that's what I meant! This will then migrate to aria-foo* which seems unexpected
There was a problem hiding this comment.
ooohhhh I see! yep that's def an issue
RobinMalfait
force-pushed
the
feat/migrate-data-and-aria-arbitrary-values
branch
from
a99b4b8 to
85f1a07
Compare
RobinMalfait
changed the title
data-* and aria-* variants from arbitrary values to bare valuesaria-*, data-* and supports-* variants from arbitrary values to bare values
| (variant.value.value.endsWith('=true') || | ||
| variant.value.value.endsWith('="true"') || | ||
| variant.value.value.endsWith("='true'")) | ||
| ) { | ||
| let [key, _value] = segment(variant.value.value, '=') | ||
| if ( | ||
| // aria-[foo~="true"] | ||
| key[key.length - 1] === '~' || | ||
| // aria-[foo|="true"] | ||
| key[key.length - 1] === '|' || | ||
| // aria-[foo^="true"] | ||
| key[key.length - 1] === '^' || | ||
| // aria-[foo$="true"] | ||
| key[key.length - 1] === '$' || | ||
| // aria-[foo*="true"] | ||
| key[key.length - 1] === '*' |
There was a problem hiding this comment.
I had a regex that covered all of these cases but it was horrible so made it more explicit 🙈
There was a problem hiding this comment.
lol its almost all special regex chars 😂 — I don't think any of them need to be escaped in a character class tho right? (unless ^ was listed first iirc). I think its this right /[~|^$*]$/.test(key)?
There was a problem hiding this comment.
explicit list of cases is fine though. It definitely reads better.
There was a problem hiding this comment.
This is the one I used originally /[^~|^$*]=(['"]?)true\1/
There was a problem hiding this comment.
ahhh yeah that is kinda awful lol
RobinMalfait
force-pushed
the
feat/migrate-data-and-aria-arbitrary-values
branch
2 times, most recently
from
0ce28b0 to
180b5aa
Compare
RobinMalfait
force-pushed
the
feat/migrate-data-and-aria-arbitrary-values
branch
from
180b5aa to
524cdbc
Compare
This PR adds a new codemod that can migrate
data-*andaria-*variants using arbitrary values to bare values.In Tailwind CSS v3, if you want to conditionally apply a class using data attributes, then you can write
data-[selected]:flex. This requires the DOM element to have adata-selected=""attribute. In Tailwind CSS v4 we can simplify this, by dropping the brackets and by usingdata-selected:flexdirectly.This migration operates on the internal AST, which means that this also just works for compound variants such as
group-has-data-[selected]:flex(which turns intogroup-has-data-selected:flex).Additionally, this codemod is also applicable to
aria-*variants. The biggest difference is that in v4aria-selectedmaps to an attribute ofaria-selected="true". This means that we can only migratearia=[selected="true"]:flextoaria-selected:flex.Last but not least, we also migrate
supports-[gap]tosupports-gapif the passed in value looks like a property. If not, e.g.:supports-[display:grid]then it stays as-is.