Given this variant:
```js
matchVariant(
"foo",
(value) => `&:is([data-foo='${value}'])`,
{
values: {
DEFAULT: "",
bar: "bar",
baz: "bar",
},
}
)
```
We weren't listing `foo-bar` and `foo-baz` in IntelliSense. This PR
fixes that.
This PR fixes two issues:
- When a variant is defined by `matchVariant` it could match unknown
values but not apply the variant (because it's unknown). This would
result in a utility being output that is the _same_ as a bare utility
without variants but a longer name. These were intended to be discarded
but weren't done so correctly.
- Similarly, when we encounter a known value but its not a string the
same thing would happen where we'd output a utility without applying the
variant. This was also intended to be discarded.
Basically given this code:
```js
matchVariant(
"foo",
(value) => `&:is([data-foo='${value}'])`,
{
values: {
DEFAULT: "",
bar: "bar",
obj: { some: "object" },
},
}
)
```
And this HTML:
```html
<div class="foo-bar:bg-none foo-[baz]:bg-none foo-baz:bg-none foo-obj:bg-none"></div>
```
This CSS would be produced:
```css
@layer utilities {
.foo-bar\:bg-none {
&:is([data-foo='bar']) {
background-image: none;
}
}
/* this one shouldn't be here */
.foo-baz\:bg-none {
background-image: none;
}
/* this one shouldn't be here */
.foo-obj\:bg-none {
background-image: none;
}
.foo-\[baz\]\:bg-none {
&:is([data-foo='baz']) {
background-image: none;
}
}
}
```
We introduced an accidental breaking change a few months ago in 4.1.5
with #17812.
We added `visibility` to the property list in `transition` which
unfortunately only applies its change instantly when going from
invisible -> visible.
I've checked `display`, `content-visibility`, and `pointer-events` and
they apply their change instantly (as best I can tell) when
transitioning by default. And `overlay` only "applies" for discrete
transitions so it can stay as well.
The spec has this to say about [animating
`visibility`](https://www.w3.org/TR/web-animations-1/#animating-visibility):
> For the visibility property, visible is interpolated as a discrete
step where values of p between 0 and 1 map to visible and other values
of p map to the closer endpoint; if neither value is visible then
discrete animation is used.
This means that for visible (t=0) -> hidden (t=1) the timeline looks
like this:
- t=0.0: visible
- t=0.5: visible
- t=0.999…8: visible
- t=1.0: invisible
This means that for invisible (t=0) -> visible (t=1) the timeline looks
like this:
- t=0.0: invisible
- t=0.000…1: visible
- t=0.5: visible
- t=1.0: visible
So the value *is* instantly applied if the element is initially
invisible but when going the other direction this is not the case. This
happens whether or not the transition type is discrete.
While the spec calls out [`display` as working
similarly](https://drafts.csswg.org/css-display-4/#display-animation) in
practice this is only the case when `transition-behavior` is explicitly
set to `allow-discrete` otherwise the change is instant for both
directions.
Fixes#18793
This PR fixes an issue where `.hdr` files were scanned for candidates
even though it's a binary file.
As a workaround today, you could use:
```css
@source not "**/*.hdr";
```
To ignore `.hdr` files, but let's bake it in by default instead.
Fixes: #18733
## Summary
In Tailwind 3 the border colors were able to be used with `divide`
utilities. I made it so that's true for Tailwind 4.
## Test plan
Just used `pnpm run tdd` and making it fails then making sure it passes.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
Fixes#18695
Was waiting for 1.2.20 b/c of some build failures. Hopefully fixed now.
Also appears to fix the above linked bug about Windows symlinks.
[ci-all]
This PR fixes 2 false-positives when running the upgrade tool on a
Tailwind CSS v3 project converting it to a Tailwind CSS v4 project.
The issue occurs around migrations with short simple names that have a
meaning outside if Tailwind CSS, e.g. `blur` and `outline`.
This PR fixes 2 such cases:
1. The `addEventListener` case:
```js
document.addEventListener('blur', handleBlur)
```
We do this by special casing the `addEventListener(` case and making
sure the first argument to `addEventListener` is never migrated.
2. A JavaScript variable with default value:
```js
function foo({ foo = "bar", outline = true, baz = "qux" }) {
// ...
}
```
The bug is relatively subtle here, but it has actually nothing to do
with `outline` itself, but rather the fact that some quote character
came before and after it on the same line...
One of our heuristics for determining if a migration on these small
words is safe, is to ensure that the candidate is inside of a string.
Since we didn't do any kind of quote balancing, we would consider the
`outline` to be inside of a string, even though it is not.
So to actually solve this, we do some form of quote balancing to ensure
that it's _not_ inside of a string in this case.
Additionally, this PR also introduces a small refactor to the
`is-safe-migration.test.ts` file where we now use a `test.each` to
ensure that failing tests in the middle don't prevent the rest of the
tests from running.
### Test plan
1. Added dedicated tests for the cases mentioned in the issue (#18675).
2. Added a few more tests with various forms of whitespace.
Fixes: #18675
Since we (optionally) support source maps now it's possible that a later
PostCSS plugin that *still* does url rewriting might fail to do so
correctly because nodes will have preserved source locations in dev
builds where before we "pretended" that everything came from the
original file.
But, because we can't know if such a plugin is present, disabling this
behavior when source maps are enabled could cause issues *and* would be
a breaking change.
I wish everything *could just work* here but realistically we can't know
what plugins have run before our PostCSS plugin or what plugins will run
after so the best option (I think) we can offer here is to allow users
to disable url rewriting at the plugin level.
Fixes#16700
Fixes https://github.com/tailwindlabs/tailwindcss-typography/issues/384
Basically when addUtilities/addComponents/matchUtilities/matchComponents
saw a value of `false` it was being output instead of being discarded
like it was in v3.
The types really require these to be strings but for things like the
typography plugin this isn't really carried through from its theme
config so it was easy to put anything in there and not realize it
doesn't match the expected types.
Basically this:
```js
addUtilities({
'.foo': {
a: 'red',
'z-index': 0,
'.bar': false,
'.baz': null, // this one already worked
'.qux': undefined,
},
})
```
Now works like it did in v3 and omits `.bar`, `.baz`, and `.qux`
## Summary
Slang is basically a Slim template language for Crystal language, so the
very same Slim parser works fine.
Slim template: https://github.com/slim-template/slim
Slang template: https://github.com/jeromegn/slang
## Test plan
Create a simple slang file with some tailwind-css and check if the CSS
is being extracted:
```slim
doctype html
html
head
title This is a title
body.min-h-screen
header.stick.top-0.z-10
section.max-w-4xl.mx-auto.p-4.flex.items-center.justify-between
h1.text-3xl.font-medium This is a slang file
```
To test it, get any slim template, rename the extension to .slang
Fixes#17851
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
This PR tweaks the dropdown arrow added to an input by Chrome when it
has a `list` attribute pointing to a `<datalist>`.
Right now the arrow isn't centered vertically:
<img width="227" height="58" alt="Screenshot 2025-07-14 at 15 41 50"
src="https://github.com/user-attachments/assets/b354a5e8-432d-432d-bfe4-f7b6f6683548"
/>
The cause of this is the line height being inherited into the pseudo
element which controls how the marker is positioned. I *think* this is
because it's being drawn with unicode symbols but I'm not sure. It could
just be from the `list-item` display.
After this PR changes the line height its centered again:
<img width="227" height="58" alt="Screenshot 2025-07-14 at 15 42 05"
src="https://github.com/user-attachments/assets/1afa1f33-cc28-4b1f-9e04-e546f6848f57"
/>
Some notes:
This only affects Chrome and also does not appear to cause issues for
date/time inputs. While weird that this pseudo is the one used for a
`<datalist>` marker it is indeed correct.
Fixes#18499
Can use this Play to test the change:
https://play.tailwindcss.com/jzT35CRpr0
---------
Co-authored-by: Jonathan Reinink <jonathan@reinink.ca>
Fixes https://github.com/tailwindlabs/tailwindcss-forms/issues/182
Inside JS plugins and configs we weren't tracking source location info
so using things like `addBase(…)` could result in warnings inside Vite's
url rewriting PostCSS plugin because not all declarations had a source
location.
The goal here is for calls to `addBase` to generate CSS that points back
to the `@plugin` or `@config` that resulted in it being called.
Fixes#18431
The `~W(…)` syntax in Elixir is a _sigil_. It's basically another way to
write strings, arrays of strings, etc… The syntax lets you use a handful
of surrounding brackets like `~W(…)`, `~W[…]`, `~W{…}`, `~W"…"`, etc… to
let you write lists without necessarily having to escape characters.
In v3 our extractor was able to pick these up but in v4 Oxide does not.
I've added a preprocessor for Elixir files so we can modify the code
before our main extractor sees it.
Now things like this: `~W(text-white bg-gray-600)` will get turned into
` ~W text-white bg-gray-600 ` which can easily be processed by our
extractor.
The sigils we support are:
- `~s` / `~S` (strings)
- `~w` / `~W` (word lists)
- `~c` / `~C` (charlists)
We're specifically detecting the use of `(…)`, `[…]`, and `{…}` as using
quotes already works today.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
## Summary
In a form like,
```clojure
(if condition :bg-white :bg-black)
```
`:bg-black` will fail to extract, while `:bg-white` is extracted as
expected. This PR fixes this case, implements more comprehensive
candidate filtering, and supersedes a previous PR.
Having recently submitted a PR for handling another special case with
Clojure keywords (the presence of `:` inside of keywords), I thought it
best to invert the previous strategy: Instead of handling special cases
one by one, consume keywords according to the Clojure reader spec.
Consume nothing else, other than strings.
Because of this, this PR is a tad more invasive rather than additive,
for which I apologize. The strategy is this:
- Strings begin with a `"` and ends with an unescaped `"`. Consume
everything between these delimiters (existing case).
- Keywords begin with `:`, and end with whitespace, or one out of a
small set of specific reserved characters. Everything else is a valid
character in a keyword. Consume everything between these delimiters, and
apply the class splitting previously contained in the outer loop. My
previous special case handling of `:` inside of keywords in #18338 is
now redundant (and is removed), as this is a more general solution.
- Discard _everything else_.
I'm hoping that a strategy that is based on Clojure's definition of
strings and keywords will pre-empt any further issues with edge cases.
Closes#18344.
## Test plan
- Added failing tests.
- `cargo test` -> failure
- Added fix
- `cargo test` -> success
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
Fixes#18400
In v3 when you used `important: true` it did not affect `@apply`.
However, in v4 it does and there's no way to make it *not*. This is
definitely a bug and would be unexpected for users coming from v3 who
use `@apply` and `important` together.
Basically, the following code, along with the detected utility `flex` in
source files…
```css
@import 'tailwindcss/utilities' important;
.flex-explicitly-important {
@apply flex!;
}
.flex-not-important {
@apply flex;
}
```
… would output this:
```css
.flex {
display: flex !important;
}
.flex-explicitly-important {
display: flex !important;
}
.flex-not-important {
display: flex !important;
}
```
But it's expected that `@apply` doesn't consider the "global" important
state. This PR addresss this problem and now the output is this:
```css
.flex {
display: flex !important;
}
.flex-explicitly-important {
display: flex !important;
}
.flex-not-important {
display: flex; /* this line changed */
}
```
If you want to mark a utility as important in `@apply` you can still use
`!` after the utility to do so as shown above.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
Closes#18381
* [Changelog for Vite 7.0.0
(2025-06-24)](https://github.com/vitejs/vite/blob/main/packages/vite/CHANGELOG.md#700-2025-06-24)
Starting from Vite 7, Node 18 support will be dropped, which doesn't
really affect Tailwind. It might be worth mentioning in the
documentation that the recommended minimum Node versions are 20.19 and
22.12.
Vite 7 is only available in ESM format, which is also not an issue.
Vite's browser support aligns with the v4 guidelines:
```
Chrome 87 → 107 (tw: 111)
Edge 88 → 107 (tw: 111)
Firefox 78 → 104 (tw: 128)
Safari 14.0 → 16.0 (tw: 16.4)
```
* [Vite 7 - Browser
Support](https://vite.dev/guide/migration.html#default-browser-target-change)
* [Tailwind CSS v4 - Browser
Support](https://tailwindcss.com/docs/compatibility#browser-support)
So, at first glance, there's nothing more to do except enabling support
for these versions.
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
This PR fixes a regression we shipped in v4.1.9, when using arbitrary
values and injecting spaces around operator.
When you use `w-[calc(100%-var(--foo))]`, you expect that this generates
valid CSS:
```css
width: calc(100% - var(--foo));
```
But due to a regression, we generated:
```css
width: calc(100%-var(--foo));
```
Which is invalid CSS.
This is because the algorithm we used to know when we had to inject a
space around the `-` didn't take the `%` sign into account.
We also didn't handle uppercase units like `123PX` properly. This PR
fixes both issues.
## Test plan
1. Added a regression test for the `%`
2. Added a regression test for uppercase units like `123PX`
Fixes: #18288
Fixes#18219
## Summary
In an arbitrary value, if there's a non-numeric character both before
and after a hyphen, there's no need for a space.
## Test plan
`decodeArbitraryValue` will correctly format special CSS values like
`fit-content`. I believe spaces are only necessary if there's a digit
either before or after the hyphen.
```js
decodeArbitraryValue('min(fit-content,calc(100dvh-4rem))')
```
This way, the result of the following arbitrary value will also be
correct:
```html
<div class="min-h-[min(fit-content,calc(100dvh-4rem))]"></div>
```
```css
.min-h-\[min\(fit-content\,calc\(100dvh-4rem\)\)\] {
min-height: min(fit-content, calc(100dvh - 4rem));
}
```
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
Strings are not parsed correctly for custom properties which makes the
following CSS raise an `Unterminated string: ";"` error:
```css
:root {
--custom: 'data:text/plain;base64,SGVsbG8sIFdvcmxkIQ==';
}
```
According to the spec, we should accept semi-colon as long as they are
not at the top level.
> The allowed syntax for [custom
properties](https://drafts.csswg.org/css-variables/#custom-property) is
extremely permissive. The <declaration-value> production matches any
sequence of one or more tokens, so long as the sequence does not contain
bad-string-token, bad-url-token, unmatched )-token, ]-token, or }-token,
or top-level semicolon-token tokens or delim-token tokens with a value
of "!".
Extract from: https://drafts.csswg.org/css-variables/#syntax
I was only able to reproduce with **tailwindcss v4**, the previous
version seems to support this. This issue is mitigated by the fact that
even if you want to use a data URL in a custom property, you would need
to wrap the value in a `url()` anyway:
```css
:root {
--my-icon-url: url('data:image/svg+xml;base64,...==');
}
.icon {
background-image: var(--my-icon-url);
}
```
Which works perfectly fine with the current/latest version (v4.1.8).
The fix suggested is to share the same code between regular property and
custom property when it comes to detect that the value is a string
starting with a `SINGLE_QUOTE` or `DOUBLE_QUOTE`. I have moved the
existing code in a `findEndStringIdx` which returns the position of the
ending single/double quote.
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
This PR fixes an issue where the `blur` in `wire:model.blur="…"` was
incorrectly migrated. We solved it by marking `wire:…` as an unsafe
region (`…` can be anything but whitespace).
Fixes: #18187
## Test plan
Added a test with this use case
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
This PR adds some improvements to the upgrade tool where it can now also
migrate negative arbitrary values to negative bare values.
We already had support for the positive version of this:
```diff
- mb-[32rem]
+ mb-128
```
But now it can also handle negative values:
```diff
- mb-[-32rem]
+ -mb-128
```
The only tricky part here is that we had to hoist the `-` sign. Before
this PR, we were actually generating `mb--128` and that is invalid so it
was thrown out.
## Test plan
1. Added a test to ensure that the negative values are correctly
transformed.
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.:
```html
<div class="bg-[#f00]/[0.16]"></dv>
```
Will now be converted to:
```html
<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.:
```html
<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:
```html
<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:
```html
<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.
This PR improves error messages when `@apply` fails. Right now it gives
you a generic error message that you cannot apply a certain utility.
```css
.foo {
@apply bg-red-500;
}
```
Would result in:
```
Cannot apply unknown utility class: bg-red-500
```
However, there are some situations where we can give you more context
about what's happening.
### Missing `@import "tailwindcss"` or `@reference`
If you are in a Vue file for example, and you have the following code:
```vue
<template>
<div class="foo"></div>
</template>
<style>
.foo {
@apply bg-red-500;
}
</style>
```
Then this will now result in:
```
Cannot apply unknown utility class `bg-white`. Are you using CSS modules or similar and missing `@reference`? https://tailwindcss.com/docs/functions-and-directives#reference-directive
```
We do this by checking if we found a `@tailwind utilities` or
`@reference`. If not, we throw this more specific error.
### Explicitly excluded classes via `@source not inline('…')`
Or via the legacy `blocklist` from a JS config.
If you then have the following file:
```css
@import "tailwindcss";
@source not inline('bg-white');
.foo {
@apply bg-white;
}
```
Then this will now result in:
```
Cannot apply utility class `bg-white` because it has been explicitly disabled: https://tailwindcss.com/docs/detecting-classes-in-source-files#explicitly-excluding-classes
```
We do this by checking if the class was marked as invalid.
### Applying unprefixed class in prefix mode
If you have the prefix option configured, but you are applying a
non-prefixed class, then we will show the following error:
Given this input:
```css
@import "tailwindcss" prefix(tw);
.foo {
@apply underline;
}
```
The following error is thrown:
```
Cannot apply unprefixed utility class `underline`. Did you mean `tw:underline`?
```
### Applying known utilities with unknown variants
If you have unknown variants, then we will list them as well if the base
utility does compile correctly.
Given this input:
```css
@import "tailwindcss";
.foo {
@apply hocus:hover:pocus:bg-red-500;
}
```
The following error is thrown:
```
Cannot apply utility class `hocus:hover:pocus:bg-red-500` because the `hocus` and `pocus` variants do not exist.
```
## Test plan
1. Everything behaves the same, but the error messages give more
details.
2. Updated tests with new error messages
3. Added new unit tests to verify the various scenarios
4. Added a Vue specific integration test with a `<style>…</style>` block
using `@apply`
[ci-all] There are some newlines here and there, let's verify that they
work identically on all platforms.
---------
Co-authored-by: Jonathan Reinink <jonathan@reinink.ca>
This PR fixes a Haml pre-processing issue where a crash occurs if there
is no trailing `\n` at the end of the file and the code before it was
considered Ruby code.
This happens in situations where Ruby code was used. E.g.:
```
- index = 0
- index += 1
```
In this situation when we see the `-` on the second line, then we will
find the whole indented block and parse it as Ruby code instead. The
block ands at the last `\n`, but since we reach the end of the file,
there is no `\n`. Right now we incorrectly reset the internal cursor to
the last known `\n` position. This means that the `start` of the Ruby
block will be _after_ the `end` of the Ruby block and the Haml parser
will crash.
To solve this, once we reach the end of the file, we don't reset the
cursor to the wrong position.
Fixes:
https://github.com/tailwindlabs/tailwindcss/issues/17379#issuecomment-2910108646
## Test plan
1. Added a regression test that did fail before the fix, and doesn't
anymore
I was testing to upgrade tool on various random projects just to see how
it behaves. Then I noticed an odd migration...
This PR fixes an issue where the upgrade tool accidentally migrated
classes such as `mt-[0px]` to `-mt-[0px]`. The reason for this is
because we are trying to find a replacement, and the computed signature
for both of them are exactly the same.
- `mt-[0px]` translates to:
```css
.x {
margin-top: 0px;
}
```
- `-mt-[0px]` translates to:
```css
.x {
margin-top: calc(0px * -1);
}
```
Which in turn translates to
```css
.x {
margin-top: 0px;
}
```
Notice that this is `0px`, not `-0px`.
Internally we use the roots of functional utilities to find
replacements. For intellisense purposes we typically show negative
versions before positive versions. This then means that we will try
`-mt-*` before `mt-*`. Because of the signature above, the `mt-[0px]`
was translated into `-mt-[0px]`.
We could solve this in a few ways. The first thing we can try is to make
sure that the signature is not the same and that `-mt-[0px]` actually
translates into `-0px` not `0px`.
This would solve our problem of the accidental migration. However, if we
_just_ sort the functional utilities roots such that the positive
versions exist before negative version and rely on the fact that
`-mt-[0px]` has the same signature. Then it also means that by doing
that we can migrate `-mt-[0px]` into `mt-[0px]` which is even better
because it's the same result and shorter.
## Test plan
1. Added a test to verify that `mt-[0px]` does not get migrated to
`-mt-[0px]`.
2. Added a test to verify that `-mt-[0px]` does get migrated to
`mt-[0px]`.
This PR fixes a crash when an arbitrary value was malformed and crashed
the build.
If you have a utility like `[--btn-border:var(--color-maroon)/90)]`
which is malformed, it will crash the build. It might not be easy to
spot but the easy is the additional `)` after the `90`.
The reason this crashes is because we parse the value
`var(--color-maroon)/90)` and when we see `)` we assume it's the end of
a "function" which also assumes it was preceded by a `(`. This is not
the case and we crash.
This PR fixes that by not assuming the parsed object is available and
uses `?` to be safe and only access `nodes` if it's available.
I'm actually not 100% sure what the best solution is in this scenario
because these candidates could (and will) be returned from Oxide so even
if we throw a more descriptive error, it will still crash the build and
you might not even have control over the candidate.
This candidate will now eventually generate the following CSS:
```css
.\[--btn-border\:var\(--color-maroon\)\/90\)\] {
--btn-border: var(--color-maroon) / ;
}
```
Which still looks odd, but even Lightning CSS doesn't throw an error in
this case (because it's a CSS variable definition), so I think it's the
best we can do. If you open your devtools you will see the weird values,
so it's still debug-able.
<img width="359" alt="image"
src="https://github.com/user-attachments/assets/2eb48662-64de-4417-a2da-1577bf9075b5"
/>
Fixes: #17064
## Test plan
Manually tested the candidate that crashed it, and after the change
generated the above CSS. Then used it in JSFiddle to proof it's fixed
now. https://jsfiddle.net/z850ykew/
Couldn't use Tailwind Play because the candidate will cause a crash
there as well 😅
This PR adds an initial version for deprecated utilities. Right now it's
hardcoded to just the `order-none` utility.
This means that `order-0` and `order-[0]` will not be migrated to
`order-none` anymore. We did that automatically because we prefer named
utilities over bare values and arbitrary values.
With this PR, `order-none` is ignored.
Similarly, `order-none` will be migrated to `order-0` instead (defined
in a separate migration for deprecated values). Made it a new migration
instead of using the legacy migration because there all utilities still
exist, but are defined differently (e.g.: `shadow`, `shadow-sm`,
`shadow-xs`).
This PR is also an initial version, it doesn't add any form of
`deprecated` flag or feature on a per-utility implementation basis. This
therefor has the side effect that if you have a custom `order-none`
defined, that it will also be ignored during migrations.
## Test plan
1. Added tests to ensure the `order-0` is not migrated to `order-none`
2. Added tests to ensure `order-none` is migrated to `order-0` (if it's
safe to do so, the signature is still computed to ensure the output is
the same).
3. Ran this on the Tailwind Plus codebase and ensured that `order-0` is
not migrated to `order-none` and that `order-none` is migrated to
`order-0`.
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
<!--
👋 Hey, thanks for your interest in contributing to Tailwind!
**Please ask first before starting work on any significant new
features.**
It's never a fun experience to have your pull request declined after
investing a lot of time and effort into a new feature. To avoid this
from happening, we request that contributors create a discussion to
first discuss any significant new features.
For more info, check out the contributing guide:
https://github.com/tailwindcss/tailwindcss/blob/main/.github/CONTRIBUTING.md
-->
Fixes#18092
## Summary
Using the Svelte preprocessor for Rust files we can support Leptos
`class:` attributes syntax.
## Test plan
```
pnpm t
```
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
This PR improves the performance of the upgrade tool due to a regression
introduced by https://github.com/tailwindlabs/tailwindcss/pull/18057
Essentially, we had to make sure that we are not in `<style>…</style>`
tags because we don't want to migrate declarations in there such as
`flex-shrink: 0;`
The issue with this approach is that we checked _before_ the candidate
if a `<style` cold be found and if we found an `</style>` tag after the
candidate.
We would basically do this check for every candidate that matches.
Running this on our Tailwind UI codebase, this resulted in a bit of a
slowdown:
```diff
- Before: ~13s
+ After: ~5m 39s
```
... quite the difference.
This is because we have a snapshot file that contains ~650k lines of
code. Looking for `<style>` and `</style>` tags in a file that large is
expensive, especially if we do it a lot.
I ran some numbers and that file contains ~1.8 million candidates.
Anyway, this PR fixes that by doing a few things:
1. We will compute the `<style>` and `</style>` tag positions only once
per file and cache it. This allows us to re-use this work for every
candidate that needs it.
2. We track the positions, which means that we can simply check if a
candidate's location is within any of 2 start and end tags. If so, we
skip it.
Running the numbers now gets us to:
```diff
- Before: ~5m 39s
+ After: ~9s
```
Much better!
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
This PR fixes an issue where an error such as:
<img width="1702" alt="image"
src="https://github.com/user-attachments/assets/4e6f75c7-3182-4497-939e-96cff08c55ae"
/>
Will be thrown during the upgrade process. This can happen when you are
using `pnpm` and your CSS file includes a `@import "tailwindcss";`. In
this scenario, `tailwindcss` will be loaded from a shared `.pnpm` folder
outside of the current working directory.
In this case, we are also not interested in migrating _that_ file, but
we also don't want the upgrade process to just crash.
I didn't see an option to ignore errors like this, so wrapped it in a
try/catch instead.
It also fixes another issue where if you are using a pnpm workspace and
run the upgrade tool from the root, then it throws you an error that you
cannot add dependencies to the workspace root unless `-w` or
`--workspace-root` flags are passed.
For this, we disable the check entirely using the
`--ignore-workspace-root-check` flag. If we always used the
`--workspace-root` flag, then the dependencies would always be added to
the root, regardless of where you are running the script from which is
not what we want.
## Test plan
Before:
<img width="1816" alt="image"
src="https://github.com/user-attachments/assets/78246876-3eb6-4539-a557-d3d366f1b3a3"
/>
After:
<img width="1816" alt="image"
src="https://github.com/user-attachments/assets/a65e4421-d7c5-4d83-b35d-934708543e25"
/>
Before:
<img width="1816" alt="image"
src="https://github.com/user-attachments/assets/53772661-2c4a-4212-84d9-a556a0ad320f"
/>
After:
<img width="1816" alt="image"
src="https://github.com/user-attachments/assets/5bfaf20e-34b8-44fd-9b59-e72d36738879"
/>
This PR improves the upgrade tool by making sure that we don't migrate
CSS declarations in `<style>…</style>` blocks.
We do this by making sure that:
1. We detect a declaration, the current heuristic is that the candidate
is:
- Preceded by whitespace
- Followed by a colon and whitespace
```html
<style>
.foo {
flex-shrink: 0;
^ ^^
}
</style>
```
2. We are in a `<style>…</style>` block
```html
<style>
^^^^^^
.foo {
flex-shrink: 0;
}
</style>
^^^^^^^^
```
The reason we have these 2 checks is because just relying on the first
heuristic alone, also means that we will not be migrating keys in JS
objects, because they typically follow the same structure:
```js
let classes = {
flex: 0,
^ ^^
}
```
Another important thing to note is that we can't just ignore anything in
between `<style>…</style>` blocks, because you could still be using
`@apply` that we _do_ want to migrate.
Last but not least, the first heuristics is not perfect either. If you
are writing minified CSS then this will likely fail if there is no
whitespace around the candidate.
But my current assumption is that nobody should be writing minified CSS,
and minified CSS will very likely be generated and gitignored. In either
situation, replacements in minified CSS will not be any worse than it is
today.
I'm open to suggestions for better heuristics.
## Test plan
1. Added an integration test that verifies that we do migrate `@apply`
and don't migrate the `flex-shrink: 0;` declaration.
Fixes: #17975
This PR fixes an issue in the Clojure pre-processor where candidates
including `.` characters were not extracted correctly.
The solution here is to only replace the `.` with a ` ` when the `.` is
not surrounded by numbers. This means that:
```
:.foo.bar
```
Becomes
```
: foo bar
```
But
```
:.gap-1.5.flex
```
Becomes
```
: gap-1.5 flex
```
This way the `gap-1.5` is correctly extracted.
## Test plan
1. Added a test for this case
2. Tested this in the extractor tool as well. Notice how the `gap-1.5`
is correctly extracted here.
<img width="1247" alt="image"
src="https://github.com/user-attachments/assets/f5dd2600-5c5e-4ad8-88af-4e5be44340f5"
/>
Fixes: 17760
This PR makes the migrations for templates much faster. To make this
work, I also had to move things around a bit (so you might want to check
this PR commit by commit). I also solved an issue by restructuring the
code.
### Performance
For starters, we barely applied any caching when migrating candidates
from α to β. The problem with this is that in big projects the same
candidates will appear _everywhere_, so caching is going to be useful
here.
One of the reasons why we didn't do any caching is that some migrations
were checking if a migration is actually safe to do. To do this, we were
checking the `location` (the location of the candidate in the template).
Since this location is unique for each template, caching was not
possible.
So the first order of business was to hoist the `isSafeMigration` check
up as the very first thing we do in the migration.
If we do this first, then the only remaining code relies on the
`DesignSystem`, `UserConfig` and `rawCandidate`.
In a project, the `DesignSystem` and `UserConfig` will be the same
during the migration, only the `rawCandidate` will be different which
means that we can move all this logic in a good old `DefaultMap` and
cache the heck out of it.
Running the numbers on our Tailwind Plus repo, this results in:
```
Total seen candidates: 2 211 844
Total migrated candidates: 7 775
Cache hits: 1 575 700
```
That's a lot of work we _don't_ have to do. Looking at the timings, the
template migration step goes from ~45s to ~10s because of this.
Another big benefit of this is that this makes migrations _actually_
safe. Before we were checking if a migration was safe to do in specific
migrations. But other migrations were still printing the candidate which
could still result in an unsafe migration.
For example when migrating the `blur` and the `shadow` classes, the
`isSafeMigration` was used. But if the input was `!flex` then the safety
check wasn't even checked in this specific migration.
### Safe migrations
Also made some changes to the `isSafeMigration` logic itself. We used to
start by checking the location, but thinking about the problem again,
the actual big problem we were running into is classes that are short
like `blur`, and `shadow` because they could be used in other contexts
than a Tailwind CSS class.
Inverting this logic means that more specific Tailwind CSS classes will
very likely _not_ cause any issues at all.
For example:
- If you have variants: `hover:focus:flex`
- If you have arbitrary properties: `[color:red]`
- If you have arbitrary values: `bg-[red]`
- If you have a modifier: `bg-red-500/50`
- If you have a `-` in the name: `bg-red-500`
Even better if we can't parse a candidate at all, we can skip the
migrations all together.
This brings us to the issue in #17974, one of the issues was already
solved by just hoisting the `isSafeMigration`. But to make the issue was
completely solved I also made sure that in Vue attributes like
`:active="…"` are also considered unsafe (note: `:class` is allowed).
Last but not least, in case of the `!duration` that got replaced with
`duration!` was solved by verifying that the candidate actually produces
valid CSS. We can compute the signature for this class.
The reason this wasn't thrown away earlier is because we can correctly
parse `duration` but `duration` on its own doesn't exist,
`duration-<number>` does exist as a functional utility which is why it
parsed in the first place.
Fixes: #17974
## Test plan
1. Ran the tool on our Tailwind UI Templates repo to compare the new
output with the "old" behavior and there were no differences in output.
2. Ran the tool on our Tailwind Plus repo, and the template migration
step went from ~45s to ~10s.
3. Added additional tests to verify the issues in #17974 are fixed.
[ci-all] let's run this on all CI platforms...
