# For humans, by @RobinMalfait
## TL;DR
Some people ran into performance issues with the current `group-*`
variant because of the `*` inside of the selector. Take the
`group-focus-visible:flex` class for example, this generates:
```css
.group-focus-visible\:flex:is(:where(.group):focus-visible *) {
display: flex;
}
```
This slightly rewrites the selector by maintaining the same
functionality, but increasing performance because the browser has to do
fewer style recalculations.
That same class now produces:
```css
:is(:where(.group):focus-visible .group-focus-visible\\:flex) {
display: flex;
}
```
# For AI, generated by AI
This PR changes the selectors generated for `group-*` and `peer-*`
variants so browsers do less style recalculation when a group or peer
changes state (e.g. on focus or hover). Which elements match, and with
what specificity, stays the same, except for one deliberately accepted
edge case involving `@namespace` (see below).
```css
/* Before */
.group-focus\:flex:is(:where(.group):focus *) { display: flex; }
.peer-focus\:flex:is(:where(.peer):focus ~ *) { display: flex; }
/* After */
:is(:where(.group):focus .group-focus\:flex) { display: flex; }
:is(:where(.peer):focus ~ .peer-focus\:flex) { display: flex; }
```
## Why
In the old form, the subject inside `:is(…)` is `*`. When `.group`
changes state, Chromium has to recalculate styles for **every**
descendant of the group (or every following sibling of the peer), not
just the elements that use the utility. With the target itself in that
position, the browser can narrow invalidation down to elements matching
the target.
## Performance
Synthetic benchmark: toggle focus on a group/peer, flush style after
each change, and measure only a non-layout property (`outline-color`) to
isolate invalidation. Apple M5 Pro, macOS arm64.
**Elements recalculated per focus/blur** (Chromium 151,
`UpdateLayoutTree` `elementCount`, including the focused element):
| Scenario | Before | After |
| ------------------------------------------- | -----: | ------: |
| Group: 100 targets among 10,000 descendants | 10,001 | **101** |
| Peer: 20 targets among 2,000 siblings | 2,001 | **21** |
**Median time per focus/blur** (sparse: 1% of elements carry the
utility):
| Engine | Group: before → after | Peer: before → after |
| ------------ | ------------------------- | ------------------------- |
| Chromium 151 | 2.169 → **0.130 ms** (~17×) | 0.635 → **0.192 ms**
(~3.3×) |
| Firefox 153 | 0.500 → 0.350 ms | 0.650 → 0.600 ms |
| WebKit 26.5 | 0.750 → 0.750 ms | 0.450 → 0.450 ms |
**Dense case** (every element carries the utility): no meaningful
difference in any engine, because every element needs recalculation
anyway. Firefox's dense group case was ~5% slower (2.775 → 2.925 ms).
Everything else was within noise.
| Engine | Group dense: before → after | Peer dense: before → after |
| ------------ | --------------------------- |
-------------------------- |
| Chromium 151 | 4.027 → 3.971 ms | 18.095 → 18.121 ms |
| Firefox 153 | 2.775 → 2.925 ms | 43.900 → 44.025 ms |
| WebKit 26.5 | 7.550 → 7.425 ms | 35.325 → 35.100 ms |
These are micro-benchmarks of style updates, not page-load or frame-rate
numbers. The real-world gain depends on DOM size and how many elements
inside a group/peer use the variant. The biggest win is the common case:
a large group containing only a handful of `group-*` targets.
## Do the selectors behave the same?
Yes. For a group condition `G` and a target `&`:
- **Before:** matches `&` and has an ancestor matching `G`
- **After:** has an ancestor matching `G` and matches `&`
`peer-*` follows the same reasoning with `~`. Details:
- **Specificity is unchanged.** `:is()` takes the specificity of its
argument, so before was `spec(&) + spec(G)` and after is `spec(G) +
spec(&)`.
- **`&` is used, not the utility class**, so `@apply`, `@variant`,
`*:group-*`, `[&_p]:group-*`, and other variants that change the target
keep working. Complex parents such as `.foo .bar { @apply
peer-focus:flex }` keep `:is(…)` semantics during nesting: `:is(P ~
:is(.foo .bar))`.
- **`&` appears only once**, so stacked variants grow the selector
linearly. A unit test with 12 stacked variants guards against
exponential growth.
- **The selectors are also shorter:** 6 bytes of wrapping instead of 7.
- **The outer `:is(…)`** keeps compound variants such as `has-group-*`,
`not-group-*`, and `in-group-*` equivalent. For example, `has-group-*`
can still match when the group sits outside the element carrying the
utility.
**Accepted edge case:** if a stylesheet declares a default `@namespace`,
the old trailing `*` limited matches to elements in that namespace.
Inside compound variants such as `group-group-*` or `has-group-*`, the
new selector no longer does, so an SVG element (e.g. inside
`foreignObject`) can now count as the inner group. Appending `:is(*)` to
the target would restore the old behavior with no performance cost, but
it makes every selector longer for a combination (`@namespace` + mixed
namespaces + compound group variants) that is very unlikely in practice.
We can add it back if anyone runs into this.
There's one known browser quirk this PR doesn't change: Chromium doesn't
invalidate `has-group-*` when the focused group is an ancestor *outside*
the element. That happens with both the old and new selectors.
## Test plan
- [x] Updated unit test snapshots for the new selector shape
- [x] New unit test that bounds selector size with 12 stacked variants
- [x] New browser tests in `packages/tailwindcss/tests/ui.spec.ts`, run
in Chromium, Firefox, and WebKit. They cover `group-*`/`peer-*` focus
and blur, `@apply` inside a complex selector, specificity, stacked
groups in either order, and compound `group-peer-*`/`peer-group-*`. The
pre-PR selectors pass all of them too, so behavior is unchanged
- [x] `pnpm run test` and `pnpm run test:ui` pass
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
<!--
👋 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/tailwindlabs/tailwindcss/blob/main/.github/CONTRIBUTING.md
-->
## Summary
<!--
Provide a summary of the issue and the changes you're making. How does
your change solve the problem?
-->
The CSS parser treated `\` inside comments as an escape and skipped the
character after it. Because of that, a comment ending in `\*/` was never
closed, and the CSS that followed was swallowed or turned into a broken
rule:
```css
/* C:\temp\*/
.a { color: red }
```
Before this change the `.a` rule disappeared entirely, and `/* \*/ .a {
color: red }` produced the selector `* \*/ .a`. The same thing happened
to comments inside declaration values, where the comment ran on until
the next `*/` it could find, pulling following declarations into the
value.
Per [CSS Syntax Level 3
§4.3.2](https://www.w3.org/TR/css-syntax-3/#consume-comment), a comment
ends at the first `*/` and escapes aren't processed inside comments.
This removes the backslash handling from both comment-scanning loops in
`css-parser.ts` (top-level and inside declaration values).
The existing test `/*Hello, \*\/ world!*/` keeps passing, since that
input contains no `*/` before the final one.
## Test plan
<!--
Explain how you tested your changes. Include the exact commands that you
used to verify the change works and include screenshots/screen
recordings of the update behavior in the browser if applicable.
-->
Added two tests to `packages/tailwindcss/src/css-parser.test.ts` (both
run with Unix and Windows line endings):
- a top-level comment ending in `\*/` followed by a rule
- a comment ending in `\*/` inside a custom property value, followed by
another declaration
Both fail without the change to `css-parser.ts` and pass with it.
```sh
pnpm vitest run packages/tailwindcss/src/css-parser.test.ts
pnpm vitest run --project tailwindcss
pnpm run lint
```
---------
Co-authored-by: Robin Malfait <robin.malfait@shopify.com>
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
## Summary
`compareBreakpoints` compared values in the same unit with `parseInt`,
which drops the fractional part, so `40.25rem` and `40.5rem` were
treated as equal. As a result `min-[40.5rem]:*` could be emitted before
`min-[40.25rem]:*` (the same happened for `@min-*` container queries),
which means the smaller breakpoint wins in the cascade. This switches
the comparison to `parseFloat` so decimal values are ordered
numerically; values that were already sorted correctly are unaffected.
## Test plan
- Added a test to `packages/tailwindcss/src/variants.test.ts` that sorts
`min-[40.25rem]`, `min-[40.5rem]`, `max-[40.25rem]` and `max-[40.5rem]`.
It fails without the change (the `min-[40.5rem]` rule is emitted before
`min-[40.25rem]`) and passes with it.
- `vitest run src/variants.test.ts -t "decimal values"` (in
`packages/tailwindcss`)
- `vitest run` (in `packages/tailwindcss`): 42 files, 5009 tests passed
- `prettier --check` on the changed files
<!--
👋 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/tailwindlabs/tailwindcss/blob/main/.github/CONTRIBUTING.md
-->
## Summary
<!--
Provide a summary of the issue and the changes you're making. How does
your change solve the problem?
-->
`segment()` preserves empty top-level segments, but the candidate and
variant parsers currently use the truthiness of the third segment to
detect additional modifiers.
As a result, inputs such as `bg-red-500/50/`, `bg-red-500/50//foo`,
`group-hover/foo/:flex`, and `group-hover/foo//bar:flex` can be parsed
as valid candidates even though they contain multiple slash modifier
segments.
This change checks the number of segments instead of the value of the
third segment. Single modifiers such as `bg-red-500/50` and
`group-hover/foo:flex` continue to parse normally, while all additional
top-level `/` segments are rejected.
## Test plan
<!--
Explain how you tested your changes. Include the exact commands that you
used to verify the change works and include screenshots/screen
recordings of the update behavior in the browser if applicable.
-->
- `pnpm exec vitest run packages/tailwindcss/src/candidate.test.ts
--hideSkippedTests`
- `pnpm exec vitest run packages/tailwindcss/src --hideSkippedTests`
- `pnpm exec prettier --check packages/tailwindcss/src/candidate.ts
packages/tailwindcss/src/candidate.test.ts`
`pnpm --filter=tailwindcss lint` was also attempted, but currently fails
on existing cross-package dependency and Bun type errors unrelated to
this change.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
Fixes#20433.
The warning filter in `optimize.ts` already ignores `:deep()`,
`:slotted()` and `:global()`. Angular's two deep selectors are the same
kind of thing — non-standard pseudo-selectors that the framework's
compiler resolves before the CSS reaches a browser — but they aren't
covered, so every Angular component stylesheet using them prints a
warning block per occurrence.
```
Found 2 warnings while optimizing generated CSS:
Issue #1:
│ :host ::ng-deep .some-child, :host
┆ ^-- 'ng-deep' is not recognized as a valid pseudo-element. Did you mean ':ng-deep' (pseudo-class) or is this a typo?
```
Angular strips both during view-encapsulation shimming — `::ng-deep` via
`_shadowDeepSelectors = /(?:>>>)|(?:\/deep\/)|(?:::ng-deep)/g`, and
`:host-context()` in the same pass — so neither ever reaches a browser.
Worth noting that `/deep/` and `>>>`, Angular's two other spellings of
the deep selector, already pass silently because
`nonStandard.deepSelectorCombinator` is enabled. `::ng-deep` is the only
one that warns, and it's the spelling the Angular docs use — so in
practice every Angular codebase hits this. On the workspace where I ran
into it (7 Angular apps), a production build printed 425 `ng-deep`
warnings and 2 `host-context` ones.
## Test plan
There's no automated coverage here because the warning path is behind
`process.env.NODE_ENV !== 'test'`, so a spy sees nothing under Vitest
regardless of the filter — the same reason #20277 shipped without one.
Instead I ran the file before and after the change against Lightning CSS
1.33.0 directly, counting emitted warning blocks:
| Input | Before | After |
| --- | --- | --- |
| `:host ::ng-deep .a, :host ::ng-deep .b { … }` | 1 | 0 |
| `:host-context(.dark) .a { … }` | 1 | 0 |
| `:deep(.a) { … }` | 0 | 0 |
| `.a::totally-not-real { … }` — genuine typo | 1 | **1** |
Generated CSS is byte-identical before and after; only the warning is
suppressed. Genuine unknown pseudo-selectors still warn, so the typo
hint the message exists for is preserved.
Happy to restructure this if you'd prefer the predicate extracted so it
can be unit-tested, or to split `ng-deep` and `host-context` into their
own block rather than extending the existing regex.
A minimal reproduction of the original issue is at
https://gist.github.com/weilinzung/ace42ceb95c2f47b6747cc1f34f162bd.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
<!--
👋 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/tailwindlabs/tailwindcss/blob/main/.github/CONTRIBUTING.md
-->
## Summary
Hi guys, thanks for you great work!
I work on performance improvements on
https://github.com/schoero/eslint-plugin-better-tailwindcss project.
Part of issues can be fixed on the tailwind side only.
This is a first fix, I have a bigger one in mind, it would require a
small additional public API method - out of scope of this PR.
Please let me know what you think.
## Finding
`getVariantOrder()` re-sorts all parsed variants with the (expensive)
variant comparator on every call, and it is called by every
compileCandidates() invocation — per build pass, per @apply
substitution, and hundreds of times during candidate canonicalization
via the variant signature caches. Since parsedVariants is append-only,
the computed order only changes when a new variant is parsed, so we can
cache the result and invalidate on parsedVariants.size. This makes cold
canonicalization (IntelliSense, lint plugins) faster and removes
repeated sorting from @apply substitution and incremental rebuilds.
## Test plan
Tested at https://github.com/smnbbrv/better-tailwindcss-bench . The
relevant part is the `epbt-now / tw-patched`
**plugin cost** (ms, cold run net of parse baseline)
| codebase | epbt-now / tw-now | epbt-patched / tw-now | epbt-now /
tw-patched | epbt-patched / tw-patched |
| ---------- | ----------------: | --------------------: |
--------------------: | ------------------------: |
| mixed | 6292 | 3965 (-37%) | 5395 (-14%) | 3595 (-43%) |
| repetitive | 5279 | 2425 (-54%) | 4819 (-9%) | 2124 (-60%) |
| unique | 6096 | 5458 (-10%) | 5507 (-10%) | 5295 (-13%) |
## Summary
The `supports-[…]` variant works around a Chrome bug where `@supports
(a)or(b)`
is invalid by spacing out the `and`, `or`, and `not` keywords. However,
the
replacement is applied to the entire value, including the inside of
function
calls, where these words can be part of a selector.
For example, `supports-[selector(a:not(.foo))]:flex` generates:
```css
@supports selector(a: not (.foo))
```
The selector `a: not (.foo)` is unparsable, so a condition that is true
in
every browser silently becomes false and the utility never applies. The
same
happens to class names like `.and` or `.or` inside `selector(…)`.
This PR only spaces out the keywords at the condition level: parens
preceded by
an identifier (other than the keywords themselves) start a function
call, and
everything inside is left as-is. The Chrome workaround still applies to
the
condition itself, e.g. `supports-[(display:grid)or(display:flex)]` still
becomes `@supports (display: grid) or (display: flex)`.
## Test plan
- Added a test covering `selector(a:not(.foo))`, class names
`.and`/`.or`
inside `selector(…)`, the Chrome `(a)or(b)` workaround, and a top-level
`not(…)` condition.
- `pnpm vitest run packages/tailwindcss/src/variants.test.ts` — 102
passed.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
## Summary
Modifiers on functional utilities that resolve a named theme value are
silently
dropped instead of invalidating the candidate. For example, with the
default theme:
- `rounded-sm/[5]` emits the same CSS as `rounded-sm` (the `[5]` is
ignored)
- `shadow-sm/foo`, `inset-shadow-sm/foo`, `text-shadow/foo`, and
`drop-shadow/foo`
emit the full shadow CSS with the invalid `foo` modifier ignored
This is inconsistent with how every sibling code path behaves:
`rounded/foo`,
`rounded-[4px]/foo`, `rounded-sm/5`, and `drop-shadow-xl/foo` all
correctly
produce no output, because those paths check `candidate.modifier`.
This PR adds the missing guards:
- In the generic `functionalUtility` handler, a candidate whose named
value
resolves from the theme now rejects modifiers (except fractions like
`w-1/2`,
where the modifier is part of the resolved value).
- The `shadow`, `inset-shadow`, and `text-shadow` utilities now apply
the same
`if (candidate.modifier && !alpha) return` guard in their default-value,
arbitrary-value, and named-size branches that `drop-shadow` already
applies,
and `drop-shadow` gets it in its default-value branch too.
Existing tests asserting candidates like `drop-shadow/foo` produce no
output were
passing for the wrong reason: they run without a theme, so the theme
lookup fails
before the modifier is ever considered. The new tests provide a theme so
the
invalid modifier is what invalidates the candidate.
## Test plan
- Added assertions to the `rounded`, `filter`, `shadow`, `inset-shadow`,
and
`text-shadow` tests that compile candidates with invalid modifiers
against a
theme that defines the relevant values, and expect no output. All of
them fail
without the fix.
- `pnpm vitest run packages/tailwindcss/src/utilities.test.ts` — 398
passed.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
This PR fixes an issue where canonicalization suggestions in
intellisense result in 'weird' suggestions.
```
The class text-foreground/60 can be written as text-default-soft-hover
```
If we look at the CSS provided by the issue, this doesn't immediately
make sense:
```css
@theme {
--color-foreground: var(--foreground);
--color-default-soft-hover: color-mix(in oklab, var(--default) 60%, transparent);
}
:root {
--foreground: oklch(0.2103 0.0059 285.89); /* near-black */
--default: oklch(94% 0.001 286.375); /* light gray */
}
```
But it turns out that when you use Uniwind (React Native) with HeroUI,
that the setup looks more like this:
```css
@import 'tailwindcss';
@theme {
--foreground: unset;
--default: unset;
}
@theme inline {
--color-foreground: var(--foreground);
--color-default-soft-hover: color-mix(in oklab, var(--default) 60%, transparent);
}
```
During the canonicalization step, we inline all the `@theme` values, the
reason for this is that `text-[#fff]` can be turned into `text-white`
even though they look slightly different:
```css
.text-\[\#fff\] {
color: #fff;
}
.text-white {
color: var(--color-white, #fff);
}
```
But when we inline them, it looks like this:
```css
.text-\[\#fff\] {
color: #fff;
}
.text-white {
color: #fff;
}
```
Internally, we use signatures to make sure that they are safe to be
subtituted with eachother. In this case, the signatures will look like
this:
```css
.x {
color: #fff;
}
.x {
color: #fff;
}
```
If we now look at the signatures of the original issue, you would see:
```css
/* text-foreground/60 */
.x {
color: color-mix(in_oklab,unset_60%,transparent);
}
/* text-default-soft-hover */
.x {
color: color-mix(in_oklab,unset_60%,transparent);
}
```
That's because the `@theme` variables were inlined, resulting in the
exact same signature, thus we consider them the same.
This PR makes sure to never inline [CSS-wide
keywords](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Values/Data_types#css-wide_keywords)
(such as `unset`) and therefore keeping the CSS variable reference:
```css
/* text-foreground/60 */
.x {
color: color-mix(in_oklab,var(--foreground)_60%,transparent);
}
/* text-default-soft-hover */
.x {
color: color-mix(in_oklab,var(--default)_60%,transparent);
}
```
Fixes:
https://github.com/tailwindlabs/tailwindcss-intellisense/issues/1610
## Test plan
1. Existing tests pass
2. Added a regression test
Checked manually in the regression repo
Before:
<img width="1358" height="421" alt="image"
src="https://github.com/user-attachments/assets/8ab3de97-17e4-4e11-b335-bb37218ff2ee"
/>
After:
<img width="1177" height="247" alt="image"
src="https://github.com/user-attachments/assets/cbbfcf04-3ed3-4fa7-a3eb-ef607239f4ad"
/>
---------
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
Instead of writing debug logs (triggered by using `DEBUG=*`) in the root
of the project as `tailwindcss-<pid>.log`, we will write them to
`.tailwindcss/logs/scanner-<timestamp>-<pid>.log` instead.
The reasoning for this is that we won't pollute the root of the project.
Another reason is that if you don't ignore `.log` files via
`.gitignore`, it could be that you end up in a loop if you use `DEBUG=*
vite` because a new `.log` file might trigger a new build. We noticed
this while looking at
https://github.com/tailwindlabs/tailwindcss/discussions/20382.
The `.tailwindcss` folder will come with a `.gitignore` file that
ignores everything (`*`).
## Test plan
1. Nothing really changed here, all tests should pass
Testing this in a local project, it looks like this:
<img width="483" height="165"
alt="file-35bfc43606c556f2380a161c7595d103"
src="https://github.com/user-attachments/assets/629519c8-8f2b-46ee-8046-9ba3749f319a"
/>
This PR removes all of the custom HMR handling we had in the
`@tailwindcss/vite` plugin.
When Vite 7.1 was introduced, Vite stopped performing a full page reload
for unknown files and instead started performing normal `hmr` updates.
This resulted in this issue:
https://github.com/tailwindlabs/tailwindcss/issues/19637
At the time, it felt like something we could easily re-add: if a file is
not covered by Vite, we can perform a `full-reload`. This meant that a
`.php` file would trigger a full page reload as expected.
The reason the `.php` file triggered Vite in the first place is because
those files were scanned by us (`@tailwindcss/vite`) so it made sense.
However, this then resulted in a plethora of issues, and it feels a bit
like a game of whac-a-mole.
- https://github.com/tailwindlabs/tailwindcss/issues/19744
- https://github.com/tailwindlabs/tailwindcss/issues/19903
- https://github.com/tailwindlabs/tailwindcss/issues/20320
- https://github.com/tailwindlabs/tailwindcss/issues/20378
- https://github.com/tailwindlabs/tailwindcss/issues/20411Fixes: #19744Fixes: #19903Fixes: #20320Fixes: #20378Fixes: #20411
We kept updating the logic by safelisting certain extensions, checking
different servers and/or environments, handling the fact that `server`
in the callback could be absent in `experimental.bundledDev` mode, etc.
etc.
Now, when investigating the last issue
(https://github.com/tailwindlabs/tailwindcss/issues/20411), I can
trigger full reloads by changing `.json`, `.yaml` or `.svg` files. This
makes sense since they aren't handled by default.
So thinking about this more, I think it's just not Tailwind's
responsibility to tell Vite to reload the browser or not. Yes, we use
the `addWatchFile` API, so files are being watched because of us.
However, our only goal is to update the `.css` file (and HMR that).
This means that we can just drop all the custom HMR handling we have in
`@tailwindcss/vite`.
This also means that
https://github.com/tailwindlabs/tailwindcss/issues/19637 would regress
and won't trigger full page reloads. But this can be easily handled by a
plugin responsible for this behavior:
- https://github.com/ElMassimo/vite-plugin-full-reload
## Test plan
1. All tests pass
2. Manually tested and changing unknown files don't result in a full
page reload
## Summary
Replace the three unchecked scanner conversions in
`crates/oxide/src/scanner/mod.rs` with checked conversions that omit
only extracted slices that are not valid UTF-8. Apply the check in the
shared `extract` pipeline so initial scans, incremental `scan_content`
calls, and CSS-variable extraction cannot insert invalid strings into
scanner state, and apply the same policy to both branches of
`get_candidates_with_positions` while preserving byte offsets and the
legacy `-[]` restoration. Keep the extractor's byte-oriented CSS
identifier classification unchanged: accepting non-ASCII bytes during
extraction is useful for valid multibyte code points, while the
conversion boundary is the authoritative place to enforce the `String`
contract.
The scanner currently converts extracted byte slices with unchecked
UTF-8 constructors at the shared extraction boundary and both
candidate-with-position branches. A source file containing a stray
continuation byte can therefore produce an invalid `String`, violating
Rust's string invariant and allowing corrupted candidates to persist in
a long-lived scanner. The thread provides a deterministic reproduction
using invalid bytes inside an arbitrary value, so the problem no longer
depends on reproducing the originally reported Turbopack race. Valid
candidates found alongside malformed byte sequences must continue to be
returned normally.
Fixes#20368
## Test plan
Not applicable to this change.
AI was used for assistance.
---------
Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
This PR improves the scanner related tests a bit. Right now all the
scanner tests (a lot of them) are somewhat hard to reason about and to
figure out whether these are actually correct or not.
With this PR, the existing are extended with a visualization of the file
system tree, but with indicators to know whether or not a file was
scanned or not. If a `.gitignore` is present, it's content is also shown
to make it easier to see why some files are included or not included.
One of the outputs look like this:
```
.
├── ✗ .gitignore
│ src/ignored-by-gitignore.html
└── ✓ src
├── ✗ ignore-by-extension.bin
├── ✓ ignored-by-gitignore.html
├── ✗ ignored-by-source-not.html
├── ✓ keep-me.html
└── ✓ new-file.html
```
I'm sure we can cleanup a lot of these tests, simplify, deduplicate, but
I didn't want to do that as part of this PR. This PR is purely adding
this visualization.
This uses the [insta.rs](https://insta.rs) library for (inline) snapshot
tests. If at some point the snapshots change, then you get a nice UI:
<img width="958" height="670" alt="image"
src="https://github.com/user-attachments/assets/652cf48f-e1b1-4fe5-a42a-29c5a888063a"
/>
## Test plan
1. All tests should pass [ci-all]
2. Nothing in the code itself changed, so nothing should break
---
<sub>Stack created with <a
href="https://github.com/github/gh-stack">GitHub Stacks CLI</a> • <a
href="https://gh.io/stacks-feedback">Give Feedback 💬</a></sub>
This PR updates the vendored `ignore/` crate to make use of the upstream
improvements.
We can't fully use the native `ignore` crate yet because of the missing
functionality that we added ourselves. Our own changes are still marked
as `CHANGED:`
## Test plan
1. All tests should still pass [ci-all]
---
<sub>Stack created with <a
href="https://github.com/github/gh-stack">GitHub Stacks CLI</a> • <a
href="https://gh.io/stacks-feedback">Give Feedback 💬</a></sub>
<!--
👋 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/tailwindlabs/tailwindcss/blob/main/.github/CONTRIBUTING.md
-->
## Summary
<!--
Provide a summary of the issue and the changes you're making. How does
your change solve the problem?
-->
## Test plan
<!--
Explain how you tested your changes. Include the exact commands that you
used to verify the change works and include screenshots/screen
recordings of the update behavior in the browser if applicable.
-->
Preface: For full transparency, I used AI (Claude) to help dig into this
issue we're having and write some of the explanation below.
Our local Laravel application (with Docker) takes between 2-6s seconds
(re)building `app.css` after each Blade file update. After checking with
Claude, there seems to be some potential unnecessary traversing of big
(gitignored) directories, specifically `vendor` and `storage`.
As far as I understand it, two scans happen in tailwindcss:
- a first scan, the content scan. This one reads the project files
(auto-detect). It respects .gitignore, so it correctly skips vendor/ and
storage/.
- a second scan, the glob resolution (resolve_globs() in the oxide
crate). It builds watch patterns that the Vite plugin registers, so a
file save can trigger a CSS rebuild. It walks the project again, but
this walk does not respect .gitignore. It only skips a hardcoded list of
directory names from `ignored-content-dirs.txt` (node_modules, .git,
venv, ...). vendor/ and storage/ are not on that list, so it descends
into them and stats every file. These directories can never produce a
watch pattern, because the content scan never visited them. That work is
perhaps wasted?
Maybe why this went unnoticed: on a native filesystem a stat takes about
1µs, so 57k of them is around 0.06s. A Docker bind mount multiplies that
by roughly 100. And the big directory in a typical JS project is
`node_modules`, which the name list already catches; `vendor/` is the
PHP ecosystem's `node_modules`, and it is not on that list. (#19616 /
#19632 fixed the same problem for `scanner.files`; the CLI never reads
`scanner.globs`, so it was never affected.)
The fix: the second walk now skips any directory the scan never visited,
the same pruning the first walk (line 73) already does.
Measured on our local project: `get_globs()` after `scan()` went from
9.9s to somewhere between 0.2 and 1.0s across runs, with identical
output (35 globs). A template save now reloads in about 0.3s instead of
4.
## Test plan
- `cargo test` in `crates/oxide`: 66 tests pass, including the glob
assertions for nested and gitignored directories in `tests/scanner.rs`.
- Compared the sorted `get_globs()` output before and after on the
project above: identical.
I've also set up a repo that reproduces the issue in a fresh Laravel
app:
https://github.com/marickvantuil/tailwind-scan-reproduce
The results:
| Environment | vendor/ | scan | get_globs | syscalls under vendor/ |
| --- | --- | --- | --- | --- |
| GitHub Actions (native FS) | present | 5.0 ms | 48.8 ms | 11,410 |
| GitHub Actions (native FS) | absent | 4.5 ms | 0.9 ms | n/a |
| macOS, Docker bind mount | present | 15.8 ms | 599.4 ms | 11,410 |
| macOS, Docker bind mount | absent | 16.5 ms | 6.5 ms | n/a |
---------
Co-authored-by: Marick van Tuil <marick@dolphiq.nl>
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
When building the legacy config compat layer, namespace mappings like
`fontSize` → `text`, `boxShadow` → `shadow`, `animation` → `animate`,
etc. spread the result of `theme(namespace, {})` directly:
```ts
...(theme('text', {}) ?? {})
```
Some of these namespaces can return a **string** (e.g. `theme('text',
{})` → `'1rem'`). Spreading a string produces char-indexed keys (`{ '0':
'1', '1': 'r', ... }`) instead of a `{ DEFAULT: ... }` entry, silently
corrupting the compat config output.
This PR adds a small `spreadTheme` helper that normalizes the return
value before spreading:
- `string` → `{ DEFAULT: value }`
- plain object → `{ ...value }`
- anything else → `{}`
and updates all namespace mappings to use it. Includes unit tests for
the helper plus integration tests for the affected namespaces and the
string-return regression cases.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
This PR fixes an issue where the `--default(…)` function that can be
used as part of `@utility` definitions goes through the same
pre-processing treatment as `--value(…)` and `--modifier(…)`.
Instead the `--default(…)` value should be emitted as-is.
The pre-processing treatment that's in place today is just to normalize
the value(s) that could be formatted in a strange way if you are dealing
with older Prettier / Biome versions.
Some of the transformations we do ahead of time:
- `--value(--spacing)` -> `--value(--spacing-*)`
- `--value(--spacing- *)` -> `--value(--spacing-*)`
- `--value(--text- * --line-height)` -> `--value(--text-*--line-height)`
- `--value(--text --line-height)` -> `--value(--text-*--line-height)`
- `--value(--text-\\* --line-height)` ->
`--value(--text-*--line-height)`
- `--value([ *])` -> `--value([*])`
One of these steps is getting rid of the spaces, that means that if your
`--default(…)` uses spaces, then we will get rid of it.
```css
@theme inline {
--text-box-trim-start: trim-start;
--text-box-trim-end: trim-end;
--text-box-trim-both: trim-both;
--text-box-edge-cap: cap alphabetic;
--text-box-edge-cap-text: cap text;
--text-box-edge-ex: ex alphabetic;
--text-box-edge-ex-text: ex text;
--text-box-edge-text: text alphabetic;
--text-box-edge-text-text: text text;
}
@utility trim-* {
text-box: --value('normal', 'inherit', 'initial', 'revert', 'revert-layer', 'unset');
text-box: --value(--text-box-trim-*) --modifier(--text-box-edge-*, --default(box alphabetic));
}
```
When you try to use this:
```html
<div className="trim-both" />
```
Then we get the following CSS out:
```css
.trim-both {
text-box: trim-both boxalphabetic;
}
```
This PR fixes that, and now the proper CSS will be emitted:
```css
.trim-both {
text-box: trim-both box alphabetic;
}
```
Fixes: #20391
## Test plan
1. Added an regression test to make sure that `--default(…)` values are
emitted as-is.
## Summary
Fixes#20386.
Ruby lets you close a `%w`/`%W` literal with any non-alphanumeric
character, but the pre-processor only recognized `[`, `(`, `{`, `#` and
a space. So `%w<bg-green-400>` and `%w|bg-blue-400|` were skipped and
the classes inside them never made it into the output.
The boundary lookup now maps `<` to `>` alongside the other paired
delimiters, and falls back to treating any other non-alphanumeric,
non-whitespace character as its own closing delimiter.
## Test plan
Added pre-processor and extraction cases for `%w<…>`, `%w|…|`, `%w:…:`
and `%w!…!` in `crates/oxide/src/extractor/pre_processors/ruby.rs`. They
fail on `main` and pass with this change.
```
cargo test -p tailwindcss-oxide
```
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
One of the integration tests is flaky on CI. This is an attempt to "fix"
it.
It has probably something to do with the availability of the resources
provided by GitHub because locally this works flawlessly for 100 runs
straight.
## Test plan
- Once we get 5 consecutive positive runs we van merge it.
- No actual code was changed, only the flaky integration test itself.
<img width="336" height="445" alt="image"
src="https://github.com/user-attachments/assets/bec81687-62f5-4df3-8109-d0aaa4ffbd8a"
/>
Right now, we use Rust for `@tailwindcss/oxide` which has 2
responsibilities:
1. Traverse the file system and figure out which files need to be
scanned based on auto source detection and `@source` directives.
2. Given those files, extract possible Tailwind CSS classes which we
call candidates.
Since this is using native code, we use napi-rs to get native `.node`
files on a per platform / arch basis.
So far so good, however, if you are on an OS that doesn't have a
prebuilt binary, you will receive an error that might look like this:
```
Error: Cannot find native binding. npm has a bug related to optional dependencies (https://github.com/npm/cli/issues/4828). Please try `npm i` again after removing both package-lock.json and node_modules directory.
at Object.<anonymous> (/private/var/folders/1k/bdv8blv93xq7qgwjdwc9z88h0000gn/T/tailwind-integrationspYHIVP/node_modules/.pnpm/@tailwindcss+oxide@file+..+..+..+..+..+..+..+Users+robin+github.com+tailwindlabs+tailwi_47ae1688f61c719f66c73e2ff35e430f/node_modules/@tailwindcss/oxide/index.js:573:19)
at Module._compile (node:internal/modules/cjs/loader:1829:14)
at Object..js (node:internal/modules/cjs/loader:1969:10)
at Module.load (node:internal/modules/cjs/loader:1552:32)
at Module._load (node:internal/modules/cjs/loader:1354:12)
at wrapModuleLoad (node:internal/modules/cjs/loader:255:19)
at Module.require (node:internal/modules/cjs/loader:1575:12)
at require (node:internal/modules/helpers:191:16)
at file:///private/var/folders/1k/bdv8blv93xq7qgwjdwc9z88h0000gn/T/tailwind-integrationspYHIVP/index.mjs:5:19
at ModuleJob.run (node:internal/modules/esm/module_job:437:25) {
cause: Error: Cannot find module '@tailwindcss/oxide-darwin-arm64'
```
This means that we have to add support for these platforms, and there
are some open PRs related to this, which could be closed by this PR:
- #20327
- #20276
- #20201
Today we already have support for the big platforms out there:
- Windows arm64
- Windows x64
- macOS arm64
- macOS x64
But then it starts to get a bit out of hand once we start looking at
Linux based versions:
- Android arm eabi
- Android arm64
- Linux arm64 gnu
- Linux arm64 gnueabihf
- Linux arm64 musl
- Linux x64 gnu
- Linux x64 musl
- freebsd x64
... and then we have the pending list from the 3 PRs linked above.
Adding support for all of these is not the end of the world, but it gets
complex if we need to keep supporting more and more. Right now we rely
on a bunch of non-default napi-rs setup in CI just to support these
other platforms.
This PR solves that by using the `wasm32-wasi` build as a universal
fallback. The napi-rs generated loader already knows how to fall back to
`@tailwindcss/oxide-wasm32-wasi`, but that package declared `"cpu":
["wasm32"]`, so npm/pnpm never installed it on real hardware. Removing
that restriction means the package is installed everywhere, and the
loader picks it up whenever no native binding exists.
This PR also fixes a `UVWASI_EACCES` crash on sandboxed platforms
(OpenHarmony, Android): the generated wasm loader preopens `/`, which
those sandboxes deny, so the fallback failed to load on exactly the
platforms that need it (see [this
comment](https://github.com/tailwindlabs/tailwindcss/pull/20276#issuecomment-4950167198)).
We patch `@napi-rs/cli`'s codegen templates via `pnpm patch` to retry
with narrower preopens (`/` → cwd → none). On such platforms, scanning
is limited to files under the current working directory.
## Test plan
Added two integration tests:
1. Trick pnpm (via `supportedArchitectures`) into installing for a
platform we explicitly don't support, and assert `@tailwindcss/oxide`
loads the wasm binding and scans files from disk.
2. Simulate a sandbox that denies preopening `/`, and assert the wasm
binding still loads and scans.
[ci-all]
This PR bumps dependencies and dev dependencies and applies required
changes due to version bumps.
- Moved `@parcel/watcher` related dependencies to the
`pnpm-workflow.yaml` catalog
- Bumped Lightning CSS + updated tests with improvements
- Bumped napi related dependencies
- Tackled a Vitest warning
## Test plan
All tests should still pass on all platforms [ci-all]
## Summary
Under Vite's experimental `bundledDev` mode, the `hotUpdate` hook in
`@tailwindcss/vite` gets called without a `server`. Vite only passes `{
type, file, modules }` here, but the hook loops over
`Object.values(server.environments)`, so editing any file (JS, CSS, or
HTML) throws `TypeError: Cannot read properties of undefined (reading
'environments')` and the dev server build fails.
The fix returns early when `server` is missing. Those environment loops
only look at environments other than the current one, and the
server-level `hot`/`ws` reload channels don't exist in this mode, so
bailing out leaves the classic (non-`bundledDev`) dev path untouched.
Fixes#20378
## Test plan
- Added a unit test that calls `hotUpdate` without a `server` and checks
it doesn't throw. It fails on the current code and passes with the
guard.
- Reproduced with a Vite 8 project using `experimental.bundledDev:
true`: before the change, editing any JS/CSS/HTML file crashed the dev
server; after it, edits work.
- `pnpm run test` and the `@tailwindcss/vite` integration suite both
pass.
[ci-all]
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
This will bring the development version and production version closer
together. It also means that the development version works in older
supported browsers like Chrome v112 where the space is required (even
though the spec allows both)
There are no changes in tests just becaues we already run each test
through Lightning CSS which normalizes these values:
Input:
```css
var(--tw-blur,)
var(--tw-blur, )
```
Lightning CSS output:
```css
var(--tw-blur, )
var(--tw-blur, )
```
Continuation of #20344, original commits of that PR are present in this
PR as well.
Before we talk about the issues, there is some jargon I'll be using that
might be unfamiliar:
```css
@scope (.from) to (.to) {
/* ^^^^^^^^^^^^^^^^ This is the prelude */
/* ^^^^^^^ This is the `scope-start` */
/* ^^^^^ This is the `scope-end` */
}
/* The `scope-start` is optional, if you only want `scope-end`: */
@scope to (.to) {
}
/* The `scope-end` is optional, if you only want `scope-start`: */
@scope (.from) {
}
```
This PR contains multiple fixes, but they are all related to the
`@scope` at-rule. The `@scope` at-rule is a beast, it's an at-rule where
we do have multiple selectors in the prelude, which in turn can contain
`&` rules. If you use `&` inside of an `@scope` rule, its meaning
changes compared to what `&` typically means and it is even different
whether it exists in `scope-start` or `scope-end`.
Let's start with the original issue, if you define a custom variant
like:
```css
@custom-variant blue {
@scope ([data-theme='blue']) to ([data-theme]) {
@slot;
}
}
```
Then using `blue:bg-blue-500` used to generate:
```css
.blue\:bg-blue-500 {
@scope ([data-theme='blue']) to ([data-theme]) {
background-color: var(--color-blue-500);
}
}
```
This is because internally we start with the AST node representing
`bg-blue-500`, then we wrap all the `variant` related nodes around it
(`blue`), and then wrap everything in the final rule with a selector
representing the class (`.blue\:bg-blue-500`).
This is incorrect because you want that sandwich effect where any
`.blue\:bg-blue-500` class between an element with the
`[data-theme="blue"]` attribute and another nested `[data-theme]`
attribute.
The other [PR](#20344) solved this by simply making sure that the
`@scope` rule gets hoisted to the top. For this particular example that
was enough.
However, that would result in a ton more issues. This hoisting or
swapping with the rule is only "safe" in a `custom-variant`.
So similar to the other PR, this PR wraps this properly:
```css
@scope ([data-theme='blue']) to ([data-theme]) {
.blue\:bg-blue-500 {
background-color: var(--color-blue-500);
}
}
```
The tricky part is that the nesting pass runs on _all_ CSS, custom
variants _and_ your own CSS. Hoisting an `@scope` rule out of the rule
it is nested in changes its meaning.
Take a look at this example:
```css
.parent {
@scope (.from) to (.to) {
* {
border: 1px solid black;
}
}
}
```
This says that you need a structure roughly like this:
```html
<div class="parent">
<div class="from">
<div>This element will get a border</div>
<div class="to">
<div>This element won't get a border, it's beyond the scope</div>
</div>
</div>
</div>
```
If we had switched it:
```css
@scope (.from) to (.to) {
.parent {
* {
border: 1px solid black;
}
}
}
```
Then this requires that an element with a class of `.parent` lives
between the
`.from` scope-start and `.to` scope-end:
```html
<div class="from">
<div class="parent">
<div>This element will get a border</div>
<div class="to">
<div>This element won't get a border, it's beyond the scope</div>
</div>
</div>
</div>
```
Subtle, but it's definitely wrong.
Instead, we will apply our flattening rules, such that the `@scope` gets
hoisted, but we have to bring that `.parent` selector requirement inside
of the `@scope` prelude, more specifically inside the `scope-start`:
```css
@scope (.parent .from) to (.to) {
* {
border: 1px solid black;
}
}
```
We _could_ have left this as-is, but there is a Lightning CSS bug where
the original CSS:
```css
.parent {
@scope (.from) to (.to) {
* {
border: 1px solid black;
}
}
}
```
gets turned into:
```css
@scope (.from) to (.to) {
:scope * {
border: 1px solid #000;
}
}
```
Notice how the `.parent` class is not found at all? (I will open some
issues on the Lightning CSS repo (and PRs to fix this). But it's a good
fix to have in Tailwind CSS as well, just because a lot of tooling is
already using Lightning CSS on top of Tailwind CSS, so we need an entire
chain to be updated for this to work.)
Side note: the version we generate is untouched by Lightning CSS.
## Resolving `&` in the prelude
`&` resolves differently depending on which scope selector you're
looking at
([spec](https://drafts.csswg.org/css-nesting-1/#nesting-at-scope)):
- In the `<scope-start>` selector, `&` refers to the elements matched by
the nearest ancestor style rule (the utility, for variants).
- In the `<scope-end>` selector, `&` refers to the scoping root and
behaves like `:where(:scope)`. `:scope` might work, but that has a
specificity of `0,1,0` instead of `0,0,0`.
So this input:
```css
.parent {
@scope (& > .scope) to (& .limit) {
.content {
color: red;
}
}
}
```
compiles to:
```css
@scope (.parent > .scope) to (:where(:scope) .limit) {
.content {
color: red;
}
}
```
The substitution uses the exact same logic as `&` in nested style rule
selectors: `:is(…)` semantics by default, dropping the `:is(…)` whenever
the substitution is provably equivalent.
So a complex parent compiles to `@scope (.a .b > .from)` rather than
`@scope (:is(.a .b) > .from)`, while `.card&` inside a `main` rule keeps
it (`@scope (.card:is(main))`) because substituting the type selector
as-is would produce invalid CSS.
For user CSS, every selector in a `<scope-start>` selector list is
relative to the parent rule, whether it uses `&` or not, just like
nested style rule selectors:
```css
.parent {
@scope (.a, & > .b) {
.inside {
color: red;
}
}
}
```
compiles to:
```css
@scope (.parent .a, .parent > .b) {
.inside {
color: red;
}
}
```
## Controlling the composition with `&`
Because `&` in the `<scope-start>` selector refers to the utility,
variant authors can control where the utility ends up:
```css
/* Default: the utility applies to elements inside the scope */
@custom-variant in-blue {
@scope ([data-theme='blue']) to ([data-theme]) {
@slot;
}
}
/* Trailing `&`: the utility itself becomes the scoping root */
@custom-variant blue-self {
@scope ([data-theme='blue'] &) to ([data-theme]) {
@slot;
}
}
/* Leading `&`: the scoping roots are found inside the utility */
@custom-variant scoped-panel {
@scope (& .panel) {
@slot;
}
}
```
generates:
```css
@scope ([data-theme='blue']) to ([data-theme]) {
.in-blue\:flex {
display: flex;
}
}
@scope ([data-theme='blue'] .blue-self\:flex) to ([data-theme]) {
:where(:scope) {
display: flex;
}
}
@scope (.scoped-panel\:flex .panel) {
:where(:scope) {
display: flex;
}
}
```
Note that when the utility becomes the scoping root, the `<scope-end>`
limit no longer affects the utility itself (a scoping root is never
beyond its own limits), and the declarations apply to the root with zero
specificity. The default composition is usually what you want to get the
sandwich effect, but now you _can_ get the other behavior if you want.
## Bare declarations
There is another small Lightning CSS bug that we want to fix. If you
have the following CSS:
```css
@scope (.from) to (.to) {
color: red;
}
```
Then Lightning CSS crashes with an unexpected input. The [spec
says](https://drafts.csswg.org/css-cascade-6/#scoped-declarations) that:
> Declarations may be used directly with the body of a `@scope` rule.
Contiguous runs of declarations are wrapped in nested declarations
rules, which match the scoping root with zero specificity.
>
> ```css
> @scope (.foo) {
> border: 1px solid black;
> }
> ```
> is equivalent to:
> ```css
> scope (.foo) {
> :where(:scope) {
> border: 1px solid black;
> }
> }
> ```
So this is what we will do as well:
```css
@scope (.from) to (.to) {
:where(:scope) {
color: red;
}
}
```
---
One more small detail about the implementation: we do have to track
which CSS is coming from the custom variant, and what is user defined
CSS. To do this, we insert some internal `context` nodes with a `{
source: 'user' }` or `{ source: 'variant' }` so we know when we can just
swap this `@scope` around, or if we just have to handle the nesting and
`&` substitutions.
Fixes: #18961Closes: #20344
## Test plan
1. Added loads of new tests related to `@scope` in user-land
1. Added loads of new tests related to `@scope` in custom variants
- When using the `@custom-variant` shorthand syntax
- When using the `@custom-variant` syntax with `@slot`
- When using arbitrary variants like `[@scope_(.from)_to_(.to)]:flex`
- When using `addVariant()` and `matchVariant()` APIs
1. Added tests for the hoisting logic, prelude resolution for `&`
selectors
1. Added browser based UI tests to make sure that the non-flattened
version and flattened version behave the same.
---
Sorry about all the sandwiches, I'm hungry myself.
---------
Co-authored-by: uditDewan <udit.dewan21@gmail.com>
This PR updates the integration tests that started failing because of a
recent PostCSS update.
PostCSS v8.5.24 started re-emitting the BOM character in the output,
see: https://github.com/postcss/postcss/releases/tag/8.5.24 therefore
the tests started failing.
This PR just re-adds that back.
It might not be clear from the diff on GitHub, but this is the change:
<img width="878" height="84" alt="image"
src="https://github.com/user-attachments/assets/5e2fbb6e-2ee4-46c5-9a2c-9c3a1a806bb0"
/>
## Test plan
1. All tests pass again [ci-all]
This PR fixes an issue where changes to a symlinked file wouldn't result
in hot-reload when using `@tailwincdss/vite`. This issue also exists in
the other packages such as `@tailwincdss/postcss`,
`@tailwincdss/webpack` and `@tailwincdss/cli`.
The issue is that we watch the symlinked file, but not the "real" file
for changes. If the source of the symlinked file lives in another folder
that is not covered by auto-source detection or by any of the `@source`
directives, then changes to that file won't trigger a change.
To solve this, if a file is symlinked or lives in a symlinked folder,
then we will make sure that the `scanner.files` contains the real path /
canonicalized path to the real file as well just so we can detect
changes in that file.
Fixes: #20346Closes: #20347
## Test plan
1. Added a regression test for `@tailwindcss/vite`
2. Added tests in the scanner code itself
3. Manually tested on the reproduction:
| | Initial state | After change |
| ---: | --- | --- |
| **Before** | <img width="3200" height="1800"
alt="file-f8616573eec3150ae484fd279204c6d7"
src="https://github.com/user-attachments/assets/2734ecc3-b5b6-420e-820d-8a4a8fcdd7f5"
/> | <img width="3200" height="1800"
alt="file-0e93fd3c2c9694c844b098616a3208d2"
src="https://github.com/user-attachments/assets/fd86859b-420b-476b-80f6-e94d02e8b07b"
/> |
| **After** | <img width="3200" height="1800"
alt="file-f8616573eec3150ae484fd279204c6d7"
src="https://github.com/user-attachments/assets/2734ecc3-b5b6-420e-820d-8a4a8fcdd7f5"
/> | <img width="3200" height="1800"
alt="file-eb7b37430ea1363dddeac7226007afe4"
src="https://github.com/user-attachments/assets/0a95b1a4-a357-491d-b57f-78460c0fc9db"
/> |
[ci-all]
---------
Co-authored-by: Nic <162764842+Nic-Polumeyv@users.noreply.github.com>
The last CI run on `main` was on July 16, and the last `globby` release
(16.2.2) was released on July 15 (~21 hours earlier). Due to the default
`minimumReleaseAge` in pnpm of 24 hours, it meant that we were receiving
the previous globby version.
In the new version, they slightly changed some of the `.gitignore`
parsing, but in one of our upgrade tests we wrote an invalid
`.gitignore` file (which had indented lines).
This PR fixes that by using the `txt` tagged template literal, which
behind the scenes uses `dedent` which in turn makes sure that we ship a
proper `.gitignore` file.
## Test plan
All tests should pass [ci-all]
This PR fixes an issue where editing a scanned file that Vite (or one of
its plugins) can process as a module, but that isn't currently loaded,
caused `@tailwindcss/vite` to force a full page reload, throwing away
all client state.
The `hotUpdate` hook has a fallback that sends a `full-reload` for files
that Tailwind scans but that Vite knows nothing about (e.g. `.php` or
`.blade.php` templates rendered by a backend). Without it, edits to
those files wouldn't refresh the page at all. To detect those files we
check whether every module for the changed file is an `asset` and/or has
no id, because the scanner's `addWatchFile` calls create exactly such
placeholder nodes for every scanned file.
The problem is that a source file that Vite _can_ process, but that
isn't loaded yet, looks exactly the same. The realistic way to get into
that state is code splitting: with route-level splitting (e.g.
`React.lazy`, TanStack Router's `autoCodeSplitting`, lazy routes in
`vue-router`), every component behind an un-visited split boundary only
exists as a scan placeholder in the module graph. Editing any of them
reloaded the whole app. The same happens for component stylesheets that
a framework plugin compiles into the component (e.g. Angular via
Analog), which never show up as their own module.
A full reload is never useful for these files: if the file is loaded,
Vite's own HMR handles it, and if it isn't loaded, reloading the page
won't load it either. Any new candidates still apply through the regular
`css-update` flow because the file is registered via `addWatchFile`.
So instead, we now skip the fallback when the changed file is handled by
Vite's module pipeline:
- The file exists as a real module in another environment (e.g. an
SSR-only module). This check already existed and is folded into the same
code path.
- The file is part of the JS/TS or CSS families, which Vite transforms
natively.
- For any other file type (e.g. `.vue`, `.svelte`, or `.md` with an SSG
plugin), a file with the same extension exists as a real module in some
environment's module graph, then a plugin does handle this file type and
the changed file just isn't loaded (yet).
External templates like `.php` files still trigger a full reload exactly
like before.
Fixes: #20320Fixes: #19903Closes: #20323
## Test plan
1. Added integration tests to ensure extensions handled by default rely
on HMR
2. Added integration tests to make sure that unknown extensions that
have been handled already will also use HMR
3. Manually tested that changing a `.php` file still triggers a
`full-reload`
4. Manually tested the reproduction where local client state isn't
thrown away
<img width="594" height="100"
alt="file-14a86a90a1e4b810c2b80338ea688572"
src="https://github.com/user-attachments/assets/a4507502-4a5d-43ee-93b9-14c793a25891"
/>
<img width="1122" height="1376"
alt="file-a5121da2ad77b95fdd1703560ef1ff41"
src="https://github.com/user-attachments/assets/cc5c67b0-b5ad-481f-8823-a3266d75357d"
/>
This PR fixes an issue where an `@source` pointing to a file in a nested
folder was not scanned when a later `@source` pointed to a file in a
parent folder.
E.g.:
```css
@source "./nested/index.html";
@source "./index.html";
```
When using `@source` pointing to a specific file, then we want to make
sure that we ignore _other_ files since they are not listed explicitly.
To ensure that these patterns don't read other files, we inject a `*`
ignore pattern before it. You can think of the above being expanded to:
```rs
Ignored { base: "/project/src/nested", pattern: "*" }
Pattern { base: "/project/src/nested", pattern: "/index.html" }
Ignored { base: "/project/src", pattern: "*" }
Pattern { base: "/project/src", pattern: "/index.html" }
```
The problem with this is that the `Ignored { base: "/project/src",
pattern: "*" }` pattern results in ignoring the `nested` folder as well.
This means that we never even walk into the `nested` folder, so the
earlier `@source "./nested/index.html"` never matches anything.
We could switch the order in user land, but that's going to be hard to
maintain (and order matters for undoing/redoing earlier rules, so we
can't re-order internally either). Instead, we can scope the ignore
pattern to the _current_ path only, and not deeply nested. In other
words, the pattern should become:
```diff
- *
+ /*
```
It's a very subtle difference, but the pattern from above will now
become:
```diff
Ignored { base: "/project/src/nested", pattern: "*" }
Pattern { base: "/project/src/nested", pattern: "/index.html" }
- Ignored { base: "/project/src", pattern: "*" }
+ Ignored { base: "/project/src", pattern: "/*" }
Pattern { base: "/project/src", pattern: "/index.html" }
```
We already do this when an unrestricted root (e.g. `@source "./nested"`)
lives inside the base of a restricted pattern. This works because every
source base is also its own walk root, and a `/*` pattern only matches
direct children so it can't ignore anything when walking from the nested
root itself.
This PR extends that same check to restricted pattern bases: if another
`@source` pattern has its base nested inside the current base, we emit
`/*` instead of `*`.
Note that we only relax the pattern to `/*` when such a nested root
actually exists. Sibling folders that no `@source` points into (e.g. an
`ignore-me` folder next to `nested`) are still direct children, so they
still match `/*` and are never walked.
Fixes: #20333
## Test plan
1. Added a regression test with the reproduction setup
2. Added a similar test with another sibling folder that should still be
ignored
3. Tested it against the actual reproduction:
Before:
<img width="797" height="463" alt="image"
src="https://github.com/user-attachments/assets/893bb872-f5cf-4c5a-bfb5-2dc1043b5a39"
/>
After:
<img width="794" height="460" alt="image"
src="https://github.com/user-attachments/assets/a59aae45-68ad-4fe3-b21f-b568f535d24f"
/>
Notice that the `text-green-500` now appears as expected.
Fixes#20328.
## What changed
When `@tailwindcss/upgrade` is invoked from a subpackage of a workspace
(e.g. `pnpm --filter …` or `cd packages/foo && pnpm exec upgrade`), it
traverses `../../node_modules/…` and applies its v3 → v4 migration
transform (`@tailwind utilities;` → `@import 'tailwindcss/utilities'
layer(utilities);`) to files inside the installed `tailwindcss` package
itself — a self-referential import that later detonates as an infinite
CSS-resolution loop and reads like a "cache corruption" bug (matches the
report in #19726 / #20328).
Root cause: `globby`'s `isGitIgnored` only walks `.gitignore` files at
or below its `cwd`. When invoked from a subpackage, the workspace-root
`.gitignore` (which almost always lists `node_modules`) is never
consulted, and `../../node_modules/…` paths come back as **not**
ignored.
The fix anchors `isGitIgnored` at the git repository root instead of the
subpackage:
- New helper: `gitRoot(cwd)` in `src/utils/git.ts` — thin wrapper over
`git rev-parse --show-toplevel`.
- `analyze(stylesheets, { base })` in `src/codemods/css/analyze.ts` now
calls `isGitIgnored({ cwd: gitRoot(base) ?? base })`. Falls back to the
previous behavior when not inside a git repository or when `git` is
unavailable.
## Test
Added an integration test that reproduces the exact scenario: a pnpm
workspace with a subpackage that imports `tailwindcss/utilities.css`,
upgrade run from the subpackage, then asserts
`packages/css/node_modules/tailwindcss/utilities.css` still holds the
pristine `@tailwind utilities;` directive.
Verified the test fails on `main` and passes with this change.
The 415 existing upgrade unit tests still pass. Two npm-related snapshot
failures in `upgrade-errors.test.ts` (`half-upgraded v3 project to v4
(bun|npm)`) pre-exist this change — they're about newer npm's `npm
notice run` output that isn't in the snapshots, unrelated to what this
PR touches.
---
Edit by @RobinMalfait: going to run on all [ci-all] so we can make sure
it works on Windows as well.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
This PR fixes an issue where some characters are incorrectly rendered on
Windows with the Japanese locale.
This is arguably a bug in the font that's loaded by Windows when it
encounters `system-ui`. But waiting for fixes there might ... take a
while.
Another option is to not change the defaults in Tailwind CSS and instead
let the users that support different locales implement a fallback by
overriding the `--font-sans` variable.
The biggest reason for me to _not_ change it in Tailwind CSS is that it
requires us to know what the (proper) fallback fonts need to be on a per
OS basis.
But the main reason why I did want to make the change is that MDN says
this about the `system-ui` font:
> Glyphs are taken from the default user interface font on a given
platform. Because typographic traditions vary widely across the world,
this generic is provided for typefaces that don't map cleanly into the
other generics.
>
> **Note:** As the name implies, `system-ui` is intended to make UI
elements look like native apps, and not for typesetting large paragraphs
of text. It may cause the displayed typeface to be undesirable for some
users—for example, the default Windows CJK font may render Latin scripts
poorly, and the `lang` attribute may not affect the displayed font. Some
operating systems do not allow customizing `system-ui`, while browsers
generally allow customizing the `sans-serif` font family. For large
paragraphs, use `sans-serif` or some other non-UI font family instead.
>
> —
https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/font-family#system-ui
There are PRs in other big projects that made this kind of change as
well. E.g.:
- https://github.com/withastro/starlight/pull/3729
- https://github.com/vuejs/vitepress/pull/4988
The reasoning for getting rid of `ui-sans-serif` is twofold:
1. Because the starlight PR seems very well tested, and they got rid of
it
2. In the event that the browser decided to load the broken font when it
encounters `ui-sans-serif`, then we will run into the same issue again.
Fixes: #19767Fixes: #19768
## Test plan
1. `system-ui` is not used anymore, so the bug doesn't happen
3. Everything still looks the same for the places I checked, but it's
hard to know if this created _other_ issues on other OS + Locale
combinations...
This PR ensure that we lazy load the `@parcel/watcher` in the
`@tailwindcss/cli`. This means that we don't have to load it at all when
using a normal build or when using `--watch --poll` combination.
The bigger reason is that on some platforms `@parcel/watcher` might not
work, and therefore the build will fail even if you don't use `--watch`
at all.
This PR fixes that by lazy loading it. Then, if we can't load it when
using `--watch`, a useful workaround is shown by using `--watch --poll`
instead.
This PR also improves showing errors such that the `error.cause`
property can be rendered as well.
Maybe in the future we can make use of deferred imports
(https://github.com/tc39/proposal-defer-import-eval)
Fixes: #20322
## Test plan
1. All tests still pass [ci-all]
2. Fabricated a fake error locally to prove that we can still use a
normal build and `--watch --poll` as a workaround
<img width="1122" height="1376"
alt="file-2f91d99cfb9eb0e24a196c2dd358c1f3"
src="https://github.com/user-attachments/assets/e37658ee-0827-422e-bd50-8ea5a85e1b7c"
/>
This PR fixes a type issue when using `--spacing(0)`. This construction
doesn't really make sense, but if you use it, it produces the value `0`
instead of `calc(var(--spacing) * 0)` which is fine if you use it in a
spot where a `<length>` data type can be used, then the `0` is
interpreted as a `<length>`.
E.g.: `padding: 0` and `padding: 0px` are equivalent.
However, if you use it in a CSS variable, then the `0` will turn in a
`<number>` if you don't have an `@property` definition for that CSS
variable.
This on its own isn't the issue, but if you later use it as part of a
`calc(…)` then the `<number>` instead of `<length>` type is being used.
As seen in #20315.
We could remove the optimization, and use `calc(var(--spacing) * 0)`
again, but this is a bit silly since it only makes your CSS file larger.
We could try to be smart, and only do it _if_ we're assigning to a CSS
variable (which #20317 is doing). But if your CSS variable _does_ use a
`<length>` then it's a non-issue. We would run into the same issue if
you use `width: calc(100% --spacing(0))`. This value is a bit silly
anyway, but it would originally resolve to `calc(100% +
calc(var(--spacing) * 0))`, the optimization of `calc(100% - 0)` would
make it invalid, so the fix in #20317 would not be enough.
Instead I opted for an inbetween solution, by always using `0px`. In
most cases we can use `0`, but in the places we can't the `0px` would at
least ensure that we are dealing with `<length>` data types.
This way we don't have to try to be smart to analyze where we use the
value, and `0px` is still better than the long `calc(var(--spacing) *
0)` value.
Fixes: #20315Closes: #20317
## Test plan
1. Manually tested that now `--spacing(0)` does produce `0px` which has
a length type
This PR introduces a new feature where we will be handling the CSS
nesting ourselves.
We currently still rely on Lightning CSS in most places. But there are
situations where we don't use Lightning CSS out of the box:
1. During development, typically optimization/minification isn't setup
2. In places where it isn't as easy to run Lightning CSS such as in
`@tailwindcss/browser` or in Tailwind Play.
We handle CSS nesting in a single pass over the AST by tracking some
information as we go. It's not the most complex code, but there are some
tricky parts to make this happen in an efficient way, especially for the
few additional optimizations we handle.
While going over the AST, we will only emit CSS the moment we see
declarations or comments. This also means that this has a fun side
effect of removing CSS that ends up with empty nodes automatically.
(Caveat: there are exceptions for body-less rules such as `@layer foo;`
or `@charset "UTF-8";)
This also allowed us to do some cleanup in `optimizeAst` that tried to
do this as well, but now this will be handled by the code that handles
nesting automatically. Which is preferred because the version in
`optimizeAst` mutated the AST.
This also contains some optimizations where we merge adjacent at-rules
(with the same name / params), and adjacent rules with the same
selector, and get rid of declarations that are duplicated in a node.
(Caveat: there are exceptions, in case of `@font-family { … }` where we
don't want to merge them)
~~To ensure that this implementation is correct, I also added an oracle
implementation in the tests. This implementation does multiple passes
over the AST, because it does each step one by one, with minimal code.
Each step contains comments with examples to see what's happening in
that step. We then test the optimized version against this.~~ Once the
implementation was in place, and all the tests were passing, then I
deleted the oracle implementation. That way we don't have to keep it in
sync all the time.
While handling the nesting, we have to make sure that `&` exists and if
we replace it with a parent selector that we do use `:is(…)` semantics.
This means that:
```css
.foo {
&:hover {
color: red;
}
}
```
Becomes:
```css
:is(.foo):hover {
color: red;
}
```
We then also make sure that we optimize the selector by removing the
unnecessary `:is(…)` wrappers, but only if they were introduced by the
nesting logic. If _you_ wrote `:is(…)` in your CSS, we won't touch it.
If you look at the commits, the first thing we did is remove the
optimization step from Lightning CSS in the tests. Then we enabled our
CSS nesting handling code. This allows us to see the effect of the
changes we are making. At the end, we re-enabled Lightning CSS.
For now, this PR will be a step that happens before Lightning CSS is
executed, while still using Lightning CSS. But now this step will also
always happen in places where we don't use Lightning CSS at all.
This should not result in any breaking changes. It could result in
changed CSS output in environments where Lightning CSS isn't used. In
environments where it is being used, then there could be some
differences related to some selectors but they should result in the same
behavior with the same specificity.
While testing things, I noticed that there are some missed opportunities
for performance related to how we extract variables from declaration
values. I want to tackle `optimizeAst` in future PRs to make it simpler,
more performant, and maybe even merge it with the CSS nesting handling.
As part of testing this, I tested it against the tailwindcss.com
codebase which contains a lot of CSS (807.67 KB, 18 174 AST nodes)
because almost every utility is being used in examples.
The oracle implementation is rather slow:
```
[131.59ms] ↳ oracle (step by step)
[129.23ms] ↳ handleNesting(…)
[ 2.32ms] ↳ toCss(…)
```
But the final code is much faster (`<15ms`):
```
[ 10.11ms] ↳ hand written (single pass)
[ 8.40ms] ↳ handleNesting(…)
[ 1.67ms] ↳ toCss(…)
```
In contrast, Lightning CSS takes: `[ 37.48ms] Optimized by Lightning
CSS`
One interesting thing to notice is that in big projects, this could add
`10ms` to the build, but Lightning CSS would then take less time to
process, which results in a no-op with better output.
One thing to keep in mind here is that Lightning CSS does more things,
such as normalizing values, handling vendor prefixes, CSS nesting, etc.
<details>
<summary>Some notes on how the algorithm works:</summary>
### The basic idea
When you have CSS that looks this:
```css
.foo {
.bar {
color: red;
}
}
```
Then the AST looks like this:
```
[
{
kind: 'rule',
selector: '.foo',
nodes: [
{
kind: 'rule',
selector: '.bar',
nodes: [
{
kind: 'declaration',
property: 'color',
value: 'red',
important: false
}
]
}
]
}
]
```
When we walk this tree, and we encounter a `rule`, then we will track
the selector on a stack. When we are done walking over the rule, then we
will pop the selector from the stack. This means that the top-most
selector on the stack will always be the parent selector.
```ts
let selectorStack = []
walk(ast, {
enter(node) {
selectorStack.push(node.selector)
},
exit(node) {
selectorStack.pop()
},
})
```
The moment we encounter a `rule`, and if a previous rule was seen, then
we push the `selector` of the rule onto the stack, but in a way that the
`&` is already replaced by the selector. This way, a sibling rule will
also get the already-prepared parent selector.
The simple version looks like this:
```ts
walk(ast, {
enter(node) {
// In the real code we properly handle `&` replacement, and make sure that
// parent selector is prepended if there is no `&` used in the selector of the
// node.
let selector =
selectorStack.length > 0
// At this point, we don't optimize anything related to the selector yet
? node.selector.replaceAll('&', `:is(${selectorStack.at(-1)})`)
: node.selector
selectorStack.push(selector)
},
exit(node) {
selectorStack.pop()
},
})
```
So far we aren't doing much yet, but the interesting part is when we
encounter a `declaration` (or a `comment`). The moment we see any of
those, then will we emit a node with the information from the
`selectorStack`.
We then also track the last node's `nodes` we created such that we can
push more declarations into it as a shortcut.
```ts
let result: AstNode[] = []
let nodes: AstNode[] | null = null
walk(ast, {
enter(node) {
if (node.kind === 'declaration') {
// `nodes` is available, nothing special to do
if (nodes) {
nodes.push(node)
return
}
// Track new nodes
let nodes = [node]
// Create a new node with a reference to `nodes` for future declarations
let newNode = rule(selectorStack.at(-1), nodes)
result.push(newNode)
}
},
})
```
The last important part is that whenever we see a new `rule`, then we
have to reset that `nodes` tracking variable such that we can create a
fresh node the next time we see a declaration.
For the `at-rules`, something similar happens but they are tracked in a
similar but separate stack. The idea there is that we can then wrap
those `at-rules` around the `newNode` we create. That way the at-rules
naturally float to the top.
I can keep going here, but I think if you're interested in this, then
you could go over the commits in this PR, or you can look at the
`ast.ts` implementation directly to see what's going on.
</details>
## Test plan
1. Existing tests should pass
2. New tests have been added to test the flattening of nested CSS
## Summary
`@tailwindcss/postcss` chooses between an incremental and a full rebuild
by comparing the mtimes of the entry file and its resolved
`@import`/`@config`/`@plugin` graph. It never looks at the input CSS
itself, so when that CSS is produced by an upstream tool (e.g. Sass) and
passed to the plugin via `process()`, it can change while the `from`
file's mtime stays the same. The plugin then re-emits its previously
cached output and silently drops the change.
This stores the input CSS per cache entry and takes the existing full
rebuild path when it differs from the previous compile, mirroring the
fix the CLI watcher already has for changed input files.
Fixes#20307
## Test plan
- Added a regression test in
`packages/@tailwindcss-postcss/src/index.test.ts` that compiles two
different inputs for the same on-disk `from` file (unchanged mtime) and
asserts the second compile reflects the new CSS.
- Confirmed it fails on `main` (the second compile returns the stale
first output) and passes with the fix.
- Ran the `@tailwindcss/postcss` package tests (all green) and checked
formatting with Prettier.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
This PR fixes a bug in the selector parser where an attribute selector
followed by a type selector inside a compound selector resulted in the
wrong result.
Given you have this CSS:
```css
[data-foo]div {}
```
Then parsing it before this PR, would result in:
```ts
{
kind: 'compound',
nodes: [
{ kind: 'selector', value: '[data-foo]div' },
],
},
```
But with this PR, it's properly split:
```ts
{
kind: 'compound',
nodes: [
{ kind: 'selector', value: '[data-foo]' },
{ kind: 'selector', value: 'div' },
],
},
```
I also tweaked some of the comments in the parser that are unrelated,
but I was there already.
## Test plan
1. Added a regression test
2. All other tests should pass
## Summary
`shadow-*`, `text-shadow-*`, `drop-shadow-*`, and `inset-shadow-*`
accept a bare (non-arbitrary) opacity modifier like `/50`, but the
named-size branch of all four utilities validates it with
`isPositiveInteger(candidate.modifier.value)` instead of
`isValidOpacityValue(candidate.modifier.value)` — the helper every other
opacity/alpha modifier in the codebase uses (`asColor`, used by `bg-*`,
`text-*`, `border-*`, `ring-*`, `fill-*`, `stroke-*`, `decoration-*`,
`accent-*`, `caret-*`, `outline-*`, `placeholder-*`, `divide-*`).
This means a fractional modifier like `/12.5` is silently ignored for a
*named size* (`shadow-sm/12.5` behaves exactly like `shadow-sm`,
dropping the modifier), while the exact same `/12.5` modifier works
correctly on the *color* variant of the same utility
(`shadow-red-500/12.5` → `color-mix(in oklab, var(--color-red-500)
12.5%, transparent)`), since that path already goes through `asColor`.
`drop-shadow-*` is worse: its named-size branch has an extra guard (`if
(candidate.modifier && !alpha) return`) that bails out of the *entire*
utility when a modifier is present but couldn't be resolved to an alpha
— so `drop-shadow-sm/12.5` produces no CSS at all.
This isn't a case of fractional percentages being unsupported by design
— the CHANGELOG entry that introduced `shadow-*/<alpha>` explicitly
describes it as controlling shadow **opacity**, and the color branch of
these same utilities already supports fractional values
(`shadow-red-500/2.25`, `/2.5`, `/2.75` are covered by existing tests).
The named-size branch just never got the same treatment.
**Repro** (verified with `pnpm --filter tailwindcss exec vitest run`):
- `shadow-red-500/12.5` → `color-mix(in oklab, var(--color-red-500)
12.5%, transparent)` (correct)
- `shadow-sm/12.5` → identical output to plain `shadow-sm` (modifier
silently dropped)
- `drop-shadow-sm/12.5` → **no CSS generated at all**
- `shadow-sm/50` (integer, control) → works correctly
## Fix
Replaced `isPositiveInteger(candidate.modifier.value)` with
`isValidOpacityValue(candidate.modifier.value)` in the four affected
utility definitions in `packages/tailwindcss/src/utilities.ts`
(`shadow`, `text-shadow`, `drop-shadow`, `inset-shadow`). No other
changes were needed — once `alpha` resolves correctly, `drop-shadow`'s
existing `if (candidate.modifier && !alpha) return` guard naturally
stops bailing out, since `alpha` is no longer `undefined` for valid
fractional modifiers.
## Test plan
- Added a regression test in
`packages/tailwindcss/src/utilities.test.ts` covering `shadow-sm/12.5`,
`text-shadow-sm/12.5`, `drop-shadow-sm/12.5`, and
`inset-shadow-sm/12.5`.
- Verified via `pnpm --filter tailwindcss exec vitest run` that this
test fails (modifier dropped / empty output) with the fix reverted, and
passes with it applied.
- Ran the full `tailwindcss` package test suite (`pnpm --filter
tailwindcss exec vitest run`) — 4685 tests passing, no regressions.
- Verified formatting on the changed files with `npx prettier --check`.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
## Summary
When a CSS theme key defined via `@theme` (or a JS config's `theme`
object) shares a dash-separated prefix with a sibling key — e.g.
`--color-foo` and `--color-foo-bar` — calling `theme('colors.foo')` from
inside a JS plugin (`addUtilities`, `addComponents`, etc.) does not
resolve to the `foo` value. Instead it returns an internal
disambiguation object shaped like `{ DEFAULT: 'red', bar: 'blue',
__CSS_VALUES__: {...} }`, because there's no way to tell from CSS custom
property names alone whether `foo-bar` is a sibling key or a nested
sub-key of `foo`.
This same ambiguity was already fixed for the CSS-embedded `theme()`
function in #19097 (which unwraps to the `DEFAULT` key when present),
and the changelog entry for that PR states it fixes this "in JS configs
**and plugins**" — but the fix only touched `apply-compat-hooks.ts`'s
`resolveThemeValue`, not `createThemeFn`'s `theme` function that's
exposed directly to plugins in `plugin-functions.ts`. This PR closes
that gap by applying the same DEFAULT-unwrapping there.
Without this fix, passing the raw object into `addUtilities` (a very
natural thing to do, since a plugin author expects a string) produces
broken CSS — the reserved `DEFAULT` key gets mangled into a garbage
property name (`-d-e-f-a-u-l-t`) by the kebab-case conversion, and the
internal `__CSS_VALUES__` bookkeeping leaks into the generated
stylesheet.
### Minimal reproduction
```js
// tailwind.config.js (registered via @config, or any @plugin-registered plugin)
const plugin = require('tailwindcss/plugin')
module.exports = {
plugins: [
plugin(function ({ addUtilities, theme }) {
addUtilities({
'.example-foo': { color: theme('colors.foo') },
})
}),
],
}
```
```css
@import "tailwindcss";
@config "./tailwind.config.js";
@theme {
--color-foo: red;
--color-foo-bar: blue;
}
```
**Before:**
```css
.example-foo color {
-d-e-f-a-u-l-t: red;
bar: blue;
}
.example-foo color __CSS_VALUES__ {
-d-e-f-a-u-l-t: 0;
bar: 0;
}
```
**After:**
```css
.example-foo {
color: red;
}
```
## Test plan
- Added a regression test in
`packages/tailwindcss/src/compat/plugin-api.test.ts` ("theme() resolves
the DEFAULT value when a bare CSS theme key shares a prefix with a
sibling key")
- Verified via `pnpm --filter tailwindcss exec vitest run` that this
test fails with the exact broken output shown above when the fix is
reverted, and passes once it's applied
- Ran the full `tailwindcss` package test suite (`pnpm --filter
tailwindcss exec vitest run`) — 4684 tests passing, no regressions
- Verified formatting on the changed files with `npx prettier --check`
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
## Description
Firefox's UA stylesheet already sets `iframe:focus-visible {
outline-style: none; }`, so Preflight's `:-moz-focusring { outline:
auto; }` rule overrides that and applies an unwanted auto outline to
focused iframes.
Adding `:where(:not(iframe))` to the selector preserves the improved
focus ring behavior for all other elements while respecting Firefox's
native iframe focus styling.
Fixes#19795
Edit by @RobinMalfait
## Test plan
Before:
<img width="1054" height="383"
alt="file-f833142116d36e1e620290b97455f001"
src="https://github.com/user-attachments/assets/81aa170b-2cef-4964-934d-61f258335e1a"
/>
After:
<img width="1056" height="310"
alt="file-400d9214fedf5b43693e10580a4869de"
src="https://github.com/user-attachments/assets/8f8bb81d-6070-425d-8820-327bf9e88e79"
/>
---------
Co-authored-by: root <root@localhost.localdomain>
Co-authored-by: Kirk Loretz <kirk-loretz-fsn@users.noreply.github.com>
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
This PR bumps most of the dependencies to the latest version.
This also marked some dependencies using a range such that you get
updates for free during the installation:
```diff
catalog:
- enhanced-resolve: 5.21.6
+ enhanced-resolve: ^5.24.1
- vite: 8.0.14
+ vite: ^8.1.2
- webpack: 5.107.0
+ webpack: ^5.108.3
```
Fixes: #20291
## Test plan
1. All tests on all OSes still pass [ci-all]
This PR fixes an issue where hex-based colors in arbitrary properties
and values were considered case-sensitive even though they are
case-insensitive in CSS.
If you look at the linked issue, there is this input CSS:
```css
@theme {
--color-brand-purple: #3f3cbb;
}
```
We expect that both `bg-[#3f3cbb]` and `bg-[#3F3CBB]` get canonicalized
to `color-brand-purple` but before this pr, only the first one would get
canonicalized that way (since it's a perfect match).
Technically a bunch more values are case-insensitive but a lot of them
_are_ sensitive so to get this 100% correct, a lot more parsing needs to
happen. I think we can start with this and expand the logic when needed.
Fixes: #20295
## Test plan
1. Added a regression test based on the linked issue
2. Added tests for arbitrary properties (`[color:#fff]` vs
`[color:#FFF]`), and tests for arbitrary properties (`bg-[#fff]` vs
`bg-[#FFF]`)
This PR re-adds the `--poll` option to the `@tailwindcss/cli` that we
had in Tailwind CSS v3, but didn't in Tailwind CSS v4.
In Tailwind CSS v4, we started using `@parcel/watcher` instead of
chokidar for our watcher in the CLI. However, this currently doesn't
support a `--poll` option.
This PR implements our own `--poll` option such that you can use it in
environments where fs events don't work properly (e.g. Docker).
Polling can be enabled by using `--watch --poll`, in this case we will
poll every `250ms` (I'm open for a different default value). You can
also pick your own interval by using `--watch --poll 500` which is
defined in milliseconds.
The `--poll` option will be less efficient than a normal `--watch`. But
if you are in a situation where you can't use `--watch` on its own then
this is a good fallback.
One thing you can do today is run the build command manually. If you do
have some tooling that _does_ work on your machine (such as
[`watchexec`](https://github.com/watchexec/watchexec)) then you can
automatically perform a full build. The biggest downside of this
approach is that you are doing a full build every time, instead of an
incremental build.
With this PR, we try to fix that by still allowing incremental builds.
This should result in the same behavior as the normal `--watch`
function:
1. First run, will trigger a full build
1. When any of the source files changes:
- If all classes were already known, then it will be a no-op, but you
will see a log in the terminal about it.
- If a new class is detected, then the CSS will be updated, but it will
be much more efficient than a full rebuild
1. When the input CSS file changes, or any of its dependencies, then a
full rebuild will be triggered (such that your new `@utility` are
available, and `@theme` values are updated).
The implementation is a little bit more complex just because I didn't
want to spam the terminal output even if we are polling every `250ms`.
In the Oxide scanner we do track the modified times of each file. Every
`250ms` we traverse the file system and skip the files that we know
didn't change (since the mtime is the same). If the file was touched,
then we will parse it again to extract possible Tailwind CSS classes. We
will also track which files were scanned such that we can know whether
we have to trigger a full-rebuild or not (in case the input.css file or
any of its dependencies was changed).
Fixes: #18109Fixes: #18540Fixes: #15750
## Test plan
1. Existing tests pass
2. An integration test has been added for the `--poll` option
3. Tested it on the tailwindcss.com codebase:
<img width="679" height="320" alt="image"
src="https://github.com/user-attachments/assets/af858da5-3e07-448d-86bd-8eacdf3bf8d1"
/>
Annotated:
```
≈ tailwindcss v4.3.2
Done in 105ms Initial build
Done in 3ms Saved a file that resulted in a no-op
Done in 2ms Saved a file that resulted in a no-op
Done in 3ms Saved a file that resulted in a no-op
Done in 53ms Saved a file with a new class
Done in 2ms Saved a file that resulted in a no-op
Done in 2ms Saved a file that resulted in a no-op
Done in 3ms Saved a file that resulted in a no-op
Done in 88ms Saved a the input.css file
Done in 3ms Saved a file that resulted in a no-op
Polling for changes…
```
We check the file system every `250ms` by default, but we won't log to
prevent spamming the terminal.
This PR fixes an issue where new PostCSS release could lead to type
related issues if newer versions change the types.
Right now `@tailwindcss/postcss` uses a hardcoded PostCSS version. Let's
loosen this up and use a semver range instead.
Fixes: #20288
## Test plan
1. All tests still pass
This PR improves the release script:
- The `node-linker=hoisted` was missing for the `wasm32-wasi` package
(this is because of the pnpm v11 changes where it migrated the
noide-linker setup from `.npmrc` to a flag during `pack`)
- Notify discord in case the release fails
## Test plan
1. All tests should pass because we didn't change anything related to
code
2. Unfortunately, the only way to properly testing this is to merge it
Sometimes this is flaky on CI, even though it doesn't make any sense
because we use `setTimeout(_, 500)` which should _at least_ result in
500ms...
But sometimes this results into:
```
AssertionError: expected 499.76 to be greater than or equal to 500
```
This PR bumps the repo to pnpm v11 (from v9).
I kept running into weird Windows specific issues for the integration
tests due to some shims but they all pass right now.
Bumping to pnpm v11 also meant that everything is driven by a
`pnpm-workspace.yaml` file, and changes applied via the `pnpm` field in
the `package.json` don't work anymore.
This also moved the `node-linker` setup that was defined in the `.npmrc`
file for the wasm oxide build into the `pnpm-workspace.yaml` file.
Ideally this is scoped to just this package, but I couldn't get that to
work, so it's applied to all packages right now.
[ci-all]
This PR ignores Lightning CSS warnings for the unknow at-rule
`@position-try`.
This is a temporary fix/workaround until support for `@position-try`
lands in Lightning CSS:
https://github.com/parcel-bundler/lightningcss/pull/1238Fixes: #20275
## Test plan
Ran a test based on the issue:
Before:
```shellsession
❯ tw -i x.css -o out.css --optimize
≈ tailwindcss v4.3.1
Found 1 warning while optimizing generated CSS:
│ position-try-fallbacks: --flip-above;
│ }
│ @position-try --flip-above {
┆ ^-- Unknown at rule: @position-try
┆
│ top: auto;
│ bottom: 0;
Done in 29ms
```
After:
```shellsession
❯ tw -i x.css -o out.css --optimize
≈ tailwindcss v4.3.1
Done in 14ms
```
In newer Vite versions this extension matters, without the
vite/resolvers integration tests won't work.
Since this is still a placeholder fake file where Vite will run
`dirname` on, the actual file doesn't really matter as long as it's
relative to this file.
This PR handles template toolkit syntax as a pre-processor step such
that `%]` and `[%` are seen as valid boundary characters.
This is handled for the `.tt`, `.tt2` and `.tx` file extensions. It's
not handled if this syntax is used in `.html` files because then
everybody pays a pre processor cost even if you don't need this syntax
in most cases.
This now ensures that a `template.tx` like this:
```html
<div class="[% IF $is_open %]bg-white/40[% ELSE %]bg-white/10[% END %]"></div>
<!-- ^^^^^^^^^^^ ^^^^^^^^^^^ -->
```
Extracts the classes in between those conditions correctly.
This also fixes a small issue related to Maud, a template engine for
Rust where conditionals like `p.text-black[condition]` caused the
`text-black` class not to be extracted. This is fixed as part of this PR
because it was commented on the linked issue.
Fixes: #20233
## Test plan
1. Added a new extractor
2. Added regression tests
3. All existing tests pass
This PR fixes an issue where a `@source` pointing to a concrete file
could result in scanning the entire parent folder instead of only
looking for the file we are actually interested in.
When we optimize a `@source`, we move all the static parts of the
pattern to the `base`. This means that a `@source` like this:
```css
@source "../../app.config.ts";
```
Resolves to:
```rs
SourceEntry::Pattern { base: "/Users", pattern: "/app.config.ts" }
```
When walking the `base`, we would only emit an `!app.config.ts` rule.
This means that _everything_ in the `/Users` folder is still walked, and
the result is then thrown away. If you take a look at the `gitignore`
equivalent (which is what we build behind the scenes), then we would
essentially create the following:
```gitignore
!app.config.ts
```
But if you know how `gitignore` files work, then you know that this does
force `app.config.ts` to _not_ be ignored, but it doesn't say anything
about all the other files/folders.
The fix is to restrict the `base` so that we ignore everything in the
folder, and then explicitly re-include only the pattern we care about.
Fixing this would result in the following:
```gitignore
*
!foo.ts
```
In the reproduction from #20255 this takes the build from appearing to
hang (~22s) down to ~20ms on my machine.
There are a few edge cases we have to be careful about:
**Multiple patterns for the same base.** If we have multiple `@source`
directives for the same folder:
```css
@source "./src/foo.ts";
@source "./src/bar.ts";
```
Then blindly emitting `*` for each one would result in this `.gitignore`
equivalent:
```gitignore
*
!foo.ts
*
!bar.ts
```
Notice that the second `*` would end up ignoring `foo.ts` again. To
avoid this, we only emit the `*` rule once per `base`.
**Dynamic parts in intermediate folders.** If the pattern still contains
a `*` in one of its folders:
```css
@source "./src/ba*/*.html";
```
This resolves to:
```rs
SourceEntry::Pattern { base: "/src", pattern: "/ba*/*.html" }
```
If we now inject the `*` rule for `/src`, then we would never walk the
`ba*` folders (e.g. `bar` or `baz`). To fix this, we add inverse rules
for each parent segment of the pattern:
```gitignore
* ← ignore everything
!/ba*/ ← except for the `ba*/` folders, so we walk into them
!/ba*/*.html ← then scan the `*.html` files in them
```
**Bases already covered by a broader source.** If the `base` is already
included (or nested) under an unrestricted source (an `Auto`/`External`
source, or a `Pattern` containing `**`), then we leave it alone.
Restricting it would incorrectly hide siblings that the broader source
is supposed to pick up. For example:
```css
@source "**/*";
@source "./src/components/button.html";
```
Here the `**/*` source should keep auto-detecting every file, so we must
_not_ restrict `src/components` just because there's a more specific
`@source` pointing to it.
Source order is preserved throughout, so later `@source not …` rules can
still override an earlier restricted source.
Fixes: #20255
## Test plan
1. Added unit tests realted to this `sources` logic
2. Added integration like tests for the scanner itself
3. All other tests should pass as-s
4. Should work on each OS [ci-all]
This PR fixes an issue where intellisense recommends this
canonicalization:
```diff
- text-[calc(var(--spacing)*4)]
+ text-[--spacing(4)]
```
Which is correct, but the issue is that the result is different due to
ambiguity of the `text-*` utilities.
```css
.text-\[calc\(var\(--spacing\)\*4\)\] {
font-size: calc(var(--spacing) * 4);
}
.text-\[--spacing\(4\)\] {
color: calc(var(--spacing, 0.25rem) * 4);
}
```
Notice that we're using `color` all of a sudden? This is because that's
the default and we infer the data type based on the arbitrary value. The
`calc(…)` infers that the type is `length`, but we don't know what the
type of `--spacing(…)` is so we fallback to the default type which would
be `color`.
This PR makes sure that built in functions like `--alpha(…)` and
`--spacing(…)` are resolved as `color` and `length` respectively.
With this fix in place, this is the result:
```css
.text-\[calc\(var\(--spacing\)\*4\)\] {
font-size: calc(var(--spacing) * 4);
}
.text-\[--spacing\(4\)\] {
font-size: calc(var(--spacing, 0.25rem) * 4);
}
```
Fixes: #20256Fixes: #20258
## Test plan
1. Added a regression test to make sure this doesn't happen anymore
This PR doesn't fix any issues, but it does add an integration test (as
a regression test) to make sure that `@variant` with default variants
and custom variants can be used inside of JS based plugin APIs.
In Tailwind CSS v4.3.1 we introduced a PR that handles `@variant` in the
`addBase` Plugin API
(https://github.com/tailwindlabs/tailwindcss/pull/19480). This was a bit
of an older PR, but the tests made sense, so it was merged.
However, by introducing that PR, we introduced a bug that the `@variant`
was handled too early. If you added custom variants later _and_ used it
in the `addBase`, then you would get an error since the variant isn't
available (yet).
That issue was fixed by
https://github.com/tailwindlabs/tailwindcss/pull/20247
Now the question remains, why did we even have the original PR when it
already worked?
The use case we had was using `@variant` as part of the
`@tailwindcss/typography` plugin configuration for one of our templates.
I was indeed able to reproduce the issue where `@variant lg` was seen in
the output CSS file.
Turns out that this template was using `@tailwindcss/typography` +
`@variant` in the configuration, but it was also using Tailwind CSS
v4.1.15.
Upgrading to the latest version automagically fixed the issue we had.
This is also the behavior you can see in the integration test.
The correct behavior was introduced in an even older PR
https://github.com/tailwindlabs/tailwindcss/pull/19263
All that said, everything should work in the next release related to
`@variant` usages inside JS based APIs.
**Tiny improvement**
While debugging what's going on, I noticed that we looped over the AST
to get some nodes out and we did that twice. This PR also improves that
by re-using the same list of nodes instead of computing it twice. This
won't have a huge impact, but it happened while compiling every single
utility which is not ideal.
## Test plan
1. All tests should pass
2. I can't see `@variant` in the output CSS file
Input:
<img width="655" height="323" alt="image"
src="https://github.com/user-attachments/assets/20c8d524-3575-488c-b0c0-5c4669f37dc7"
/>
Before:
<img width="477" height="175" alt="image"
src="https://github.com/user-attachments/assets/045e2086-1d4b-487c-96ff-676351412935"
/>
After:
<img width="484" height="175" alt="image"
src="https://github.com/user-attachments/assets/24d950b1-7c28-40f8-96bc-81b38be0e7a3"
/>
This PR fixes an issue where `@variant` inside `addBase` is being used
with a custom variant.
The issue is that we substitute the `@variant` calls immediately when we
call the `addBase` function. That means that variants that aren't
processed yet will error out.
This is a regression, because this used to work in Tailwind CSS v4.3.0
and started failing in Tailwind CSS v4.3.1.
## Test plan
1. Added a regression test
This PR fixes an issue where if the `--input` file (when using
`@tailwindcss/cli`) lives in an ignored folder, then changes to the
input file won't trigger a rebuild.
This happened in #17632 where the input file lives in the `assets/`
folder which is ignored by default.
However, if you make a change to the input file, then the CLI doesn't
restart which means that you can't update the `@source` directives
without quitting the program and re-starting it manually.
This PR solves that by automatically injecting an `@source` with the
path to the input file. This way the CLI will see changes, even if the
input file is in an ignored directory.
Fixes: #17632
## Test plan
1. Added an integration test
2. Existing tests pass
3. Reproduced it on the
Before:
<img width="1122" height="1376"
alt="file-295ce4696b6b3199a3915c63f8bb50cd"
src="https://github.com/user-attachments/assets/09e5e965-38d1-474d-bfc6-3b5e9bca73b6"
/>
After:
<img width="1122" height="1376"
alt="file-301b2f2e06aee045957355014ae5de87"
src="https://github.com/user-attachments/assets/2b6d4cba-f456-4138-98bd-2259876fe70a"
/>
This PR might fix an issue where resolvers don't work on deno v2.8.x
(they do work on deno v2.7.x) when using `@tailwindcss/vite`.
This happens when the `context.parentURL` is not actually a URL at all,
and therefore the `new URL(…)` just crashes. This PR will fallback to
the incoming result for files that are not passed proper URLs.
Fixes: #20232
## Test plan
1. Existing tests pass
2. Can't seem to figure out how to test this in the reproduction issue
without publishing first. So going to merge this and test the insiders
version instead.
This PR adds bare value support for `auto-rows-*` and `auto-cols-*`.
We first introduced `auto-rows-auto`, `auto-rows-min`, `auto-rows-max`
and `auto-rows-fr` (same for `auto-cols-*`) back in Tailwind CSS v1.9
(https://v1.tailwindcss.com/docs/grid-auto-rows#app) but we haven't
touched it since.
This PR now adds support for bare values that use the spacing scale.
That means that you can now use `auto-rows-12` or `auto-cols-12` which
will result in the following CSS:
```css
.auto-cols-12 {
grid-auto-columns: calc(var(--spacing) * 12);
}
.auto-rows-12 {
grid-auto-rows: calc(var(--spacing) * 12);
}
```
We could also add support for percentage based values. The only question
is what the syntax should be. This can either be `auto-rows-3/4` or
`auto-rows-75%`.
For the fraction case, we already have `w-3/4` and `aspect-3/4` even
though they both have a different value as a result:
```css
.aspect-3\/4 {
aspect-ratio: 3/4;
}
.w-3\/4 {
width: calc(3 / 4 * 100%);
}
```
We also have some precedence for the `%` value as well, e.g. `via-10%`
for gradient color stops.
I think I would personally towards the `auto-rows-75%` value instead of
`auto-rows-3/4`. The fraction syntax works great for aspect ratio
because that's literally what it is (`aspect-16/9`). The fraction also
works great for widths, because you typically have 2 elements next to
each other:
```html
<div>
<div class="w-1/3"></div>
<div class="w-2/3"></div>
</div>
```
Since you only use the `auto-rows-*` once on a parent element, I think
the `auto-rows-75%` makes a bit more sense than `auto-rows-3/4` since
there is no _other_ element (at least not that I can think of).
## TODO
- [ ] Support percentages?
- [ ] Syntax A: `auto-rows-3/4`
- [ ] Syntax B: `auto-rows-75%`
- [ ] Syntax C: support both, but that seems silly
Percentage support isn't a blocker for this PR, since you can always use
`auto-rows-[75%]` if you want
## Test plan
1. Added a test to prove that this works
1. Existing tests still pass
Requested by:
https://github.com/tailwindlabs/tailwindcss/discussions/20225
This PR fixes an issue on Windows where the `@tailwindcss/cli` with the
`--watch` flag crashes when using a `@source` with a base path that
doesn't exist on disk.
This happens when setting up the `@parce/watcher` for directories that
don't exist. This PR essentially filters out these directories that
don't exist on disk to prevent the crash.
It might be that if you add the folder _later_, while the watcher is
already watching, that you have to restart the `@tailwindcss/cli` (or
save the `index.css` (the file that contains the `@source` directives),
this also recreates watchers from scratch).
If this issue causes problems for `@tailwindcss/postcss` and
`@tailwindcss/vite` in the future as well, then we can move this logic
back to Oxide. We do maintain the incoming `@source` files as best as
possible without resolving to absolute paths. Back when we did resolve
them, if that process error'd we just never returned the glob.
The root cause is still referencing folders that don't exist.
Fixes: #20231
## Test plan
1. Added a failing test, that did fail on Windows
2. Once fixed, all tests should pass
[ci-all]
---------
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
## Summary
Fixes#20219.
The `@tailwindcss/postcss` exports map serves the CJS-shaped
`dist/index.d.ts` (`export = _default`) for both the `import` and
`require` conditions, while the correct ESM declaration file
`dist/index.d.mts` (`export { _default as default }`) is built and
published but never referenced. Type checkers that treat the import
condition as ESM reject the default import with TS1192 — concretely,
`deno check` on Deno 2.8.3+ (which ships TypeScript 6.0) fails on
`import tailwindcss from "@tailwindcss/postcss"`.
This splits the export entry into per-condition `types` blocks so ESM
importers resolve `index.d.mts` and CJS consumers keep `index.d.ts` —
the same shape `@tailwindcss/vite` already uses (`"types":
"./dist/index.d.mts"`).
Two notes on the issue as filed:
- Stock `tsc` with NodeNext does **not** reproduce the error
(declaration file format follows the file extension and package `type`,
not the matched condition), so I didn't take the suggested `export =` →
`export default` change in `index.d.ts` — that would break CJS
consumers, and the correct ESM declarations already ship.
- `@tailwindcss/node` has the same single-`types` exports shape; happy
to follow up there if you want parity.
## Test plan
Against `@tailwindcss/postcss@4.3.0` with the published exports map,
then again with only this `package.json` change applied to the installed
package:
```sh
# Deno 2.8.3 (TypeScript 6.0), nodeModulesDir: auto
deno check main.ts # before: TS1192 "Module ... index.d.ts has no default export" — after: passes
```
```sh
# typescript@6.0.0-dev (NodeNext), one ESM importer + one .cts require importer
tsc --noEmit # passes both before and after (no regression for npm consumers)
```
`@arethetypeswrong/cli`:
| | published 4.3.0 | with this change |
|---|---|---|
| node16 (from ESM) | 🎭 Masquerading as CJS | 🟢 (ESM) |
| node16 (from CJS) | 🟢 (CJS) | 🟢 (CJS) |
| bundler | 🟢 | 🟢 |
This PR fixes a bug where we suggest a canonicalization with a high
precision number.
E.g.:
`w-[calc(100%/3.5)]` → `w-[28.571428571428573%]`
While this is technically correct, it's also not as user friendly. This
PR solves this issue by checking whether the result has a precision of
`.xx` at most. If that's not the case, then we keep the original
expression.
Fixes:
https://github.com/tailwindlabs/tailwindcss-intellisense/issues/1591
## Test plan
1. Added an a regression test for this situation
2. Existing tests pass
## Summary
Fixes a double word typo in a test comment: 'No need to to wrap' → 'No
need to wrap'.
## Test plan
This is a comment-only change in a test file. No functional changes.
Co-authored-by: Codex <codex@openai.com>
This PR fixes an issue where we were over-scanning because we lost
pattern information when a `@source` ended in `**/*` and contained other
dynamic parts in the glob pattern.
Noticed this while debugging and working on #20214. Let's say you have
the following:
```css
@source './blog/*/foo/bar/baz/**/*';
```
We make sure that folders or patterns ending in `**/*` are converted to
"auto sources", meaning that auto content detection should be used in
these folders.
However, when doing so, we would only take the `base` path of the glob.
And since we have "dynamic" parts (the `*`) in the pattern, that should
not be the case.
So the `@source` from above, would be turned into:
```rs
SourceEntry::Auto { base = "/Users/projects/project/blog" }
```
Notice that we lose all the information related to `/*/foo/bar/baz/`.
While this would technically still work, it also means that we are
scanning **too many files and folders** because we're only interested in
folders in the `blog` folder that also contain `foo/bar/baz`.
If the `*` wasn't there, then this would be correct, because then we
would've moved the `/blog/foo/bar/baz` part to the `base` ahead of time,
and the pattern would just be `/**/*`. That would result in:
```rs
SourceEntry::Auto { base = "/Users/projects/project/blog/foo/bar/baz" }
```
This PR fixes that, by _not_ converting it to an auto-source, and
instead convert it to a pattern:
```rs
SourceEntry::Pattern {
base: "/Users/projects/project/blog",
pattern: "/*/foo/bar/baz/**/*"
}
```
Notice that the static part `blog` is still moved to the base path. But
the rest stays in the `pattern` part as expected.
## Test plan
1. Added a failing test to make sure this doesn't happen anymore
2. Existing tests pass
3. Tested this on the tailwindcss.com codebase using `@source
"../blog/tailwindcss*/**/*";`
```diff
diff --git a/./tailwindcss-55526.log b/./tailwindcss-55527.log
index ce79c5da..03e97598 100644
--- a/./tailwindcss-55526.log
+++ b/./tailwindcss-55527.log
@@ -2,50 +2,9 @@ INFO tailwindcss_oxide::scanner: Provided sources:
INFO tailwindcss_oxide::scanner: Source: PublicSourceEntry { base: "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/app", pattern: "../blog/tailwindcss*/**/*", negated: false }
INFO tailwindcss_oxide::scanner: Source: PublicSourceEntry { base: "/Users/robin/.bun/bin", pattern: "bun", negated: true }
INFO tailwindcss_oxide::scanner: Optimized sources:
-INFO tailwindcss_oxide::scanner: Source: Auto { base: "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog" }
+INFO tailwindcss_oxide::scanner: Source: Pattern { base: "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog", pattern: "/tailwindcss*/**/*" }
INFO tailwindcss_oxide::scanner: Source: Ignored { base: "/Users/robin/.bun/bin", pattern: "/bun" }
INFO discover_sources: tailwindcss_oxide::scanner: enter
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/2022-05-23-headless-ui-v1-6-tailwind-ui-team-management/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/2022-06-23-tailwind-templates-and-all-access/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/2022-08-17-tailwind-framer-motion-template-and-tailwind-jobs/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/2022-09-09-new-personal-website-heroicons-2-headless-ui-v17/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/2022-12-15-protocol-api-documentation-template/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/2023-04-24-new-changelog-template-and-the-biggest-tailwind-ui-update-ever/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/2023-07-18-tailwind-connect-2023-recap/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/2023-08-07-meet-studio-our-new-agency-template/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/2024-05-24-catalyst-application-layouts/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/2024-05-30-prettier-plugin-collapse-whitespace/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/2024-06-21-headless-ui-v2-1/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/2024-09-12-radiant-a-beautiful-new-marketing-site-template/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/2025-05-14-compass-course-starter-kit/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/automatic-class-sorting-with-prettier/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/building-react-and-vue-support-for-tailwind-ui/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/building-the-tailwind-blog/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/designing-tailwind-ui-ecommerce/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/from-900-to-1-how-we-hired-robin-malfait/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/headless-ui-unstyled-accessible-ui-components/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/headless-ui-v1-4/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/headless-ui-v1-5/demo.tsx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/headless-ui-v1-5/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/headless-ui-v1/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/headless-ui-v2/examples/HeadlessUIV2Examples.tsx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/headless-ui-v2/examples/StateAttributesExample.tsx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/headless-ui-v2/examples/anchor-positioning.tsx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/headless-ui-v2/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/heroicons-micro/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/heroicons-v1/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/hiring-a-design-engineer-and-staff-engineer/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/introducing-catalyst/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/introducing-heroicons/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/introducing-linting-for-tailwindcss-intellisense/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/introducing-tailwind-play/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/just-in-time-the-next-generation-of-tailwind-css/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/multi-line-truncation-with-tailwindcss-line-clamp/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/simon-vrachliotis-joins-tailwind-labs/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/standalone-cli/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/tailwind-plus/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/tailwind-ui-ecommerce/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/tailwind-ui-now-with-react-and-vue-support/index.mdx"
INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/tailwindcss-1-5/index.mdx"
INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/tailwindcss-1-6/index.mdx"
INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/tailwindcss-1-7/index.mdx"
@@ -68,10 +27,4 @@ INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/t
INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/tailwindcss-v4-beta/index.mdx"
INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/tailwindcss-v4/color-palette.tsx"
INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/tailwindcss-v4/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/utility-friendly-transitions-with-tailwindui-react/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/vanilla-js-support-for-tailwind-plus/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/welcoming-brad-cornes-to-the-tailwind-team/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/welcoming-david-luhr-to-tailwind-labs/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/welcoming-james-mcdonald-to-tailwind-labs/index.mdx"
-INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/tailwindlabs/tailwindcss.com/src/blog/whats-new-in-tailwindcss-on-youtube/index.mdx"
INFO discover_sources: tailwindcss_oxide::scanner: exit
```
Notice now that a lot of files are skipped as expected since we-re not
accidentally over-scanning now.
[ci-all]
This PR fixes an issue where a `@source` that's pointing to a folder
that is git ignored, is also ignored by the `@source` even if it's
explicitly added.
Internally, we convert `@source` directives from `PublicSourceEntry`s to
`SourceEntry`s where we have dedicated enum branches for `Auto`,
`Pattern`, `Ignored` and `External`.
The `Auto` one accepts a `base` path, and will be used for auto content
detection. However, these paths will make use of all the default auto
content detection rules, which includes git ignore rules.
We also have `External` where we link to something that's "external" to
the current repo. We can probably improve this name, but it's external
in the sense that it won't show up on GitHub for example, aka ignored.
We have some content dirs that we ignore by default, such as the
`node_modules` folder. When you do use `@source` with `node_modules` in
the path, then we will mark it as an `external` resource which does not
look at the `gitignore` related rules and allowing it to be included
this way.
The idea with this is that, even though the folder is ignored by
default, you can still include files from the folder by explicitly using
the `@source` directive.
The issue as seen in #19844 is using `vendor/` instead of
`node_modules/` which is _not_ ignored by default. While we can add
`vendor/` to this same ignored dirs list, it will result in a breaking
change because this folder is often used by the Laravel community to
store some resources in.
This PR fixes this problem by not only looking at the content dirs we
ignore by default, but also looking at the actual git ignore state of
this folder. If it turns out that this is ignored, then we promote the
`Auto` source to an `External` source.
Fixes: #19844Closes: #20057
## Test plan
1. Added integration tests for this situation
2. Ran the fix on the reproduction from #19844. If we run the CLI with
the `DEBUG=*` environment variable, the log file produces these results:
```diff
diff --git a/./tailwindcss-29207.log b/./tailwindcss-30381.log
index bc3017c..921af0e 100644
--- a/./tailwindcss-29207.log
+++ b/./tailwindcss-30381.log
@@ -6,8 +6,9 @@ INFO tailwindcss_oxide::scanner: Source: PublicSourceEntry { base: "/Users/robin
INFO tailwindcss_oxide::scanner: Optimized sources:
INFO tailwindcss_oxide::scanner: Source: Pattern { base: "/Users/robin/github.com/GrimLink/tailwind-gitignore-bug/app/design/frontend/theme", pattern: "/**/*.phtml" }
INFO tailwindcss_oxide::scanner: Source: Pattern { base: "/Users/robin/github.com/GrimLink/tailwind-gitignore-bug/app/design/frontend/theme", pattern: "/**/*.xml" }
-INFO tailwindcss_oxide::scanner: Source: Auto { base: "/Users/robin/github.com/GrimLink/tailwind-gitignore-bug/vendor/acme/theme" }
+INFO tailwindcss_oxide::scanner: Source: External { base: "/Users/robin/github.com/GrimLink/tailwind-gitignore-bug/vendor/acme/theme" }
INFO tailwindcss_oxide::scanner: Source: Ignored { base: "/Users/robin/.fnm/node-versions/v26.1.0/installation/bin", pattern: "/node" }
INFO discover_sources: tailwindcss_oxide::scanner: enter
-INFO discover_sources: tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/GrimLink/tailwind-gitignore-bug/app/design/frontend/theme/index.phtml"
+INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/GrimLink/tailwind-gitignore-bug/app/design/frontend/theme/index.phtml"
+INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/GrimLink/tailwind-gitignore-bug/vendor/acme/theme/module/templates/component.phtml"
INFO discover_sources: tailwindcss_oxide::scanner: exit
```
We're checking some `.gitignore` related files, so let's check on each
OS [ci-all]
<!--depfu-start-->
> 👉 **This PR is queued up to get rebased by Depfu**
<!--depfu-end-->
Here is everything you need to know about this upgrade. Please take a
good look at what changed and the test results before merging this pull
request.
### What changed?
#### ✳️ react (19.2.6 → 19.2.7) ·
[Repo](https://github.com/facebook/react) ·
[Changelog](https://github.com/facebook/react/blob/main/CHANGELOG.md)
<details>
<summary>Release Notes</summary>
<h4><a
href="https://github.com/facebook/react/releases/tag/v19.2.7">19.2.7</a></h4>
<blockquote><h2 dir="auto">React Server Components</h2>
<ul dir="auto">
<li>Fixed missing <code class="notranslate">FormData</code> entries in
Server Actions which regressed in 19.2.6<br>
(<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/36566">#36566</a>
by <a
href="https://bounce.depfu.com/github.com/unstubbable">@unstubbable</a>)</li>
</ul></blockquote>
<p><em>Does any of this look wrong? <a
href="feedback">Please let us
know.</a></em></p>
</details>
<details>
<summary>Commits</summary>
<p><a
href="eaf3e95ca9...6117d7cca4">See
the full diff on Github</a>. The new version differs by 5 commits:</p>
<ul>
<li><a
href="6117d7cca4"><code>Version
19.2.7 (#36591)</code></a></li>
<li><a
href="53a07de1a7"><code>[19.2.x]
Unified release process (#36550)</code></a></li>
<li><a
href="02c444c3f0"><code>[19.2.x][FlightReply]
Don't drop FormData entries in `decodeReplyFromBusboy`
(#36566)</code></a></li>
<li><a
href="750848e565"><code>[19.2.x][ci]
Create artifact attestations for builds on backport branches
(#36559)</code></a></li>
<li><a
href="e1cfa7b6de"><code>[19.2.x]
Enable CI (#36552)</code></a></li>
</ul>
</details>
---
[Depfu](https://depfu.com) will automatically keep this PR
conflict-free, as long as you don't add any commits to this branch
yourself. You can also trigger a rebase manually by commenting with
`@depfu rebase`.
<details><summary>All Depfu comment commands</summary>
<blockquote><dl>
<dt>@depfu rebase</dt><dd>Rebases against your default branch and
redoes this update</dd>
<dt>@depfu recreate</dt><dd>Recreates this PR, overwriting any edits
that you've made to it</dd>
<dt>@depfu merge</dt><dd>Merges this PR once your tests are passing and
conflicts are resolved</dd>
<dt>@depfu cancel merge</dt><dd>Cancels automatic merging of this
PR</dd>
<dt>@depfu close</dt><dd>Closes this PR and deletes the branch</dd>
<dt>@depfu reopen</dt><dd>Restores the branch and reopens this PR (if
it's closed)</dd>
<dt>@depfu pause</dt><dd>Ignores all future updates for this dependency
and closes this PR</dd>
<dt>@depfu pause [minor|major]</dt><dd>Ignores all future minor/major
updates for this dependency and closes this PR</dd>
<dt>@depfu resume</dt><dd>Future versions of this dependency will
create PRs again (leaves this PR as is)</dd>
</dl></blockquote>
</details>
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
Here is everything you need to know about this upgrade. Please take a
good look at what changed and the test results before merging this pull
request.
### What changed?
#### ✳️ next (16.2.6 → 16.2.7) ·
[Repo](https://github.com/vercel/next.js)
<details>
<summary>Release Notes</summary>
<h4><a
href="https://github.com/vercel/next.js/releases/tag/v16.2.7">16.2.7</a></h4>
<blockquote><div class="markdown-alert markdown-alert-note" dir="auto">
<p class="markdown-alert-title" dir="auto"><svg data-component="Octicon"
class="octicon octicon-info mr-2" viewbox="0 0 16 16" version="1.1"
width="16" height="16" aria-hidden="true"><path d="M0 8a8 8 0 1 1 16 0A8
8 0 0 1 0 8Zm8-6.5a6.5 6.5 0 1 0 0 13 6.5 6.5 0 0 0 0-13ZM6.5
7.75A.75.75 0 0 1 7.25 7h1a.75.75 0 0 1 .75.75v2.75h.25a.75.75 0 0 1 0
1.5h-2a.75.75 0 0 1 0-1.5h.25v-2h-.25a.75.75 0 0 1-.75-.75ZM8 6a1 1 0 1
1 0-2 1 1 0 0 1 0 2Z"></path></svg>Note</p>
<p dir="auto">This release is backporting bug fixes. It does
<strong>not</strong> include all pending features/changes on canary.</p>
</div>
<h3 dir="auto">Core Changes</h3>
<ul dir="auto">
<li>Backport documentation fixes for v16.2 (<a
href="https://bounce.depfu.com/github.com/vercel/next.js/pull/93804">#93804</a>)</li>
<li>[backport] Patch <code class="notranslate">playwright-core</code> to
resolve <code class="notranslate">_finishedPromise</code> on <code
class="notranslate">requestFailed</code> (<a
href="https://bounce.depfu.com/github.com/vercel/next.js/pull/93920">#93920</a>)</li>
<li>[backport] Fix dev mode hydration failure when page is served from
HTTP cache (<a
href="https://bounce.depfu.com/github.com/vercel/next.js/pull/93492">#93492</a>)</li>
<li>[backport] Fix catch-all <code
class="notranslate">router.query</code> corruption with <code
class="notranslate">basePath</code> + <code
class="notranslate">rewrites</code> (<a
href="https://bounce.depfu.com/github.com/vercel/next.js/pull/93917">#93917</a>)</li>
<li>[backport] Encode non-ASCII characters in cache tags at construction
(<a
href="https://bounce.depfu.com/github.com/vercel/next.js/pull/93918">#93918</a>)</li>
<li>[backport] Fix server action forwarding loop with middleware
rewrites (<a
href="https://bounce.depfu.com/github.com/vercel/next.js/pull/93919">#93919</a>)</li>
<li>[backport] Turbopack: switch from base40 to base38 hash encoding (<a
href="https://bounce.depfu.com/github.com/vercel/next.js/pull/93932">#93932</a>)</li>
<li>[ci] Disable hanging node 24 typescript tests on 16.2 backport
branch (<a
href="https://bounce.depfu.com/github.com/vercel/next.js/pull/94164">#94164</a>)</li>
<li>[backport] Fix "type: module" in project dir when using standalone
or adapters (<a
href="https://bounce.depfu.com/github.com/vercel/next.js/pull/94050">#94050</a>)</li>
<li>[backport] Propagate adapter preferred regions (<a
href="https://bounce.depfu.com/github.com/vercel/next.js/pull/94200">#94200</a>)</li>
<li>[16.2.x] Don't drop <code class="notranslate">FormData</code>
entries (<a
href="https://bounce.depfu.com/github.com/vercel/next.js/pull/94240">#94240</a>)</li>
<li>[backport] feat(turbopack): add LocalPathOrProjectPath PostCSS
config resolution (<a
href="https://bounce.depfu.com/github.com/vercel/next.js/pull/94284">#94284</a>)</li>
</ul>
<h3 dir="auto">Credits</h3>
<p dir="auto">Huge thanks to <a
href="https://bounce.depfu.com/github.com/eps1lon">@eps1lon</a>, <a
href="https://bounce.depfu.com/github.com/icyJoseph">@icyJoseph</a>, <a
href="https://bounce.depfu.com/github.com/unstubbable">@unstubbable</a>,
<a href="https://bounce.depfu.com/github.com/mischnic">@mischnic</a>, <a
href="https://bounce.depfu.com/github.com/bgw">@bgw</a>, <a
href="https://bounce.depfu.com/github.com/timneutkens">@timneutkens</a>,
and <a
href="https://bounce.depfu.com/github.com/lukesandberg">@lukesandberg</a>
for helping!</p></blockquote>
<p><em>Does any of this look wrong? <a
href="feedback">Please let us
know.</a></em></p>
</details>
<details>
<summary>Commits</summary>
<p><a
href="ee6e79b179...9bd3c26a73">See
the full diff on Github</a>. The new version differs by 13 commits:</p>
<ul>
<li><a
href="9bd3c26a73"><code>v16.2.7</code></a></li>
<li><a
href="c63224f3d8"><code>[backport]
feat(turbopack): add LocalPathOrProjectPath PostCSS config resolution
(#94284)</code></a></li>
<li><a
href="63115c7987"><code>[16.2.x]
Don't drop `FormData` entries (#94240)</code></a></li>
<li><a
href="aef22fdc82"><code>[backport]
Propagate adapter preferred regions (#94200)</code></a></li>
<li><a
href="f126e72271"><code>[backport]
Fix "type: module" in project dir when using standalone or
adapters (#94050)</code></a></li>
<li><a
href="bda3e2aabe"><code>[ci]
Disable hanging node 24 typescript tests on 16.2 backport branch
(#94164)</code></a></li>
<li><a
href="7e16e07c02"><code>[backport]
Turbopack: switch from base40 to base38 hash encoding
(#93932)</code></a></li>
<li><a
href="6139f4b885"><code>[backport]
Fix server action forwarding loop with middleware rewrites
(#93919)</code></a></li>
<li><a
href="c021d10fe9"><code>[backport]
Encode non-ASCII characters in cache tags at construction
(#93918)</code></a></li>
<li><a
href="9184ddb1ae"><code>[backport]
Fix catch-all `router.query` corruption with `basePath` + `rewrites`
(#93917)</code></a></li>
<li><a
href="3279f01607"><code>[backport]
Fix dev mode hydration failure when page is served from HTTP cache
(#93492)</code></a></li>
<li><a
href="ffc4f29682"><code>[backport]
Patch `playwright-core` to resolve `_finishedPromise` on `requestFailed`
(#93920)</code></a></li>
<li><a
href="bc1791dd7e"><code>Backport
documentation fixes for v16.2 (#93804)</code></a></li>
</ul>
</details>
---
[Depfu](https://depfu.com) will automatically keep this PR
conflict-free, as long as you don't add any commits to this branch
yourself. You can also trigger a rebase manually by commenting with
`@depfu rebase`.
<details><summary>All Depfu comment commands</summary>
<blockquote><dl>
<dt>@depfu rebase</dt><dd>Rebases against your default branch and
redoes this update</dd>
<dt>@depfu recreate</dt><dd>Recreates this PR, overwriting any edits
that you've made to it</dd>
<dt>@depfu merge</dt><dd>Merges this PR once your tests are passing and
conflicts are resolved</dd>
<dt>@depfu cancel merge</dt><dd>Cancels automatic merging of this
PR</dd>
<dt>@depfu close</dt><dd>Closes this PR and deletes the branch</dd>
<dt>@depfu reopen</dt><dd>Restores the branch and reopens this PR (if
it's closed)</dd>
<dt>@depfu pause</dt><dd>Ignores all future updates for this dependency
and closes this PR</dd>
<dt>@depfu pause [minor|major]</dt><dd>Ignores all future minor/major
updates for this dependency and closes this PR</dd>
<dt>@depfu resume</dt><dd>Future versions of this dependency will
create PRs again (leaves this PR as is)</dd>
</dl></blockquote>
</details>
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
This PR fixes an issue where the `inset-shadow-none` class did not use
the `inset` keyword. This PR fixes that by introducing the `inset`
keyword:
```diff
.inset-shadow-none {
- --tw-inset-shadow: 0 0 #0000;
+ --tw-inset-shadow: inset 0 0 #0000;
box-shadow: var(--tw-inset-shadow), var
}
```
While the end effect is the same (there will be no shadow), it also
means that we switch between the types of shadows. This results in the
fact that things like transitions don't behave the way they should.
A minimal reproduction looks like this:
https://play.tailwindcss.com/iOrnKWP49a (depending on when you visit
this link, it might be fixed)
## Test plan
1. Updated tests to reflect
2. Verified in the Vite playground that this is the case. In the video
you will notice that the transition is smooth in the fixed case, but
there is no transition in the current state:
https://github.com/user-attachments/assets/15d8c78e-6be5-4c6c-8df9-1044c14e8f39
This PR fixes a crash while using `npx @tailwindcss/upgrade` when
migrating classes with no body inside of an `@layer utilities`.
When running `npx @tailwindcss/upgrade`, one thing we do is migrate the
CSS from:
```css
@layer utilities {
.foo {
color: red;
}
}
```
To:
```css
@utility foo {
color: red;
}
```
We already have some logic that leaves non-classe (IDs, attribute
selectors, ...) alone. But if we are migrating a class that has no body,
then we will migrate that as well:
```css
@layer utilities {
.empty {
}
}
```
Is turned into:
```css
@utility empty {
}
```
But later in the migration process this will result in an error because
a `@utility` has to have at least _some_ nodes.
Ideally, you don't even have CSS that has empty rules since it doesn't
have any effect in the browser (except of making your CSS file bigger),
but it could be that you don't have control over this file, so a fix is
still valid.
This PR solves that by leaving those rules alone, and keep them in an
`@layer utilities`.
Fixes: #20204
## Test plan
1. Added a dedicated test for this usecase
This PR fixes an issue when working with `@source` and `@source not`
that involves symlinks.
Internally our sources are mapped to a source entry where we have a
`base` path and a `pattern`. You can think about this where we insert a
`.gitignore` file in the `base` path for the given pattern.
However, we optimize these entries to move as many "static" parts into
the base path. For example:
```css
@source "./some/folder/here/*.html";
```
Is mapped to something like:
```ts
{ base: "/projects/my-project", pattern: "./some/folder/here/*.html" }
```
We then optimize it by turning it into:
```ts
{ base: "/projects/my-project/some/folder/here", pattern: "*.html" }
```
While doing this, we also use `dunce::canonicalize` to resolve the
actual paths on disk. This means that a symlink is resolved to their
real paths. This can cause issues because the "real" path is not what
you wrote in the `@source` directives.
So before, it could be that you have this:
```css
@source "./some/symlinked-folder/here/*.html";
```
Which was mapped to this on the Rust side:
```ts
{ base: "/projects/my-project", pattern: "./some/symlinked-folder/here/*.html" }
```
But was then optimized to:
```ts
{ base: "/projects/my-project/some/actual-folder/here", pattern: "*.html" }
```
...and we lost the `symlinked-folder` information. This causes issues as
seen in #17985.
With this PR, we keep the symlinked information in those globs since
that's what you wrote in those `@source` directives.
While setting up integration tests, I stumbled upon an issue because I
wanted to test that ignoring a symlinked folder, but including a single
particular file of that ignored folder resulted in that file being
ignored as well. Let's look at an example:
```css
@source '../lib';
@source not '../lib/ignored';
@source '../lib/ignored/except.html';
```
Earlier I mentioned that we create `.gitignore` files based on these
`@source` directives. In this case, when we're dealing with a folder, we
use `**/*` as the contents.
Looking at the example above, we should essentially have something like
this:
```gitignore
# lib/.gitignore
# @source '../lib'
!**/*
# lib/ignored/.gitignore
# @source '../lib/ignored'
**/*
# @source '../lib/ignored/except.html'
!except.html
```
Since it's a `.gitignore` file, we have to invert the globs. But the bug
I noticed is that in reality the result of those gitignores didn't look
like the above, it looked like:
```gitignore
# lib/.gitignore
# @source '../lib'
!**/*
# lib/ignored/.gitignore
# @source '../lib/ignored/except.html'
!except.html
# @source '../lib/ignored'
**/*
```
Notice how the `!except.html` and `**/*` are flipped. When dealing with
`.gitignore` files, the order is important.
This was caused because internally we kept a `BTreeMap` of `BTreeSet`s
where the map was the base path and a set of patterns. The patterns were
sorted because of the `BTreeSet`... which is not what we want.
Fixes: #17985Closes: #20091
## Test plan
1. Added new tests in the scanner tests (on the Rust side)
2. Added integration tests with a symlink to another folder, outside of
the current folder
2. Added integration tests with a symlink to another folder, inside of
the current folder
2. Added integration tests to ensure that the order of `@source` files
with a folder + file is sorted correctly.
3. Since we're dealing with symlinks in these tests, let's test all OSes
[ci-all]
## Summary
This PR fixes a panic that occurs when the Ruby or Vue preprocessors
encounter files with invalid UTF-8 bytes.
**The issue:**
- `ruby.rs:37` and `vue.rs:18` used
`std::str::from_utf8(content).unwrap()`
- This panics when processing files containing invalid UTF-8 bytes
**Error message:**
```
thread panicked at crates/oxide/src/extractor/pre_processors/ruby.rs:37:59:
called `Result::unwrap()` on an `Err` value: Utf8Error { valid_up_to: 45, error_len: Some(1) }
```
**The fix:**
- Wrap UTF-8 conversion in `if let Ok(...)` to gracefully handle invalid
UTF-8
- Skip regex-based template extraction when UTF-8 conversion fails
- Allow byte-level processing to continue (in Ruby's case)
This can happen in Rails projects when:
- Binary files are inadvertently scanned
- Files contain non-UTF-8 encodings
- Files are truncated at multi-byte character boundaries during parallel
processing
## Test plan
- [x] Added `test_invalid_utf8_does_not_panic` test for Ruby
preprocessor
- [x] Added `test_valid_utf8_with_multibyte_chars` test for Ruby
preprocessor
- [x] Added `test_invalid_utf8_does_not_panic` test for Vue preprocessor
- [x] All existing tests pass (`cargo test pre_processors` - 43 tests)
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
This PR fixes an issue where `addClass(opacity-50)` and
`removeClass(opacity-50)` in Twig templates isn't extracted properly.
This fixes that by adding a pre-processor for `.twig` files. This is a
simple initial implementation where we drop the `(` and `)` from the
`addClass` and `removeClass` functions. We don't do any special handling
around escaped characters or parenthesis inside of strings. We will add
them when there is a use case for it. Until then, we'll keep it simple.
If the real API would've been `addClass('opacity-50')` then it would've
worked out of the box.
A workaround you can use today is by using spaces `addClass( opacity-50
)` that works as well.
Fixes: #19458Closes: #20110
## Test plan
1. Added new tests for `twig` extraction
2. Added tests with nested `(` and `)` e.g. `addClass(p-(--value))`
which should properly extarct `p-(--value)`
Here is everything you need to know about this upgrade. Please take a
good look at what changed and the test results before merging this pull
request.
### What changed?
#### ✳️ @napi-rs/cli (3.6.2 → 3.7.0) ·
[Repo](https://github.com/napi-rs/napi-rs)
Sorry, we couldn't find anything useful about this release.
---
[Depfu](https://depfu.com) will automatically keep this PR
conflict-free, as long as you don't add any commits to this branch
yourself. You can also trigger a rebase manually by commenting with
`@depfu rebase`.
<details><summary>All Depfu comment commands</summary>
<blockquote><dl>
<dt>@depfu rebase</dt><dd>Rebases against your default branch and
redoes this update</dd>
<dt>@depfu recreate</dt><dd>Recreates this PR, overwriting any edits
that you've made to it</dd>
<dt>@depfu merge</dt><dd>Merges this PR once your tests are passing and
conflicts are resolved</dd>
<dt>@depfu cancel merge</dt><dd>Cancels automatic merging of this
PR</dd>
<dt>@depfu close</dt><dd>Closes this PR and deletes the branch</dd>
<dt>@depfu reopen</dt><dd>Restores the branch and reopens this PR (if
it's closed)</dd>
<dt>@depfu pause</dt><dd>Ignores all future updates for this dependency
and closes this PR</dd>
<dt>@depfu pause [minor|major]</dt><dd>Ignores all future minor/major
updates for this dependency and closes this PR</dd>
<dt>@depfu resume</dt><dd>Future versions of this dependency will
create PRs again (leaves this PR as is)</dd>
</dl></blockquote>
</details>
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
## Why?
While inspecting a Tailwind-powered site, I noticed selectors like
```css
.inset-0{inset:calc(var(--spacing) * 0)}
.inset-x-0{inset-inline:calc(var(--spacing) * 0)}
.top-0{top:calc(var(--spacing) * 0)}
```
which seem a bit silly, not to mention more complex for the end-user
device parsing the CSS.
## Summary
This PR adjusts helpers to not generate `calc(... * 0)` expressions.
https://github.com/tailwindlabs/tailwindcss/pull/19095 does a similar
thing on CSS AST, but that doesn't run during the build proper.
## Test plan
Ran `pnpm build && pnpm test && pnpm test:integration`. (Some unrelated
tests failed on my machine, hopefully less in CI.)
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
This PR fixes an issue where if you use the standalone CLI, and you move
the standalone CLI into the current project, then we would scan that
standalone CLI as-if it contains Tailwind CSS classes. Since the CLI
contains actual Tailwind CSS classes, and is in fact readable text, this
binary would've been used as a source.
There are a few ways of fixing this, we could hardcode all the known
names, but that would result in an issue if you rename the CLI. We could
check whether it's a binary format and look for magic numbers at the
top. We could also check for a shebang at the top of the file and skip
it that way.
While some of these solutions might still be useful for the future. For
now I fixed it by essentially always ignoring `process.execPath`. That
way we never ever scan the actual executable regardless of whether you
renamed it or not.
Fixes: #20134
## Test plan
- Added an integration tests
- Works on every OS [ci-all]
This PR fixes an issue where the `@tailwindcss/cli` can get into a
non-recoverable state when any of the transitive dependencies break.
Tailwind CSS has 2 kinds of dependencies:
1. All your templates
2. All dependencies that contribute to your configuration such as the
`input.css`, any plugins, any `tailwind.config.js` files and so on.
When a template changes, we just have to scan for new Tailwind CSS
classes and emit a new CSS file. But when the `input.css` file, or any
of its dependencies changes, then we want to perform a full rebuild.
The idea is that your `@theme` might have changed, or new plugins have
been added, or old plugins have been removed.
If you have an `input.css` file:
```css
@import "tailwindcss";
@config "./tailwind.config.js";
```
That relies on a custom config: `tailwind.config.js`:
```js
const theme = require('./my-custom-theme.js');
module.exports = {
theme
}
```
If that file relies on yet another file: `./my-custom-theme.js`, then
changes there should also trigger a full rebuild.
Since we're dealing with JavaScript here, we want to clear the require
cache and rebuild the dependency tree such that another change to any of
these files triggers a full fresh build.
However, if any of those (transitive) dependencies are deleted, then we
will end up in an invalid state. Creating a new compiler will result in
a build error. The compiler won't be able to figure out the entire
dependency tree, and we're stuck.
Once the user fixes the potentially missing dependency, the watchers
will not be watching any of those files because we created a fresh
compiler.
With this PR, we fix that by keeping track of old paths and using those
while we are still in an invalid state. The moment everything is fixed,
a fresh dependency tree is created and everything starts working again
without you having to restart the `@tailwindcss/cli` command.
Fixes: #20113Closes: #20114Closes: #20133
## Test plan
- Added an integration test that removes the transitive dependency.
Re-adding that file later will recover the CLI state.
This PR improves the canonicalization process by limiting the bare
values to a certain amount.
Before this PR, whenever we have an arbitrary value, e.g. `left-[6px]`,
then we prefer to use a bare value instead e.g. `left-1.5`. In most
cases, this makes sense.
However, there are places where this doesn't really make sense
(https://x.com/kettanaito/status/2059987396050268589)
- `left-[99999px]` → `left-24999.75 `
The hard part is to figure out _why_ this feels wrong. The `.75` could
feel wrong, but in the `left-[6px]` → `left-1.5`, the `.5` makes sense.
If we reduce that big number to `left-[99996px]` → `left-24999`, then
there is no floating point but it still feels wrong.
One possibility I can think of is to analyze the incoming value and see
if we find certain patterns. All repeating numbers, fun numbers like
`1337`, common numbers most programmers know such as `720px`, `1280px`,
etc.
But instead of that, I think it's more reasonable to limit the bare
value such that the `px` based value doesn't exceed a big number. We can
improve the logic if there are other cases that don't really make sense.
The biggest value we have in our default theme is `--breakpoint-2xl:
96rem`, which is equivalent to `1536px`.
So I think any bare value that results in a value `<= 1536px` should
probably be fine.
In this case, `left-[99999px]` would stay as `left-[99999px]`, but
`left-[6px]` is still converted to `left-1.5`.
Note: this is only happening for arbitrary values being converted to
bare values _if_ they use the `--spacing` variable internally.
Values such as `z-[99999999999]` will still be converted to
`z-99999999999`, since the intent is still clear.
## Test plan
1. Added new tests for these limitations
2. Other existing tests still pass
This PR fixes a bug in the canonicalization process when we simplify /
fold declarations that contain `0<unit>` values.
The reason we even try to fold these in the first place is to simplify
values such as `m-[0rem]` to `m-0`. The more values we can
fold/canonicalize, the better we can suggest replacements _if_ they are
the same.
One thing we know in CSS is that if you have a `<length>` type, and that
value is `0<unit>`, then we can safely change that to just `0`.
```css
width: 0rem;
width: 0; /* `0` is a <length> */
```
However, if this was part of a `calc(…)` (or another CSS math function),
then this could make the calc expression invalid:
- `calc(1rem + 0px)` → `calc(1rem + 0)` — this goes from _valid_ to
_invalid_
At runtime the `1rem` can be converted to a `px` based valued, then
`16px + 0px` makes sense. Adding `0` without unit does not.
- `calc(1rem * 0px)` → `calc(1rem * 0)` — this goes from _invalid_ to
_valid_
At runtime the `1rem` can be converted to a `px` based value, but `16px
* 0px` would result in `0px^2` which doesn't make sense either.
We will still normalize values such as `-0.0rem` to just `0rem`, but not
`0` if we know it's unsafe to do so.
If we end up with top-level `calc(…)` expressions that can be folded,
then we will try to do that:
- `calc(0px * -1)` → `0`
- `calc(calc(0px * -1) + 1rem)` → `calc(0px + 1rem)`
Notice that the inner `calc(…)` was folded to `0px` not `0` because that
would make the `calc(0 + 1rem)` invalid.
Additionally, we could potentially fold the `calc(0px + 1rem)` to just
`1rem`, but we have to make sure that we don't introduce valid values
from invalid values `calc(0s + 1rem)` would be invalid, but folding it
to `1rem` would make it valid which is not good.
Fixes:
https://github.com/tailwindlabs/tailwindcss-intellisense/issues/1579
This PR improves some of the internal instrumentation tooling we have.
While working on another branch, I updated the instrumentation tooling
to have a few different ways of measuring what's going on.
Until now, we had an `I.start(label)` and corresponding `I.end(label)`.
While this works, it also means that you have to make sure that you call
`I.end(label)` before every `return` to track things properly.
With this PR, I added a `I.span(label, () => /* some callback*/{})` API
that essentially does that in one go. It also handles promises and
resturns the value that was returned from the callback. This can be
useful in situations where you have a one-liner:
```ts
let css = I.span('toCss(…)', () => toCss(ast))
```
If your callback is longer, then you end up in a situation where you
have to indent your code, and if you want to stop measuring you have to
drop code in 2 places and re-indent:
```diff
- I.span('label', () => {
…
- })
```
For this situation, I also added a `using _ = I.track(label)` API
instead. This can also be used in any block and automatically inserts
the `I.end(label)` on every exit point. This relies on the new `using`
keyword, but we already relied on that for the instrumentation module.
Last but not least, the constructor accepts a `shouldReport` which
defaults to the `env.DEBUG`. The reason for this change is so that it's
easier to report / not report during development instead of swapping out
an environment variable. Again, this is internal so there is no public
API change happening here.
## Test plan
All tests should still pass.
This PR cleans up some old stale test that has been skipped from the
beginning.
While this test wants to prove that migrating from Tailwind CSS v3 to
Tailwind CSS v4 can handle the `#{!important}` SCSS notation, it doesn't
prove that we can migrate an entire SCSS project. SCSS has much more
special syntax and we never supported that.
Let's get rid of this test that's doing nothing at the moment.
Especially since we don't want to migrate SCSS projects. Enabling this
might result in the false sense that we _do_ support SCSS migrations
which is not the case.
Closes: #20106
This PR is a small improvement of the current `walk` implementation
where we will expose the `index` and the `siblings` on the current
context.
During a walk, we walk over objects that contain a `nodes: []` field.
The `ctx.parent` that already exists is a reference to the parent node,
but `ctx.siblings` is a reference to the `ctx.parent.nodes`.
The `ctx.index` is the index of the current node we are walking in the
`siblings` array. This way we can prevent the awkward
`ctx.parent?.nodes.indexOf(node)` which is a bit silly because we
already know the nodes we're walking and its index...
The `ctx.parent` can be `null`, but the `ctx.siblings` will never be
`null`, this can be seen in a situation like this:
```ts
let ast: AstNode = [nodeA, nodeB]
walk(ast, (node, ctx) => {
if (node === nodeA) {
ctx.parent === null; // Because there is no parent
ctx.siblings === ast; // Because that's the current list we're looping over
// Before this PR, we would have to do something like:
let siblings = ctx.parent?.nodes ?? ast
}
})
```
In the above example, the `ast` is a separately variable, but if this
was inlined, we would run into some issues:
```ts
walk([nodeA, nodeB], (node, ctx) => {
if (node === nodeA) {
ctx.parent === null; // Because there is no parent
ctx.siblings === ast; // Because that's the current list we're looping over
// At this point, there is no way to get to the `[nodeA, nodeB]` list
// without moving it to a variable first.
}
})
```
So, this PR doesn't change much, the additional information we track is
already known information that is now exposed to the caller of the
`walk` function.
In this PR we did update some usages and got rid of some awkward
`ctx.parent?.nodes ?? []` and `ctx.parent.nodes.indexOf(…)` usages.
## Test plan
- All tests still pass as expected
## Summary
This PR makes Rspack support explicit for `@tailwindcss/webpack` by
adding `@rspack/core` as an optional peer dependency alongside
`webpack`.
The loader already works through Rspack's webpack-compatible loader API,
as shown in this runnable example:
https://github.com/rstackjs/rstack-examples/tree/main/rspack/tailwindcss.
The README and package description are updated to document that usage.
## Test plan
No Rspack-specific tests were added. The loader implementation is
unchanged, and the existing webpack loader tests exercise the same
loader API path that Rspack uses, which should cover the relevant
behavior.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
This PR fixes an issue where a bunch of warnings would be shown related
to sourcemaps.
This happens when we are dealing with CSS files that are _not_ Tailwind
CSS roots. In that case, in the `transform` step, we return the `src` of
that module as-is because we didn't modify anything. However, when
nothing changed, you have to return a `NullValue` such as `undefined`.
So this is a stupid little fix, but it should get rid of a bunch of
annoying warnings.
Fixes: #19930
## Test plan
- Added an integration test to mimic the problem
- Other tests still pass
- Tested it against the reproduction provided in #19930
Before:
<img width="1887" height="1763" alt="8oQNG5Lqr2B"
src="https://github.com/user-attachments/assets/2d8af456-4176-4f18-92a3-5327e395ac6b"
/>
After:
<img width="1885" height="1404" alt="8oQND5kWSb4"
src="https://github.com/user-attachments/assets/7dd98ea4-126b-45d4-9411-0afbacd2c797"
/>
This PR reduces the installed dependencies by cleaning up the
`pnpm-lock.yaml` file.
This also pins `@parcel/watcher` such that the lockfile is generated
properly becauase of the patched dependencies.
This is a follow-up of #19499, but up to date with the latest state of
the repo.
## Test plan
- Lockfile is simpler. Most dependencies stayed the same, and were
published _months_ ago. There are a few cases where we have more recent
published dependencies. There are 7 dependencies that were published in
the last ~24 hours: `node-releases@2.0.46` (10 hours ago),
`electron-to-chromium@1.5.361` (12 hours ago), `semver@7.8.1` (20 hours
ago), `terser@5.48.0` (20 hours ago), `webpack-sources@3.5.0` (5 hours
ago), `vite@8.0.14` (yesterday). All of these but the `terser` version
used OIDC.
- Socket.dev didn't report any issues with the changed dependencies
- All tests still pass
---------
Co-authored-by: James Garbutt <43081j@users.noreply.github.com>
Edited by: @RobinMalfait
This PR adds a new `--silent` option to the `@tailwindcss/cli` to
suppress output (except for errors).
## Test plan
- Existing tests pass
- A new integration test for the `--silent` option was added
---
Original:
## Summary
Small change to add a `--quiet` option.
@adamwathan previously said this type of thing [sounded like a good
idea](https://github.com/tailwindlabs/tailwindcss/issues/8050#issuecomment-1100164351):
> [I] have made a note about the --silent option idea which I think
definitely has value 👍🏻
This is helpful to keep logs high signal in some scenarios. For example,
when I want AI to sift through my foreman logs, where "Done in X"
becomes the dominant log message over time when running tailwind
alongside other things.
## Test plan
I've added an integration test.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
This PR removes the `pnpm-lock.yaml` file from one of the sub-packages.
This is unnecessary and causes confusion. Since this is a monorepo, we
can make use of the `pnpm-lock.yaml` file in the root of the project
instead.
Closes#20097
This PR bumps some of our dependencies, common dependencies were moved
to pnpm's `catalog` feature.
Closes#20092Closes#20085Closes#20075Closes#20066Closes#20062
## Test plan
- All tests still pass
- Each dependency was published some time ago. Webpack has an even newer
version that was published <15min ago. Will update that one later.
[ci-all]
This PR improves GitHub workflows by making sure that:
- Uesed actions are pinned
- We don't persist credentials
- Remove caches from release workflows
- Prevent template expansion when using `env.…` in `run` blocks
- Use the `gh release` instead of `softprops/action-gh-release`
While working on another feature, I noticed that a selector such as
`.foo::before` was parsed as:
```ts
[
{
kind: 'compound',
nodes: [
{ kind: 'selector', value: '.foo' },
{ kind: 'selector', value: ':' },
{ kind: 'selector', value: '::before' },
],
},
]
```
Instead of:
```ts
[
{
kind: 'compound',
nodes: [
{ kind: 'selector', value: '.foo' },
{ kind: 'selector', value: '::before' },
],
},
]
```
So far this hasn't been a real issue in practice, but it is in a
follow-up PR that I'm working on. To keep things separated, I wanted to
fix this behavior in a dedicated PR instead.
## Test plan
1. Added a test case for this situation
2. Other tests still pass
This PR is a follow-up of #20088 to further improve selectors, in
particular the `combinator`.
This PR explicitly types the `combinator` as:
```ts
type Combinator =
| ' ' // Descendant combinator
| '>' // Child combinator
| '+' // Next-sibling combinator
| '~' // Subsequent-sibling combinator
```
This allows us to explicitly test for this pattern in various places,
without us having to call `.trim()` first to know what the actual
combinator was.
In the selector parser itself, we already did a `.trim()` to know
whether we were dealing with a descendant combinator or not. With this
PR, we further ensure that there is no whitespace involved aroudn these
combinators.
This introduces a small problem because we need to be able to re-print a
selector's AST. So if we don't track whitespace, we have to re-introduce
it. But there are situations where we don't want it at all (during
canonicalization).
To solve this, we introduced a `minify = false` option in the
`SelectorParser.toCss`. If it's false (the default), then we introduce
whitespace, otherwise we remove all whitespace.
## Test plan
1. All existing tests pass
2. Manual cleanup/trimming of descendants is no longer necessary
---------
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
This PR introduces a few more nodes in the `SelectorParser`:
- A `list` node
- A `complex` node
- A `compound` node
These names are closer to the CSS Selector AST names
(https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Selectors/Selector_structure),
and are also used in other libraries.
The problem today is that there are situations where we parse a selector
like: `#a.b > .c, .d` as:
```ts
[
{ kind: 'selector', value: '#a' },
{ kind: 'selector', value: '.b' },
{ kind: 'combinator', value: ' > ' },
{ kind: 'selector', value: '.c' },
{ kind: 'separator', value: ', ' },
{ kind: 'selector', value: '.d' }
]
```
Which is a very simple structure, but this contains a flaw that is
annoying to deal with in practice: In order to determine that we are
dealing with multiple selectors, we have to loop through the nodes and
see if a separator occurs somewhere.
The other fun thing is that we already know the difference between
selectors, combinators and separators. So if we tweak this structure a
little bit during parsing, then we can answer the question from above in
a much simpler way:
With this PR, we will parse the selector as:
```ts
[
{
kind: 'list',
nodes: [
{
kind: 'complex',
nodes: [
{
kind: 'compound',
nodes: [
{ kind: 'selector', value: '#a' },
{ kind: 'selector', value: '.b' }
]
},
{ kind: 'combinator', value: '>' },
{ kind: 'selector', value: '.c' }
]
},
{ kind: 'selector', value: '.d' }
]
}
]
```
It definitely looks more complex, but now that we have a `list` node, we
already know that we are dealing with multiple selectors.
If you squint your eyes, in the inner part there is a `compound`
selector. This is essentially a node where each sub-node can be squished
together with no spaces whatsoever.
The `complex` selector is there just to group everything together. In
other tools, a complex selector is often represented as:
```ts
{
kind: 'complex',
combinator: '>',
lhs: { … },
rhs: { … },
}
```
While I want to have the concept of a `complex` node, I didn't go with
this syntax just because I want to keep the concept of `nodes` which
means that we don't need any special handling when using `walk` (which
loops over `.nodes` internally).
The reason this complex node exists is because otherwise you would end
up with this structure:
```ts
[
{
kind: 'list',
nodes: [
{
kind: 'compound',
nodes: [
{ kind: 'selector', value: '#a' },
{ kind: 'selector', value: '.b' }
]
},
{ kind: 'combinator', value: '>' },
{ kind: 'selector', value: '.c' }
{ kind: 'selector', value: '.d' }
]
}
]
```
But if you look at the `list` node now, it's not clear that we are
dealing with `2` selectors since there are 4 nodes. We could solve this
by re-introducing the separator node (`,`). The fact that the `list`
exists tells us that we're dealing with `n` selectors. But to know which
selectors we're dealing with, then we have to look for that `,` node
again, which introduces the original problem.
This is just an internal refactor to make future changes easier.
## Test plan
1. Everything still works as expected (all tests pass)
2. No public API breaking changes, this parser was never exposed
This PR fixes an issue where a `calc(…)` value used in a shadow value
was incorrectly marked as the color of that shadow.
We have this feature where we can have colored shadows, this requires us
to replace the color in a value with a `var(--tw-shadow-color,
<original-value-here>)` such that we can swap out the color.
For this, we have to parse the value and figure out what the color part.
This PR uses the `ValueParser` to parse values, then figure out what the
color part is. The biggest reason for this is that we know what a
"function" is and what a normal "word" is, which allows us to do more
fine-grained checks on a per-type basis.
We tracked a few more functions that we _know_ produce color values, and
a few cases that we know produce length values so therefore can't be the
color.
Some examples:
- `calc(…)`, `min(…)`, `max(…)`, `clamp(…)`, `--spacing(…)` — these all
produce length-values.
- `color(…)`, `color-mix(…)`, `rgba?(…)`, `--alpha(…)` … — these all
produce color values.
Notice that we added `--spacing(…)` and `--alpha(…)` as well, these are
custom functions that Tailwind CSS provides, but we know what it will
eventually map to internally.
Last but not least, we also detect named colors and hex-based colors.
Fixes: #20065Closes: #20074
## Test plan
1. Added an integration test, before the fix the test would've looked
lik this:
```diff
.drop-shadow-calc {
- --tw-drop-shadow-size: drop-shadow(0 0 calc(1 * var(--spacing))
var(--tw-drop-shadow-color, black));
+ --tw-drop-shadow-size: drop-shadow(0 0 var(--tw-drop-shadow-color,
calc(1 * var(--spacing))) black);
--tw-drop-shadow: drop-shadow(var(--drop-shadow-calc));
filter: var(--tw-blur, ) var(--tw-brightness, ) var(--tw-contrast, )
var(--tw-grayscale, ) var(--tw-hue-rotate, ) var(--tw-invert, )
var(--tw-saturate, ) var(--tw-sepia, ) var(--tw-drop-shadow, );
}
```
2. Added more tests related to the shadow replacement logic itself where
we try to infer the color (or the length-values for x, y, blur, spread)
3. All other existing tests pass
This PR fixes an issue where a custom variant declared with a
`@container` wasn't properly negated when using it in combination with
the `not-*` variant.
Given this CSS:
```css
@custom-variant has-a {
@container style(--a) {
@slot;
}
}
```
If you then used `not-has-a:flex`, then the following CSS was produced:
```css
.not-has-a\:flex {
@container style(--a) not {
display: flex;
}
}
```
But we expect the `not` to be in the correct location:
```css
.not-has-a\:flex {
@container not style(--a) {
display: flex;
}
}
```
The issue was that we did some string related checks, and we assumed
that the `query` part of the `@container` (`style(--a)`) had to start
with a `(` character.
To fix this, we now parse the value to an AST, and verify the AST shape
before manipulating it. This now checks whether the `query` part is a
function (both `(…)` and `style(…)` are considered functions).
Also added some additional tests that were already handled, these cases
look like:
- `@container {query}`
- `@container not {query}`
- `@container {name} not {query}`
- `@container {name} {query}`
Fixes: #20058
## Test plan
1. Added a failing test for the use case of the linked issue.
2. Added a few more additional tests to explicitly track some use cases
we handled already but didn't track via tests.
3. All other tests still pass as expected.
The CSS Custom Functions and Mixins spec [is using `@apply` with dashed
idents](https://drafts.csswg.org/css-mixins-1/#apply-rule) for native
mixin support. We shouldn't attempt to treat these as utilities and try
to compile them since they'll fail.
There one intentional limitation with regards to mixins and our use of
`@apply`: We do not allow users to mix utilities and mixins in the same
at-rule. In other words, all of the following `@apply` rules are
invalid:
```css
.foo {
/* Invalid because the rules contain both mixins and utilities */
@apply --my-mixin underline;
@apply --my-mixin() underline;
@apply underline --my-mixin;
@apply underline --my-mixin();
}
```
Aside: Lightning CSS does not yet support this syntax so the results of
a production build won't produce the correct code but we'll at least
handle these correctly in Tailwind CSS itself.
Fixes#19422
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
This PR adds an integration test with Vue where we use a 1000 components
and where each component references a CSS file via `@reference`. Each
component has a unique class that uses `@apply`.
There are some discussions in
https://github.com/tailwindlabs/tailwindcss/discussions/16429 that
mention that this causes OOM issues. Right now I can't reproduce that,
and even with a 1000 components, it produces CSS in a reasonable time:
```
vite v7.3.3 building client environment for production...
✓ 2011 modules transformed.
dist/index.html 0.23 kB │ gzip: 0.18 kB
dist/assets/index-DNVNFkYQ.css 106.65 kB │ gzip: 10.79 kB
dist/assets/index-B8v7EbAN.js 223.84 kB │ gzip: 49.81 kB
✓ built in 3.17s
```
I also started a Vite server and triggered file changes to see if the
memory would grow forever, which it didn't. After a 1000 changes,
everything still behaves smoothly:
<img width="1694" height="1856" alt="image"
src="https://github.com/user-attachments/assets/b16800ae-4dce-4f0d-9d97-25f4cab21c1c"
/>
Making changes manually to a single component, result in proper HMR
request that update the browser:
https://github.com/user-attachments/assets/5c79ffc6-2329-4341-9d25-82b000093e31
This test is here to make sure that it keeps working in the future.
---
If I remove all `@reference` references, and usages of `@apply`, then
the build time is indeed faster:
```
vite v7.3.3 building client environment for production...
✓ 2011 modules transformed.
dist/index.html 0.23 kB │ gzip: 0.18 kB
dist/assets/index-CcxXccJ1.css 106.61 kB │ gzip: 10.76 kB
dist/assets/index-M92YFF0G.js 223.84 kB │ gzip: 49.81 kB
✓ built in 1.97s
```
So we go from `1.97s` → `3.17s`, which is a `1.2s` increase when you use
`@reference` with `@apply` in 1000 files for a fresh build.
I also saw some comments about the CSS growing whenever `@reference` was
used, but as you can see in the snippets above they are at a stable
size.
## Test plan
1. All tests still pass
[ci-all] For testing on Windows / macOS
---------
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
This PR improves the workflows a bit more by:
1. Making sure that we always use `pnpm install` with a frozen lockfile
2. Cleanup permissions
3. By not caching `~/.cargo/bin/`
## Test plan
1. Every test should still pass
[ci-all]
Here is everything you need to know about this upgrade. Please take a
good look at what changed and the test results before merging this pull
request.
### What changed?
#### ✳️ react (19.2.5 → 19.2.6) ·
[Repo](https://github.com/facebook/react) ·
[Changelog](https://github.com/facebook/react/blob/main/CHANGELOG.md)
<details>
<summary>Release Notes</summary>
<h4><a
href="https://github.com/facebook/react/releases/tag/v19.2.6">19.2.6</a></h4>
<blockquote><h2 dir="auto">React Server Components</h2>
<ul dir="auto">
<li>Type hardening and performance improvements<br>
(<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/36425">#36425</a>
by <a href="https://bounce.depfu.com/github.com/eps1lon">@eps1lon</a>
and <a
href="https://bounce.depfu.com/github.com/unstubbable">@unstubbable</a>)</li>
</ul></blockquote>
<p><em>Does any of this look wrong? <a
href="feedback">Please let us
know.</a></em></p>
</details>
<details>
<summary>Commits</summary>
<p><a
href="23f4f9f30d...eaf3e95ca9">See
the full diff on Github</a>. The new version differs by 2 commits:</p>
<ul>
<li><a
href="eaf3e95ca9"><code>Version
19.2.6</code></a></li>
<li><a
href="795203e75e"><code>[FlightReply]
Type hardening and performance improvements</code></a></li>
</ul>
</details>
---
[Depfu](https://depfu.com) will automatically keep this PR
conflict-free, as long as you don't add any commits to this branch
yourself. You can also trigger a rebase manually by commenting with
`@depfu rebase`.
<details><summary>All Depfu comment commands</summary>
<blockquote><dl>
<dt>@depfu rebase</dt><dd>Rebases against your default branch and
redoes this update</dd>
<dt>@depfu recreate</dt><dd>Recreates this PR, overwriting any edits
that you've made to it</dd>
<dt>@depfu merge</dt><dd>Merges this PR once your tests are passing and
conflicts are resolved</dd>
<dt>@depfu cancel merge</dt><dd>Cancels automatic merging of this
PR</dd>
<dt>@depfu close</dt><dd>Closes this PR and deletes the branch</dd>
<dt>@depfu reopen</dt><dd>Restores the branch and reopens this PR (if
it's closed)</dd>
<dt>@depfu pause</dt><dd>Ignores all future updates for this dependency
and closes this PR</dd>
<dt>@depfu pause [minor|major]</dt><dd>Ignores all future minor/major
updates for this dependency and closes this PR</dd>
<dt>@depfu resume</dt><dd>Future versions of this dependency will
create PRs again (leaves this PR as is)</dd>
</dl></blockquote>
</details>
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
## Summary
Fixes#20051.
The collapse canonicalization pass speculatively checks compatible
functional utility roots. When one of those roots comes from a plugin
registered with `matchComponents`/`matchUtilities`, the speculative
candidate can call the plugin callback with an arbitrary value that is
not present in the configured `values` map. Plugins such as the Phoenix
Heroicons helper expect the mapped value shape and can throw while
canonicalize is only probing possible replacements.
This change skips speculative replacement utilities whose property
lookup throws, matching the best-effort behavior already used by utility
signature generation. The original candidates are preserved instead of
crashing canonicalization.
## Test plan
- `source ~/.nvm/nvm.sh && nvm use 22.14.0 && pnpm vitest run
packages/tailwindcss/src/canonicalize-candidates.test.ts -t "does not
crash when plugin matchComponents rejects speculative values during
collapse"`
- `source ~/.nvm/nvm.sh && nvm use 22.14.0 && pnpm vitest run
packages/tailwindcss/src/canonicalize-candidates.test.ts`
- `source ~/.nvm/nvm.sh && nvm use 22.14.0 && pnpm prettier --check
packages/tailwindcss/src/canonicalize-candidates.ts
packages/tailwindcss/src/canonicalize-candidates.test.ts`
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
This PR does some cleanup work in the tests such that every test is
using the custom test helpers instead of creating the compiler itself
and using other test helpers such as `optimizeCss` or `pretty`.
For tests we have some helpers that introduce a small layer of
indirection. While you typically want to avoid indirection, this one
allows us to keep the tests the same whenever we make changes to the
internals.
It also allows us to run through the full core flow where we have to
setup a compiler, pass in the CSS, compile the candidates, optimize the
CSS and pretty print it for snapshot purposes.
Our tests often look like this when you are testing some candidates:
```ts
test('…', async () => {
expect(await run(['flex', 'hover:flex'])).toMatchInlineSnapshot(`
"
.flex {
display: flex;
}
@media (hover: hover) {
.hover\\:flex:hover {
display: flex;
}
}
"
`)
})
```
If you need to compile some CSS, we used the following:
```ts
test('…', async () => {
expect(
await compileCss(css`
@tailwind utilities;
.foo {
@apply flex;
}
`),
).toMatchInlineSnapshot(`
"
.foo {
display: flex;
}
"
`)
})
```
With this PR, I normalized the tests by changing the signatures of those
tests slightly:
```ts
export async function run(
// A list of candidates
candidates: string[],
// Optionally, custom CSS
input = css`
@tailwind utilities;
`,
// Optionally, custom compile options
options: Parameters<typeof compile>[1] = {},
) {
let { build } = await compile(input, options)
return pretty(optimize(build(candidates)).code)
}
// Same as above, but without the candidates
export async function compileCss(css: string, options: Parameters<typeof compile>[1] = {}) {
return run([], css, options)
}
```
They are very similar, but if we migrate _everything_ to `run`, then
there will be situations where you have to use:
```ts
test('…', async () => {
expect(
await run(
[],
css`
@tailwind utilities;
.foo {
@apply flex;
}
`,
),
).toMatchInlineSnapshot(`
"
.foo {
display: flex;
}
"
`)
})
```
Which is a little bit confusing because what does `[]` even mean?
The next big change is that a lot of the tests were manually setting up
the compiler, passing in the CSS and compiler options, then building the
candidates, then manually optimizing the CSS and then manually pretty
printing the resulting CSS for snapshot purposes.
Other tests, didn't use all those steps and skipped the optimization
step for example. This means that not all tests were testing the
end-to-end core workflow.
This PR uses the tests helpers wherever we could. This now also means
that our tests look the same as much as possible.
The biggest goal of this was to get everything in a similar state.
Future PRs that add additional optimizations will now see those
optimizations reflected in the actual test output.
## Test plan
1. All tests still pass
- Some test _output_ has changed because the `optimizeCss` will now kick
in. But this reflects production better anyway.
2. No source code was changed
Here is everything you need to know about this update. Please take a
good look at what changed and the test results before merging this pull
request.
### What changed?
#### ✳️ jiti (2.6.1 → 2.7.0) · [Repo](https://github.com/unjs/jiti) ·
[Changelog](https://github.com/unjs/jiti/blob/main/CHANGELOG.md)
<details>
<summary>Release Notes</summary>
<h4><a
href="https://github.com/unjs/jiti/releases/tag/v2.7.0">2.7.0</a></h4>
<blockquote><p dir="auto"><a
href="https://bounce.depfu.com/github.com/unjs/jiti/compare/v2.6.1...v2.7.0">compare
changes</a></p>
<h3 dir="auto">🚀 Enhancements</h3>
<ul dir="auto">
<li>Add explicit resource management (<code
class="notranslate">using</code>/<code class="notranslate">await
using</code>) support (<a
href="https://bounce.depfu.com/github.com/unjs/jiti/pull/422">#422</a>)</li>
<li>Support opt-in <code class="notranslate">tsconfigPaths</code> (<a
href="https://bounce.depfu.com/github.com/unjs/jiti/pull/427">#427</a>)</li>
<li>Support virtual modules (<a
href="https://bounce.depfu.com/github.com/unjs/jiti/pull/428">#428</a>)</li>
<li>Add <code class="notranslate">jiti/static</code> subpath (<a
href="https://bounce.depfu.com/github.com/unjs/jiti/pull/430">#430</a>)</li>
</ul>
<h3 dir="auto">🔥 Performance</h3>
<ul dir="auto">
<li>
<strong>interopDefault:</strong> Add caching to reduce proxy overhead by
~2x (<a
href="https://bounce.depfu.com/github.com/unjs/jiti/pull/421">#421</a>)</li>
</ul>
<h3 dir="auto">🩹 Fixes</h3>
<ul dir="auto">
<li>
<strong>require:</strong> Passthrough resolve options (<a
href="https://bounce.depfu.com/github.com/unjs/jiti/pull/412">#412</a>)</li>
<li>
<strong>require:</strong> Fallback to transpilation when <code
class="notranslate">tryNative</code> fails (<a
href="https://bounce.depfu.com/github.com/unjs/jiti/pull/413">#413</a>)</li>
<li>Fallback for <code class="notranslate">ENAMETOOLONG</code> when
evaluating esm (<a
href="https://bounce.depfu.com/github.com/unjs/jiti/pull/429">#429</a>)</li>
</ul>
<h3 dir="auto">📦 Build</h3>
<ul dir="auto">
<li>Upgrade rspack to v2 (<a
href="55194fb">55194fb</a>)</li>
<li>Experimental rolldown config (<a
href="8c0243f">8c0243f</a>)</li>
</ul>
<h3 dir="auto">✅ Tests</h3>
<ul dir="auto">
<li>Ignore jsx test for bun/cjs (<a
href="3a744ca">3a744ca</a>)</li>
</ul>
<h3 dir="auto">❤️ Contributors</h3>
<ul dir="auto">
<li>Pooya Parsa (<a
href="https://bounce.depfu.com/github.com/pi0">@pi0</a>)</li>
<li>Kricsleo (<a
href="https://bounce.depfu.com/github.com/kricsleo">@kricsleo</a>)</li>
<li>Espen Hovlandsdal (<a
href="https://bounce.depfu.com/github.com/rexxars">@rexxars</a>)</li>
<li>Rintaro Itokawa (<a
href="https://bounce.depfu.com/github.com/re-taro">@re-taro</a>)</li>
<li>Matteo Collina (<a
href="https://bounce.depfu.com/github.com/mcollina">@mcollina</a>)</li>
<li>Mario Zechner (<a
href="https://bounce.depfu.com/github.com/badlogic">@badlogic</a>)</li>
</ul></blockquote>
<p><em>Does any of this look wrong? <a
href="feedback">Please let us
know.</a></em></p>
</details>
<details>
<summary>Commits</summary>
<p><a
href="aedcdee7fe...fd3bb289b7">See
the full diff on Github</a>. The new version differs by 29 commits:</p>
<ul>
<li><a
href="fd3bb289b7"><code>chore(release):
v2.7.0</code></a></li>
<li><a
href="27fe3f2a49"><code>chore:
update release script</code></a></li>
<li><a
href="4fcd2f23aa"><code>fix:
fallback for `ENAMETOOLONG` when evaluating esm (#429)</code></a></li>
<li><a
href="8c0243f14e"><code>build:
experimental rolldown config</code></a></li>
<li><a
href="55194fbb97"><code>build:
upgrade rspack</code></a></li>
<li><a
href="0abda72c11"><code>ci:
update node test matrix</code></a></li>
<li><a
href="8c7822ef2f"><code>chore:
update tsconfig</code></a></li>
<li><a
href="08fc868c92"><code>chore:
update deps</code></a></li>
<li><a
href="5d552e3beb"><code>feat:
add `jiti/static` export (#430)</code></a></li>
<li><a
href="ae790b0214"><code>feat:
support virtual modules option (#428)</code></a></li>
<li><a
href="a3e705dbdc"><code>fix(require):
fallback to transpilation when `tryNative` fails (#413)</code></a></li>
<li><a
href="4deba16283"><code>chore:
update agents.md</code></a></li>
<li><a
href="f85b0e523d"><code>lint</code></a></li>
<li><a
href="3ce242653f"><code>feat:
support opt-in `tsconfigPaths` (#427)</code></a></li>
<li><a
href="c49c54e42e"><code>chore:
init agents.md</code></a></li>
<li><a
href="b66bd233c2"><code>feat:
add explicit resource management (using/await using) support
(#422)</code></a></li>
<li><a
href="a467d31ffc"><code>perf(interopDefault):
add caching to reduce proxy overhead by ~2x (#421)</code></a></li>
<li><a
href="fe264b49f1"><code>fix(ci):
skip `--coverage` flag for node 18</code></a></li>
<li><a
href="058d91a338"><code>chore:
lint</code></a></li>
<li><a
href="650bc48a76"><code>chore:
add missing prettier dep</code></a></li>
<li><a
href="e28b5e9645"><code>chore(deps):
update autofix-ci/action digest to 7a166d7 (#424)</code></a></li>
<li><a
href="31096aa9e2"><code>chore(deps):
update actions/checkout action to v6 (#419)</code></a></li>
<li><a
href="498e8d73a4"><code>chore:
update deps</code></a></li>
<li><a
href="9ee314fd0f"><code>test:
update</code></a></li>
<li><a
href="3a744ca271"><code>test:
ignore jsx test for bun/cjs</code></a></li>
<li><a
href="e88ac44079"><code>chore:
update deps</code></a></li>
<li><a
href="4045c7a2a2"><code>chore:
fix lint issues</code></a></li>
<li><a
href="39e86de57c"><code>chore(deps):
update actions/setup-node action to v6 (#411)</code></a></li>
<li><a
href="ddb4683d37"><code>fix(require):
passthrough resolve options (#412)</code></a></li>
</ul>
</details>
---
[Depfu](https://depfu.com) will automatically keep this PR
conflict-free, as long as you don't add any commits to this branch
yourself. You can also trigger a rebase manually by commenting with
`@depfu rebase`.
<details><summary>All Depfu comment commands</summary>
<blockquote><dl>
<dt>@depfu rebase</dt><dd>Rebases against your default branch and
redoes this update</dd>
<dt>@depfu recreate</dt><dd>Recreates this PR, overwriting any edits
that you've made to it</dd>
<dt>@depfu merge</dt><dd>Merges this PR once your tests are passing and
conflicts are resolved</dd>
<dt>@depfu cancel merge</dt><dd>Cancels automatic merging of this
PR</dd>
<dt>@depfu close</dt><dd>Closes this PR and deletes the branch</dd>
<dt>@depfu reopen</dt><dd>Restores the branch and reopens this PR (if
it's closed)</dd>
<dt>@depfu pause</dt><dd>Ignores all future updates for this dependency
and closes this PR</dd>
<dt>@depfu pause [minor|major]</dt><dd>Ignores all future minor/major
updates for this dependency and closes this PR</dd>
<dt>@depfu resume</dt><dd>Future versions of this dependency will
create PRs again (leaves this PR as is)</dd>
</dl></blockquote>
</details>
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
Here is everything you need to know about this upgrade. Please take a
good look at what changed and the test results before merging this pull
request.
### What changed?
#### ✳️ postcss (8.5.10 → 8.5.14) ·
[Repo](https://github.com/postcss/postcss) ·
[Changelog](https://github.com/postcss/postcss/blob/main/CHANGELOG.md)
<details>
<summary>Release Notes</summary>
<h4><a
href="https://github.com/postcss/postcss/releases/tag/8.5.14">8.5.14</a></h4>
<blockquote><ul dir="auto">
<li>Fixed custom syntax regression (by <a
href="https://bounce.depfu.com/github.com/43081j">@43081j</a>).</li>
</ul></blockquote>
<h4><a
href="https://github.com/postcss/postcss/releases/tag/8.5.13">8.5.13</a></h4>
<blockquote><ul dir="auto">
<li>Fixed <code class="notranslate">postcss-scss</code> commend
regression.</li>
</ul></blockquote>
<h4><a
href="https://github.com/postcss/postcss/releases/tag/8.5.12">8.5.12</a></h4>
<blockquote><ul dir="auto">
<li>Fixed reading any file via user-generated CSS.</li>
<li>Added <code class="notranslate">opts.unsafeMap</code> to disable
checks.</li>
</ul></blockquote>
<h4><a
href="https://github.com/postcss/postcss/releases/tag/8.5.11">8.5.11</a></h4>
<blockquote><ul dir="auto">
<li>Fixed nested brackets parsing performance (by <a
href="https://bounce.depfu.com/github.com/offset">@offset</a>).</li>
</ul></blockquote>
<p><em>Does any of this look wrong? <a
href="feedback">Please let us
know.</a></em></p>
</details>
<details>
<summary>Commits</summary>
<p><a
href="33b9790263...3ec13948ae">See
the full diff on Github</a>. The new version differs by 21 commits:</p>
<ul>
<li><a
href="3ec13948ae"><code>Release
8.5.14 version</code></a></li>
<li><a
href="f2bb827b20"><code>Update
dependencies</code></a></li>
<li><a
href="d75953d608"><code>Merge
pull request #2084 from 43081j/raw-raws-rawing</code></a></li>
<li><a
href="68bd2139b5"><code>fix:
always call `raw` to retrieve raw values</code></a></li>
<li><a
href="af58cf1b7a"><code>Release
8.5.13 version</code></a></li>
<li><a
href="f227dbd0e9"><code>Temporary
ignore pnpm 11 config</code></a></li>
<li><a
href="d3abd40d72"><code>Update
dependencies</code></a></li>
<li><a
href="dd06c3e113"><code>Revert
stringifier changes because of the conflict with
postcss-scss</code></a></li>
<li><a
href="ae889c815f"><code>Try
to fix CI</code></a></li>
<li><a
href="e0093e49bc"><code>Move
to pnpm 11</code></a></li>
<li><a
href="9bc81c48f0"><code>Release
8.5.12 version</code></a></li>
<li><a
href="85c4d7dab8"><code>Another
try to fix coverage</code></a></li>
<li><a
href="94484cae6d"><code>Try
to fix coverage</code></a></li>
<li><a
href="c64b7488d2"><code>Load
only .map source maps</code></a></li>
<li><a
href="aaec7b78b3"><code>Avoid
throwing JSON parsing errors for non-JSON source maps</code></a></li>
<li><a
href="233fb264ea"><code>Mention
original author of the solution</code></a></li>
<li><a
href="2502f75030"><code>Release
8.5.11 version</code></a></li>
<li><a
href="5ca1901949"><code>Speed
up parsing many nested brackets</code></a></li>
<li><a
href="42b5337dd7"><code>Update
dependencies</code></a></li>
<li><a
href="7e36e153d0"><code>Cache
node.raws locally in Stringifier hot methods</code></a></li>
<li><a
href="8ec62b157b"><code>Bypass
MapGenerator for no-source-map stringify in LazyResult</code></a></li>
</ul>
</details>
---
[Depfu](https://depfu.com) will automatically keep this PR
conflict-free, as long as you don't add any commits to this branch
yourself. You can also trigger a rebase manually by commenting with
`@depfu rebase`.
<details><summary>All Depfu comment commands</summary>
<blockquote><dl>
<dt>@depfu rebase</dt><dd>Rebases against your default branch and
redoes this update</dd>
<dt>@depfu recreate</dt><dd>Recreates this PR, overwriting any edits
that you've made to it</dd>
<dt>@depfu merge</dt><dd>Merges this PR once your tests are passing and
conflicts are resolved</dd>
<dt>@depfu cancel merge</dt><dd>Cancels automatic merging of this
PR</dd>
<dt>@depfu close</dt><dd>Closes this PR and deletes the branch</dd>
<dt>@depfu reopen</dt><dd>Restores the branch and reopens this PR (if
it's closed)</dd>
<dt>@depfu pause</dt><dd>Ignores all future updates for this dependency
and closes this PR</dd>
<dt>@depfu pause [minor|major]</dt><dd>Ignores all future minor/major
updates for this dependency and closes this PR</dd>
<dt>@depfu resume</dt><dd>Future versions of this dependency will
create PRs again (leaves this PR as is)</dd>
</dl></blockquote>
</details>
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
<hr>
🚨 <b>Your current dependencies have known security vulnerabilities</b> 🚨
This dependency update fixes known security vulnerabilities. Please see
the details below and assess their impact carefully. We recommend to
merge and deploy this as soon as possible!
<hr>
Here is everything you need to know about this upgrade. Please take a
good look at what changed and the test results before merging this pull
request.
### What changed?
#### ✳️ next (16.2.4 → 16.2.6) ·
[Repo](https://github.com/vercel/next.js)
<details>
<summary>Security Advisories 🚨</summary>
<h4><a
href="https://bounce.depfu.com/github.com/facebook/react/security/advisories/GHSA-rv78-f8rc-xrxh">🚨
Next.js Vulnerable to Denial of Service with Server Components</a></h4>
<blockquote><p dir="auto">A vulnerability affects certain React Server
Components packages for versions 19.x and frameworks that use the
affected packages, including Next.js 13.x, 14.x, 15.x, and 16.x using
the App Router. The issue is tracked upstream as <a
href="https://bounce.depfu.com/github.com/facebook/react/security/advisories/GHSA-rv78-f8rc-xrxh">CVE-2026-23870</a>.</p>
<p dir="auto">A specially crafted HTTP request can be sent to any App
Router Server Function endpoint that, when deserialized, may trigger
excessive CPU usage. This can result in denial of service in unpatched
environments.</p></blockquote>
<h4><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-36qx-fr4f-26g5">🚨
Next.js has a Middleware / Proxy bypass in Pages Router applications
using i18n</a></h4>
<blockquote><h3 dir="auto">Impact</h3>
<p dir="auto">Applications using the Pages Router with <code
class="notranslate">i18n</code> configured and middleware/proxy-based
authorization can allow unauthorized access to protected page data
through locale-less <code
class="notranslate">/_next/data/<buildId>/<page>.json</code>
requests. In affected configurations, middleware does not run for the
unprefixed data route, allowing an attacker to retrieve SSR JSON for
protected pages without passing the intended authorization checks.</p>
<h3 dir="auto">Fix</h3>
<p dir="auto">The matcher logic was updated to perform the same match as
it would on a non-i18n data route.</p>
<h3 dir="auto">Workarounds</h3>
<p dir="auto">If you cannot upgrade immediately, enforce authorization
in the page's server-side data path instead of relying solely on
middleware.</p></blockquote>
<h4><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-267c-6grr-h53f">🚨
Next.js has a Middleware / Proxy bypass in App Router applications via
segment-prefetch routes</a></h4>
<blockquote><h3 dir="auto">Impact</h3>
<p dir="auto">App Router applications that rely on middleware or
proxy-based checks for authorization can allow unauthorized access
through transport-specific route variants used for segment prefetching.
In affected configurations, specially crafted <code
class="notranslate">.rsc</code> and segment-prefetch URLs can resolve to
the same page without being matched by the intended middleware rule,
which can allow protected content to be reached without the expected
authorization check.</p>
<h3 dir="auto">Fix</h3>
<p dir="auto">We now include App Router transport variants when
generating middleware matchers, so middleware protections are applied
consistently to those requests as well as to the normal page URL.</p>
<h3 dir="auto">Workarounds</h3>
<p dir="auto">If you cannot upgrade immediately, enforce authorization
in the underlying route or page logic instead of relying solely on
middleware.</p></blockquote>
<h4><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-wfc6-r584-vfw7">🚨
Next.js vulnerable to cache poisoning in React Server Component
responses</a></h4>
<blockquote><h3 dir="auto">Impact</h3>
<p dir="auto">Applications using React Server Components can be
vulnerable to cache poisoning when shared caches do not correctly
partition response variants. Under affected conditions, an attacker can
cause an RSC response to be served from the original URL and poison
shared cache entries so later visitors receive component payloads
instead of the expected HTML.</p>
<h3 dir="auto">Fix</h3>
<p dir="auto">We now validate and interpret <code
class="notranslate">RSC</code> request headers consistently across
request classification and rendering, and we enforce the intended
cache-busting behavior so RSC payloads are not unexpectedly served from
the original URL.</p>
<h3 dir="auto">Workarounds</h3>
<p dir="auto">If you cannot upgrade immediately, ensure your CDN or
reverse proxy keys on the relevant RSC request headers and honors <code
class="notranslate">Vary</code>, or disable shared caching for affected
App Router and RSC responses.</p></blockquote>
<h4><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-492v-c6pp-mqqv">🚨
Next.js has a Middleware / Proxy bypass through dynamic route parameter
injection</a></h4>
<blockquote><h3 dir="auto">Impact</h3>
<p dir="auto">Applications that rely on middleware to protect dynamic
routes can be vulnerable to authorization bypass. In affected
deployments, specially crafted query parameters can alter the dynamic
route value seen by the page while leaving the visible path unchanged,
which can allow protected content to be rendered without passing the
expected middleware check.</p>
<h3 dir="auto">Fix</h3>
<p dir="auto">We now only honor internal route-parameter normalization
in trusted routing flows and ignore externally supplied parameter
encodings that should never have been accepted from ordinary
requests.</p>
<h3 dir="auto">Workarounds</h3>
<p dir="auto">If you cannot upgrade immediately, enforce authorization
in route or page logic instead of relying solely on middleware path
matching.</p></blockquote>
<h4><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-c4j6-fc7j-m34r">🚨
Next.js vulnerable to server-side request forgery in applications using
WebSocket upgrades</a></h4>
<blockquote><h3 dir="auto">Impact</h3>
<p dir="auto">Self-hosted applications using the built-in Node.js server
can be vulnerable to server-side request forgery through crafted
WebSocket upgrade requests. An attacker can cause the server to proxy
requests to arbitrary internal or external destinations, which may
expose internal services or cloud metadata endpoints. Vercel-hosted
deployments are not affected.</p>
<h3 dir="auto">Fix</h3>
<p dir="auto">We now apply the same safety checks to WebSocket upgrade
handling that already existed for normal HTTP requests, so upgrade
requests are only proxied when routing has explicitly marked them as
safe external rewrites.</p>
<h3 dir="auto">Workarounds</h3>
<p dir="auto">If you cannot upgrade immediately, do not expose the
origin server directly to untrusted networks. If WebSocket upgrades are
not required, block them at your reverse proxy or load balancer, and
restrict origin egress to internal networks and metadata services where
possible.</p></blockquote>
<h4><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-h64f-5h5j-jqjh">🚨
Next.js has a Denial of Service in the Image Optimization API</a></h4>
<blockquote><h3 dir="auto">Impact</h3>
<p dir="auto">When self-hosting Next.js with the default image loader,
the Image Optimization API fetches local images entirely into memory
without enforcing a maximum size limit. An attacker could cause
out-of-memory conditions by requesting large local assets from the <code
class="notranslate">/_next/image</code> endpoint that match the <code
class="notranslate">images.localPatterns</code> configuration (by
default, all patterns are allowed).</p>
<ul dir="auto">
<li>If you are using <code
class="notranslate">images.localPatterns</code>, only the patterns in
that array are impacted.</li>
<li>If you are using <code class="notranslate">images.unoptimized:
true</code>, you are NOT impacted.</li>
<li>If you are using <code class="notranslate">images.loader:
'custom'</code>, you are NOT impacted.</li>
<li>If you are using Vercel, you are NOT impacted.</li>
</ul>
<h3 dir="auto">Fix</h3>
<p dir="auto">We now apply response size limits consistently to internal
image fetches, not just external ones, and fail oversized responses
before they can exhaust process memory.</p>
<p dir="auto">This can be adjusted using the <code
class="notranslate">images.maximumResponseBody</code> configuration.</p>
<h3 dir="auto">Workarounds</h3>
<p dir="auto">If you cannot upgrade immediately, avoid routing large
local assets through <code class="notranslate">/_next/image</code>,
disable image optimization for large or untrusted local files, or block
image optimization access to those assets at the edge.</p>
<p dir="auto">You can disable using the <code
class="notranslate">images.localPatterns: []</code> configuration. This
will still allow fetching remote images (which is not
impacted).</p></blockquote>
<h4><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-mg66-mrh9-m8jx">🚨
Next.js vulnerable to Denial of Service via connection exhaustion in
applications using Cache Components</a></h4>
<blockquote><h3 dir="auto">Impact</h3>
<p dir="auto">Applications using Partial Prerendering through the Cache
Components feature can be vulnerable to connection exhaustion through
crafted POST requests to a server action. In affected configurations, a
malicious request can trigger a request-body handling deadlock that
leaves connections open for an extended period, consuming file
descriptors and server capacity until legitimate users are denied
service.</p>
<h3 dir="auto">Fix</h3>
<p dir="auto">We now treat the header used for resuming Partial
Prerendered requests as an internal-only header and strip it from
untrusted incoming requests. This header should never be accepted
directly from external clients.</p>
<h3 dir="auto">Workarounds</h3>
<p dir="auto">If you cannot upgrade immediately, block requests that
would be handled by Next.js if they contain the <code
class="notranslate">Next-Resume</code> header at the
edge.</p></blockquote>
<h4><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-gx5p-jg67-6x7h">🚨
Next.js has cross-site scripting in beforeInteractive scripts with
untrusted input</a></h4>
<blockquote><h3 dir="auto">Impact</h3>
<p dir="auto">Applications that use <code
class="notranslate">beforeInteractive</code> scripts together with
untrusted content can be vulnerable to cross-site scripting. In affected
versions, serialized script content was not escaped safely before being
embedded into the document, which could allow attacker-controlled input
to break out of the intended script context and execute arbitrary
JavaScript in a visitor's browser.</p>
<h3 dir="auto">Fix</h3>
<p dir="auto">We now HTML-escape serialized <code
class="notranslate">beforeInteractive</code> script content before
embedding it into the page, preventing attacker-controlled content from
breaking out of the inline script boundary.</p>
<h3 dir="auto">Workarounds</h3>
<p dir="auto">If you cannot upgrade immediately, do not pass untrusted
data into <code class="notranslate">beforeInteractive</code> scripts. If
that pattern is unavoidable, sanitize or escape the content before
embedding it.</p></blockquote>
<h4><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-vfv6-92ff-j949">🚨
Next.js vulnerable to cache poisoning via collisions in React Server
Component cache-busting</a></h4>
<blockquote><h3 dir="auto">Impact</h3>
<p dir="auto">React Server Component responses can be vulnerable to
cache poisoning in deployments that rely on shared caches with
insufficient response partitioning. In affected conditions, collisions
in the <code class="notranslate">_rsc</code> cache-busting value can
allow an attacker to poison cache entries so users receive the wrong
response variant for a given URL.</p>
<h3 dir="auto">Fix</h3>
<p dir="auto">We strengthened the <code class="notranslate">_rsc</code>
cache-busting mechanism to make practical collisions significantly
harder and to better separate response variants that should not share
cache entries.</p>
<h3 dir="auto">Workarounds</h3>
<p dir="auto">If you cannot upgrade immediately, ensure intermediary
caches correctly honor <code class="notranslate">Vary</code> for
RSC-related request headers, or disable shared caching for affected RSC
responses until you can deploy a patched release.</p></blockquote>
<h4><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-ffhc-5mcf-pf4q">🚨
Next.js vulnerable to cross-site scripting in App Router applications
using CSP nonces</a></h4>
<blockquote><h3 dir="auto">Impact</h3>
<p dir="auto">App Router applications that rely on CSP nonces can be
vulnerable to stored cross-site scripting when deployed behind shared
caches. In affected versions, malformed nonce values derived from
request headers could be reflected into rendered HTML in an unsafe way,
allowing an attacker to poison cached responses and cause script
execution for later visitors.</p>
<h3 dir="auto">Fix</h3>
<p dir="auto">We now reject or ignore malformed nonce values before they
are embedded into HTML and apply stricter nonce sanitization so
request-derived nonce data cannot break out of the intended attribute
context.</p>
<h3 dir="auto">Workarounds</h3>
<p dir="auto">If you cannot upgrade immediately, strip inbound <code
class="notranslate">Content-Security-Policy</code> request headers from
untrusted traffic.</p></blockquote>
<h4><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-3g8h-86w9-wvmq">🚨
Next.js's Middleware / Proxy redirects can be cache-poisoned</a></h4>
<blockquote><h3 dir="auto">Impact</h3>
<p dir="auto">Next.js uses the <code
class="notranslate">x-nextjs-data</code> request header for internal
data requests. On affected versions, an external client could send this
header on a normal request to a path handled by middleware that returns
a redirect.</p>
<p dir="auto">When that happened, the middleware/proxy could treat the
request as a data request and replace the standard <code
class="notranslate">Location</code> redirect header with the internal
<code class="notranslate">x-nextjs-redirect</code> header. Browsers do
not follow <code class="notranslate">x-nextjs-redirect</code>, so the
response became an unusable redirect for normal clients.</p>
<p dir="auto">If the application was deployed behind a CDN or reverse
proxy that caches 3xx responses without varying on this header, a single
attacker request could poison the cached redirect response for the
affected path. Subsequent visitors could then receive a cached redirect
response without a <code class="notranslate">Location</code> header,
causing a denial of service for that redirect path until the cache entry
expired or was purged.</p>
<h3 dir="auto">Affected scenarios</h3>
<p dir="auto">This affects applications that:</p>
<ul dir="auto">
<li>use middleware or proxy redirects</li>
<li>are deployed behind a caching CDN or reverse proxy</li>
<li>allow 3xx responses on those paths to be cached without
differentiating internal data requests from normal requests</li>
</ul>
<h3 dir="auto">Fix</h3>
<p dir="auto">The fix stops trusting <code
class="notranslate">x-nextjs-data</code> by itself for middleware
redirect handling. A request is now treated as an internal data request
only when it is validated as such by internal routing state, preserving
legitimate data-request redirect behavior while preventing external
header injection from changing normal redirect responses.</p>
<h3 dir="auto">Workarounds</h3>
<p dir="auto">Before upgrading, users can reduce risk by:</p>
<ul dir="auto">
<li>configuring the CDN or reverse proxy to vary its cache key on <code
class="notranslate">x-nextjs-data</code> for affected responses</li>
</ul></blockquote>
<h4><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-267c-6grr-h53f">🚨
Next.js has a Middleware / Proxy bypass in App Router applications via
segment-prefetch routes - Incomplete Fix Follow-Up</a></h4>
<blockquote><h3 dir="auto">Impact</h3>
<p dir="auto">It was found that the fix addressing <a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-267c-6grr-h53f">CVE-2026-44575</a>
did not apply to <code class="notranslate">middleware.ts</code> with
Turbopack. Refer to <a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-267c-6grr-h53f">CVE-2026-44575</a>
for further details.</p>
<h3 dir="auto">References</h3>
<ul dir="auto">
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-267c-6grr-h53f">CVE
CVE-2026-44575</a></li>
</ul></blockquote>
</details>
<details>
<summary>Release Notes</summary>
<h4><a
href="https://github.com/vercel/next.js/releases/tag/v16.2.6">16.2.6</a></h4>
<blockquote><p dir="auto">This release contains security fixes for the
following advisories:</p>
<p dir="auto">High:</p>
<ul dir="auto">
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-8h8q-6873-q5fj">GHSA-8h8q-6873-q5fj:
Denial of Service with Server Components</a></li>
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-267c-6grr-h53f">GHSA-267c-6grr-h53f:
Middleware / Proxy bypass in App Router applications via
segment-prefetch routes</a></li>
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-26hh-7cqf-hhc6">GHSA-26hh-7cqf-hhc6:
Middleware / Proxy bypass in App Router applications via
segment-prefetch routes - Incomplete Fix Follow-Up</a></li>
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-mg66-mrh9-m8jx">GHSA-mg66-mrh9-m8jx:
Denial of Service via connection exhaustion in applications using Cache
Components</a></li>
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-492v-c6pp-mqqv">GHSA-492v-c6pp-mqqv:
Middleware / Proxy bypass through dynamic route parameter
injection</a></li>
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-c4j6-fc7j-m34r">GHSA-c4j6-fc7j-m34r:
Server-side request forgery in applications using WebSocket
upgrades</a></li>
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-36qx-fr4f-26g5">GHSA-36qx-fr4f-26g5:
Middleware / Proxy bypass in Pages Router applications using
i18n</a></li>
</ul>
<p dir="auto">Moderate:</p>
<ul dir="auto">
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-ffhc-5mcf-pf4q">GHSA-ffhc-5mcf-pf4q:
Cross-site scripting in App Router applications using CSP
nonces</a></li>
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-gx5p-jg67-6x7h">GHSA-gx5p-jg67-6x7h:
Cross-site scripting in beforeInteractive scripts with untrusted
input</a></li>
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-h64f-5h5j-jqjh">GHSA-h64f-5h5j-jqjh:
Denial of Service in the Image Optimization API</a></li>
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-wfc6-r584-vfw7">GHSA-wfc6-r584-vfw7:
Cache poisoning in React Server Component responses</a></li>
</ul>
<p dir="auto">Low:</p>
<ul dir="auto">
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-vfv6-92ff-j949">GHSA-vfv6-92ff-j949:
Cache poisoning via collisions in React Server Component
cache-busting</a></li>
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-3g8h-86w9-wvmq">GHSA-3g8h-86w9-wvmq:
Middleware / Proxy redirects can be cache-poisoned</a></li>
</ul></blockquote>
<h4><a
href="https://github.com/vercel/next.js/releases/tag/v16.2.5">16.2.5</a></h4>
<blockquote><p dir="auto">This release contains security fixes for the
following advisories:</p>
<p dir="auto">High:</p>
<ul dir="auto">
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-8h8q-6873-q5fj">GHSA-8h8q-6873-q5fj:
Denial of Service with Server Components</a></li>
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-267c-6grr-h53f">GHSA-267c-6grr-h53f:
Middleware / Proxy bypass in App Router applications via
segment-prefetch routes</a></li>
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-mg66-mrh9-m8jx">GHSA-mg66-mrh9-m8jx:
Denial of Service via connection exhaustion in applications using Cache
Components</a></li>
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-492v-c6pp-mqqv">GHSA-492v-c6pp-mqqv:
Middleware / Proxy bypass through dynamic route parameter
injection</a></li>
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-c4j6-fc7j-m34r">GHSA-c4j6-fc7j-m34r:
Server-side request forgery in applications using WebSocket
upgrades</a></li>
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-36qx-fr4f-26g5">GHSA-36qx-fr4f-26g5:
Middleware / Proxy bypass in Pages Router applications using
i18n</a></li>
</ul>
<p dir="auto">Moderate:</p>
<ul dir="auto">
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-ffhc-5mcf-pf4q">GHSA-ffhc-5mcf-pf4q:
Cross-site scripting in App Router applications using CSP
nonces</a></li>
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-gx5p-jg67-6x7h">GHSA-gx5p-jg67-6x7h:
Cross-site scripting in beforeInteractive scripts with untrusted
input</a></li>
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-h64f-5h5j-jqjh">GHSA-h64f-5h5j-jqjh:
Denial of Service in the Image Optimization API</a></li>
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-wfc6-r584-vfw7">GHSA-wfc6-r584-vfw7:
Cache poisoning in React Server Component responses</a></li>
</ul>
<p dir="auto">Low:</p>
<ul dir="auto">
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-vfv6-92ff-j949">GHSA-vfv6-92ff-j949:
Cache poisoning via collisions in React Server Component
cache-busting</a></li>
<li><a
href="https://bounce.depfu.com/github.com/vercel/next.js/security/advisories/GHSA-3g8h-86w9-wvmq">GHSA-3g8h-86w9-wvmq:
Middleware / Proxy redirects can be cache-poisoned</a></li>
</ul></blockquote>
<p><em>Does any of this look wrong? <a
href="feedback">Please let us
know.</a></em></p>
</details>
<details>
<summary>Commits</summary>
<p><a
href="2275bd8598...ee6e79b179">See
the full diff on Github</a>. The new version differs by 36 commits:</p>
<ul>
<li><a
href="ee6e79b179"><code>v16.2.6</code></a></li>
<li><a
href="afa053d9eb"><code>Turbopack:
Match proxy matchers with webpack implementation
(#93594)</code></a></li>
<li><a
href="97a154e5bb"><code>Turbopack:
Fix middleware matcher suffix (#93590)</code></a></li>
<li><a
href="83899bc891"><code>[backport]
Disable build caches for production/staging/force-preview deploys
(#93586)</code></a></li>
<li><a
href="7b222b9095"><code>[backport][test]
Pin package manager to patch versions (#93595)</code></a></li>
<li><a
href="a8dc24f1fe"><code>[backport]
Turbopack: more strict vergen setup (#93587)</code></a></li>
<li><a
href="766148f9cd"><code>v16.2.5</code></a></li>
<li><a
href="0dd94836a8"><code>fix:
add explicit checks for RSC header (#83) (#98)</code></a></li>
<li><a
href="d166096c39"><code>fix
proxy matching for segment prefetch URLs (#89) (#96)</code></a></li>
<li><a
href="9d50c0b719"><code>Strip
next-resume header from incoming requests (#92)</code></a></li>
<li><a
href="df7ab5ad72"><code>fix:
skip internal param normalization in unsupported
environments</code></a></li>
<li><a
href="ed41d1d454"><code>Move
htmlescape to shared/lib (#91)</code></a></li>
<li><a
href="b4c6705c70"><code>Ignore
malformed CSP nonce headers</code></a></li>
<li><a
href="5b194ee2d4"><code>router-server:
guard upgrade proxy against absolute-url SSRF (#77)</code></a></li>
<li><a
href="cb171d7494"><code>Fix
i18n middleware matching for default-locale data routes
(#82)</code></a></li>
<li><a
href="89e995431a"><code>[16.x]
Type hardening and performance improvements (#80)</code></a></li>
<li><a
href="66f6017f15"><code>Escape
properties for beforeInteractive scripts (#86)</code></a></li>
<li><a
href="3d98505a24"><code>[backport]
fix: preserve HTTP access fallbacks during prerender recovery
(#93470)</code></a></li>
<li><a
href="bb5ada6e38"><code>[backport]
[test] Deflake `instant-navs-devtools` (#93534)</code></a></li>
<li><a
href="f1c11203d5"><code>[backport]
Fix double-encoding of URL pathname parts in client param parsing
(#93506)</code></a></li>
<li><a
href="2d08397b3d"><code>[backport]
fix accidental test duplication (#93507)</code></a></li>
<li><a
href="75d19ecbb3"><code>[backport]
Include deployment id in `cacheHandlers` keys (#93471)</code></a></li>
<li><a
href="7ab1e2e93d"><code>CI:
Download and run self-contained datadog-ci instead of using pnpm dlx or
npx (#92546)</code></a></li>
<li><a
href="084f2bcf19"><code>[ci]:
trigger signed release commit via API (#93285)</code></a></li>
<li><a
href="a3bb370b00"><code>[ci]:
app-based release workflow (#93245)</code></a></li>
<li><a
href="6e23383c56"><code>[ci]:
add environment to publishRelease flow (#93093)</code></a></li>
<li><a
href="f40b8876e6"><code>[ci]:
remove publish token in favor of OIDC (#93065)</code></a></li>
<li><a
href="f6bda26ef9"><code>Fix
fallback route params case in app-page handler (#93109)</code></a></li>
<li><a
href="70defda2a8"><code>[ci]:
switch to GitHub runners (#93164)</code></a></li>
<li><a
href="af0e96ba23"><code>Fix
invalid HTML response for route-level RSC requests in deployment adapter
(#91541)</code></a></li>
<li><a
href="2cdb7ed34f"><code>[tests]:
fix cache-components.test.ts type error (#93113)</code></a></li>
<li><a
href="8cd3fdc111"><code>test:
scope css data-url typing to fixture (#91877)</code></a></li>
<li><a
href="6fd09bf8ab"><code>Patch
setHeader for direct route handlers (#93101)</code></a></li>
<li><a
href="688ed31e21"><code>Strengthen
_rsc cache-busting param (#92755)</code></a></li>
<li><a
href="62ef305096"><code>fix(next/image):
ensure `images.maximumResponseBody` applies to local images too
(#92920)</code></a></li>
<li><a
href="15341fdf49"><code>Ensure
x-nextjs-data header is only set during resolve (#92752)</code></a></li>
</ul>
</details>
---
[Depfu](https://depfu.com) will automatically keep this PR
conflict-free, as long as you don't add any commits to this branch
yourself. You can also trigger a rebase manually by commenting with
`@depfu rebase`.
<details><summary>All Depfu comment commands</summary>
<blockquote><dl>
<dt>@depfu rebase</dt><dd>Rebases against your default branch and
redoes this update</dd>
<dt>@depfu recreate</dt><dd>Recreates this PR, overwriting any edits
that you've made to it</dd>
<dt>@depfu merge</dt><dd>Merges this PR once your tests are passing and
conflicts are resolved</dd>
<dt>@depfu cancel merge</dt><dd>Cancels automatic merging of this
PR</dd>
<dt>@depfu close</dt><dd>Closes this PR and deletes the branch</dd>
<dt>@depfu reopen</dt><dd>Restores the branch and reopens this PR (if
it's closed)</dd>
<dt>@depfu pause</dt><dd>Ignores all future updates for this dependency
and closes this PR</dd>
<dt>@depfu pause [minor|major]</dt><dd>Ignores all future minor/major
updates for this dependency and closes this PR</dd>
<dt>@depfu resume</dt><dd>Future versions of this dependency will
create PRs again (leaves this PR as is)</dd>
</dl></blockquote>
</details>
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
<!--
👋 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/tailwindlabs/tailwindcss/blob/main/.github/CONTRIBUTING.md
-->
## Summary
<!--
Provide a summary of the issue and the changes you're making. How does
your change solve the problem?
-->
Fix this warning when building apps with TailwindCSS with Node 26+:
```
(node:25346) [DEP0205] DeprecationWarning: `module.register()` is deprecated. Use `module.registerHooks()` instead.
at node:internal/util:129:11
at Module.register (node:internal/modules/esm/loader:969:3)
at file:///Users/antoine/Developer/my-app/node_modules/.pnpm/@tailwindcss+node@4.3.0/node_modules/@tailwindcss/node/dist/index.mjs:18:214
at ...
```
This PR:
- Correctly prefers using `Module#registerHooks` instead of
`Module#register` by checking its availability at runtime
- Adjusts the exports of the hooks’ file by creating a synchronous
version for the new API
- Remove now unused exports from the `package.json`, relying on the
[recommended usage in the
docs](https://nodejs.org/docs/latest/api/module.html#registration-of-asynchronous-customization-hooks)
for the `Module#register` calls
## Test plan
<!--
Explain how you tested your changes. Include the exact commands that you
used to verify the change works and include screenshots/screen
recordings of the update behavior in the browser if applicable.
-->
I'd be happy to ensure this works correctly on my end before merging
this, but it's not as trivial to test locally as a logic fix. Can you
guide me through what I need to do to test this?
I extensively based my change on the docs, following those guides:
- [Fixing imports for
`Module#register`](https://nodejs.org/docs/latest/api/module.html#registration-of-asynchronous-customization-hooks)
- [Using the new `Module#registerHooks`
function](https://nodejs.org/docs/latest/api/module.html#registration-of-synchronous-customization-hooks)
(and other more detailed sections of the same docs page)
---
Fixes#19893Closes#19907
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
Here is everything you need to know about this update. Please take a
good look at what changed and the test results before merging this pull
request.
### What changed?
#### ✳️ @tybys/wasm-util (0.10.1 → 0.10.2) ·
[Repo](https://github.com/toyobayashi/wasm-util)
Sorry, we couldn't find anything useful about this release.
---
[Depfu](https://depfu.com) will automatically keep this PR
conflict-free, as long as you don't add any commits to this branch
yourself. You can also trigger a rebase manually by commenting with
`@depfu rebase`.
<details><summary>All Depfu comment commands</summary>
<blockquote><dl>
<dt>@depfu rebase</dt><dd>Rebases against your default branch and
redoes this update</dd>
<dt>@depfu recreate</dt><dd>Recreates this PR, overwriting any edits
that you've made to it</dd>
<dt>@depfu merge</dt><dd>Merges this PR once your tests are passing and
conflicts are resolved</dd>
<dt>@depfu cancel merge</dt><dd>Cancels automatic merging of this
PR</dd>
<dt>@depfu close</dt><dd>Closes this PR and deletes the branch</dd>
<dt>@depfu reopen</dt><dd>Restores the branch and reopens this PR (if
it's closed)</dd>
<dt>@depfu pause</dt><dd>Ignores all future updates for this dependency
and closes this PR</dd>
<dt>@depfu pause [minor|major]</dt><dd>Ignores all future minor/major
updates for this dependency and closes this PR</dd>
<dt>@depfu resume</dt><dd>Future versions of this dependency will
create PRs again (leaves this PR as is)</dd>
</dl></blockquote>
</details>
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
This PR adds new `tab-*` utilities.
The `tab-*` utilities set the `tab-size` property. They support positive
integer bare values, and arbitrary values:
| Class | CSS |
| -- | -- |
| `tab-2` | `tab-size: 2;` |
| `tab-[12px]` | `tab-size: 12px;` |
This also adds `tab-size` to the property order near the other text
layout properties.
## Test plan
1. Added new `tab-*` utility tests
2. Updated the intellisense snapshot
3. Other existing tests still pass
This PR adds new `zoom-*` utilities.
The `zoom-*` utilities accept bare values that are transformed into `%`
based values, and arbitrary values:
| Class | CSS |
| -- | -- |
| `zoom-50` | `zoom: 50%;` |
| `zoom-[1.1]` | `zoom: 1.1;` |
| `zoom-(--value)` | `zoom: var(--value);` |
This also adds the `zoom` property after the `transform` related
properties. Initially I added it right after `scale`, because logically
they are close together. But then `zoom-*` would sit between `scale` and
other tranfsorm related properties which is a bit weird. Instead, I
moved it after `transform`.
## Test plan
1. Added new zoom based tests
2. All other tests still pass
Here is everything you need to know about this update. Please take a
good look at what changed and the test results before merging this pull
request.
### What changed?
#### ✳️ listhen (1.9.1 → 1.10.0) ·
[Repo](https://github.com/unjs/listhen) ·
[Changelog](https://github.com/unjs/listhen/blob/main/CHANGELOG.md)
<details>
<summary>Release Notes</summary>
<h4><a
href="https://github.com/unjs/listhen/releases/tag/v1.10.0">1.10.0</a></h4>
<blockquote><p dir="auto"><a
href="https://bounce.depfu.com/github.com/unjs/listhen/compare/v1.9.1...v1.10.0">compare
changes</a></p>
<h3 dir="auto">🚀 Enhancements</h3>
<ul dir="auto">
<li>Support <code class="notranslate">extraURLs</code> and detect <a
href="https://portless.sh/">portless</a> from env by default (<a
href="https://bounce.depfu.com/github.com/unjs/listhen/pull/228">#228</a>)</li>
</ul>
<h3 dir="auto">🩹 Fixes</h3>
<ul dir="auto">
<li>Filter IPv4 link-local addresses from network interfaces (<a
href="https://bounce.depfu.com/github.com/unjs/listhen/pull/226">#226</a>)</li>
<li>Do not use fallback port in production (<a
href="https://bounce.depfu.com/github.com/unjs/listhen/pull/223">#223</a>)</li>
</ul>
<h3 dir="auto">❤️ Contributors</h3>
<ul dir="auto">
<li>Kricsleo (<a
href="https://bounce.depfu.com/github.com/kricsleo">@kricsleo</a>)</li>
<li>Tim Krajcar (<a
href="https://bounce.depfu.com/github.com/tkrajcar">@tkrajcar</a>)</li>
<li>Max (<a
href="https://bounce.depfu.com/github.com/onmax">@onmax</a>)</li>
<li>Pooya Parsa (<a
href="https://bounce.depfu.com/github.com/pi0">@pi0</a>)</li>
</ul></blockquote>
<p><em>Does any of this look wrong? <a
href="feedback">Please let us
know.</a></em></p>
</details>
<details>
<summary>Commits</summary>
<p><a
href="60ba9f2ae2...33c98f262d">See
the full diff on Github</a>. The new version differs by 5 commits:</p>
<ul>
<li><a
href="33c98f262d"><code>fix:
do not use fallback port in production (#223)</code></a></li>
<li><a
href="49ef95e7a7"><code>fix:
filter IPv4 link-local addresses from network interfaces
(#226)</code></a></li>
<li><a
href="de2d49ae00"><code>chore(deps):
update all non-major dependencies (#221)</code></a></li>
<li><a
href="f341eb9f76"><code>feat:
support `extraURLs` and detect portless by env by default
(#228)</code></a></li>
<li><a
href="402c52df87"><code>chore:
update deps</code></a></li>
</ul>
</details>
---
[Depfu](https://depfu.com) will automatically keep this PR
conflict-free, as long as you don't add any commits to this branch
yourself. You can also trigger a rebase manually by commenting with
`@depfu rebase`.
<details><summary>All Depfu comment commands</summary>
<blockquote><dl>
<dt>@depfu rebase</dt><dd>Rebases against your default branch and
redoes this update</dd>
<dt>@depfu recreate</dt><dd>Recreates this PR, overwriting any edits
that you've made to it</dd>
<dt>@depfu merge</dt><dd>Merges this PR once your tests are passing and
conflicts are resolved</dd>
<dt>@depfu cancel merge</dt><dd>Cancels automatic merging of this
PR</dd>
<dt>@depfu close</dt><dd>Closes this PR and deletes the branch</dd>
<dt>@depfu reopen</dt><dd>Restores the branch and reopens this PR (if
it's closed)</dd>
<dt>@depfu pause</dt><dd>Ignores all future updates for this dependency
and closes this PR</dd>
<dt>@depfu pause [minor|major]</dt><dd>Ignores all future minor/major
updates for this dependency and closes this PR</dd>
<dt>@depfu resume</dt><dd>Future versions of this dependency will
create PRs again (leaves this PR as is)</dd>
</dl></blockquote>
</details>
[ci-all]
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
This PR makes a small change to the tests. In some cases, where we test
`@utility` functionality we use `tab-*` utilities.
But there is a possibility that we will add this as an actual utility,
so instead let's use a much more generic `example-*` utility. Then we
can read from the `--example` theme value, and use `--resolved-value:
…;` and `--resolved-modifier: …;` values.
It's admittedly more vague, but chances of conflicts go way down. Until
CSS or Tailwind CSS introduces an `example-*` utility...
## Test plan
1. Only tests changed, and all of them still pass
This PR cleans up the noisy test output where some `console.warn`
messages were leaking into the test output.
This also uses the `src/` files instead of the `dist/` files of
`@tailwindcss/node` to get rid of a source map related warning in tests.
It also means that we don't have to rebuild `@tailwindcss/node` when we
make changes.
## Test plan
1. Existing tests pass
2. Output is clean when running tests (`vitest run --reporter=minimal`)
Before:
<img width="1193" height="1376" alt="image"
src="https://github.com/user-attachments/assets/9aceab62-cd99-4391-9734-0ae5c4c3fb48"
/>
After:
<img width="1099" height="294" alt="image"
src="https://github.com/user-attachments/assets/3ada4a0a-8a7a-48a7-9fbd-f3d5dd8700a5"
/>
This PR improves the snapshot tests. At first, this looks like a very
silly PR, but I swear I have legit reasons for these changes:
First, there are a few places where we use `.toMatchInlineSnapshot()`
for tests where we expect that nothing is being generated. This is fine,
but the issue is that this means that if you're not careful, and if we
have a bug, then these snapshots could start producing something.
Updating these snapshots is _too_ easy. So instead, we convert them to
an explicit `.toEqual('')`
Next, I introduced a `pretty` helper function which is used behind the
scenes in the `compileCss(…)`, `run(…)`, and `optimizeCss(…)` test
helpers. It's very silly and simple, it either returns `''` when the
trimmed input is empty, or it will wrap the result in `\n…\n`. The
reason for this is because of how (inline) snapshots works in Vitest. A
snapshot result will be in double quotes, and inside backticks:
```ts
expect(result.css.trim()).toMatchInlineSnapshot(`
"@layer utilities {
.foo {
color: #000;
}
.bar {
color: red;
}
}"
`)
```
This CSS now starts with `"` and ends with `"`. While that is fine, it
starts to get annoying when we have merge conflicts when CSS changes
(this is what triggered me to make this PR because I ran into this a
dozen times already). Because the first and last CSS line also contain a
`"` that you have to keep into account.
Instead we now use `\n` around the output, which makes the tests look
like this:
```ts
expect(pretty(result.css)).toMatchInlineSnapshot(`
"
@layer utilities {
.foo {
color: #000;
}
.bar {
color: red;
}
}
"
`)
```
In a perfect world, I wish we could use something like:
```css
expect(pretty(result.css)).toMatchInlineSnapshot(css`
@layer utilities {
.foo {
color: #000;
}
.bar {
color: red;
}
}
`)
```
That way you are only dealing with CSS, nothing else. Most editors will
show syntax highlighting, and even prettier will do formatting on the
CSS to keep everything consistent.
Unfortunately this also causes issues because when prettier formats
this, then the input/output will not always match. We can solve that by
parsing both sides and compare the ASTs but that would make things
slower.
The biggest issue is that Vitest doesn't support this. You can use
custom serializers
https://vitest.dev/guide/snapshot.html#custom-snapshot-matchers and
domains https://vitest.dev/guide/snapshot.html#custom-snapshot-domain
but this has an annoying issue around escaping values.
When you use `css` it's typically implemented as `const css =
String.raw`, which means that you can write actual CSS instead of JS:
```ts
let input = css`
.\[color:red\] {
color: red;
}
`
```
But vitest would double scape the `\`, which would make the snapshot
test fail:
```ts
let input = css`
.\\[color:red\\] {
color: red;
}
`
```
**Edit**: It is possible with a custom snapshot environment! But this
still introduces some levels of indirection. We are also not really
testing the same thing anymore. Prettier will be formatting the CSS, we
rely on our own CSS parser / printer, which is fine but subtle bugs
could maybe be invisible or maybe it unlocks some hidden bugs, who
knows. Funnily enough, running tests with this new matcher also goes
from `23.60s` to `22.88s` (just 1 run comparison).
<img width="1227" height="897" alt="image"
src="https://github.com/user-attachments/assets/698a0c67-a1fc-46e3-ba5a-60e5873b32df"
/>
Long story short, simple `\n` and `\n` boundaries it is!
## Test plan
- Everything still works as expected.
- There are visual changes in tests, but no actual source code was
updated either so there can not be an accidental diff
This PR fixes an issue where some `calc(…)` expressions become invalid
after we canonicalize them to a different syntax.
Let's say you start with:
`left-[calc(-1*(var(--my-var1)+var(--my-var2)))]`, then the produced AST
for this candidate looks like this:
```js
[
{
"kind": "functional",
"root": "left",
"modifier": null,
"value": {
"kind": "arbitrary",
"dataType": null,
"value": "calc(-1 * (var(--my-var1) + var(--my-var2)))"
},
"variants": [],
"important": false,
"raw": "left-[calc(-1*(var(--my-var1)+var(--my-var2)))]"
}
]
```
Notice that the `+` in between the vars already contain spaces.
And the generated CSS looks like this:
```css
.left-\[calc\(-1\*\(var\(--my-var1\)\+var\(--my-var2\)\)\)\] {
left: calc(-1 * (var(--my-var1) + var(--my-var2)));
}
```
Again, the `+` has spaces aroudn it.
However, we canoncialize this syntax where we remove the `calc(-1 *
<value>)` and move the `-` in front:
`-left-[(var(--my-var1)+var(--my-var2))]`, which should behave the same,
but it did not. The parsed value for this looks like:
```js
[
{
"kind": "functional",
"root": "-left",
"modifier": null,
"value": {
"kind": "arbitrary",
"dataType": null,
"value": "(var(--my-var1)+var(--my-var2))"
},
"variants": [],
"important": false,
"raw": "-left-[(var(--my-var1)+var(--my-var2))]"
}
]
```
Notice that the `+` does not contain spaces around it. That's because we
add them when we parse arbitrary values and when we are in a `calc(…)`
expression. But the `calc(<value> * -1)` is added later, so at this
point, no spaces are added yet.
This also means that the generated CSS currently looks like:
```css
.-left-\[\(var\(--my-var1\)\+var\(--my-var2\)\)\] {
left: calc((var(--my-var1)+var(--my-var2)) * -1);
}
```
Which is invalid.
To solve this, we will make sure to add the whitespace around operators
when we re-insert the `calc(<value> * -1)`. With this fix, the CSS looks
like this:
```css
.-left-\[\(var\(--my-var1\)\+var\(--my-var2\)\)\] {
left: calc((var(--my-var1) + var(--my-var2)) * -1);
}
```
Which is correct again.
---
There are a few other issues that need a bit more work, but are not
required for this fix.
1. Can we get rid of the additional `(` and `)` parens? E.g.:
```diff
- left-[calc(-1*(var(--my-var1)+var(--my-var2)))]
- -left-[(var(--my-var1)+var(--my-var2))]
+ -left-[var(--my-var1)+var(--my-var2)]
```
Right now this means that we should use `calc((<value>) * -1)` instead
of
`calc(<value> * -1)` since `<value>` can be an expression on its own.
This
could lead to unwanted behavior, but this will be a follow up PR _if_
it's
worth it.
2. Why did we even allow this canoncialization from A to B if it's not
the same result?
This last question is a bit more scary, but it has to do with how we
compare results. We create a signature where we normalize a bunch of
values to make sure that we can compare them. As a silly example
`calc(var(--a) + var(--b))` and `calc(var(--b) + var(--a))` will result
in the same value, therefor should have the same signature and should be
swappable.
But what's happening is that the signature of
`left-[calc(-1*(var(--my-var1)+var(--my-var2)))]` and
`-left-[(var(--my-var1)+var(--my-var2))]` result in:
```
/* Signature of: left-[calc(-1*(var(--my-var1)+var(--my-var2)))] */
.x {
left: calc((var(--my-var1)+var(--my-var2))*-1);
}
/* Signature of: -left-[(var(--my-var1)+var(--my-var2))] */
.x {
left: calc((var(--my-var1)+var(--my-var2))*-1);
}
```
This gets rid of whitespace to store less data, but this is obviously
wrong now, so we need to improve the signatures around this. That said,
that will be a follow up PR as well because this requires much more
testing.
But this PR at least fixes the #20010 issue because we will properly
insert the whitespace around the math operators.
Fixes: #20010
## Test plan
1. Added a regression test to make sure that the new canonicalized
syntax results in the correct CSS. Before the fix, the test would fail:
<img width="623" height="106" alt="image"
src="https://github.com/user-attachments/assets/c470ce38-c3fa-4080-92ca-8a3e509f700b"
/>
2. Existing tests still pass
## Summary
Adds utilities for the
[`scrollbar-width`](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/scrollbar-width)
and
[`scrollbar-color`](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/scrollbar-color)
CSS properties.
### `scrollbar-width`
Three static utilities mirroring the spec keywords:
| Class | CSS |
| --- | --- |
| `scrollbar-auto` | `scrollbar-width: auto;` |
| `scrollbar-thin` | `scrollbar-width: thin;` |
| `scrollbar-none` | `scrollbar-width: none;` |
### `scrollbar-color`
The `scrollbar-color` property takes two colors (thumb and track). To
allow them to be set independently, two color utilities are added that
share a pair of CSS variables (`--tw-scrollbar-thumb` and
`--tw-scrollbar-track`), following the same pattern as the gradient stop
utilities (`from-*` / `via-*` / `to-*`):
| Class | CSS |
| --- | --- |
| `scrollbar-thumb-<color>` | `--tw-scrollbar-thumb: <color>;
scrollbar-color: var(--tw-scrollbar-thumb) var(--tw-scrollbar-track);` |
| `scrollbar-track-<color>` | `--tw-scrollbar-track: <color>;
scrollbar-color: var(--tw-scrollbar-thumb) var(--tw-scrollbar-track);` |
Both go through `colorUtility`, so they automatically support the
standard color palette, theme keys (`--scrollbar-thumb-color` /
`--scrollbar-track-color` with `--color` as a fallback), arbitrary
values, and the `/<alpha>` opacity modifier. The variables are
registered with `@property` (initial value `#0000`), matching the
gradient-stop convention so an unset side falls back to transparent.
```html
<div class="scrollbar-thin scrollbar-thumb-red-500 scrollbar-track-zinc-200">…</div>
```
## Test plan
- [x] `pnpm test` (all 4480 tests pass)
- [x] New `scrollbar-width`, `scrollbar-thumb`, and `scrollbar-track`
test cases in `utilities.test.ts` covering palette colors, theme-key
colors, `current` / `inherit` / `transparent`, arbitrary colors,
`/<alpha>` modifiers, and invalid candidates
- [x] `intellisense.test.ts` snapshot updated to include the new class
names
---
_Generated by [Claude
Code](https://claude.ai/code/session_014ajg5maQ4gUHKmqBs5o7vD)_
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
This PR adds a new `--default(…)` option that can be used inside
`--value(…)` or `--modifier(…)` such that functional utilities without
an explicit value/modifier can still be defined as a functional utility.
It would also allow you to use a functional utility without a value and
_with_ a modifier, e.g.: `shadow/50`.
---
This allows us to re-implement functional utilities with a default value
in CSS using `@utility`.
Used the explicit `--default(…)` argument of `--value(…)` for a few
reasons.
1. It's explicit about being a falllback value. If you have `@utility
foo-*`, then you want to be able to use `foo`, but `foo-bad` should not
compile.
2. When `--value(…)` is used in (complex) property values (think a bunch
of `calc(…)` expressions), then we don't need a separate property for
this.
One of the ideas was to have a literal fallback:
```css
@utility tab-* {
tab-size: 4;
tab-size: --value(number);
}
```
For `tab`, this would compile to:
```css
.tab {
tab-size: 4;
}
```
For `tab-123`, this would compile to:
```css
.tab {
tab-size: 4;
tab-size: 123;
}
```
Getting rid of the `tab-size: 4` would be an option, but it's a common
pattern in real CSS for fallback values (think hex background color,
over a more modern `oklch` color).
For `tab-foo`, this would compile to:
```css
.tab {
tab-size: 4;
}
```
Which means that we have an infinite amount classes that would result in
the same class, which is bad. We could special case this one because the
internal `value` would still be `null`, but it might be too confusing.
This syntax without the `--default(…)` also means repetition of certain
properties. Add `--modifier(…)` to the mix, and there is even more
repetition going on.
Another option to consider is that the default fallback is just another
option in the `--value(…, 4)`, but if a default fallback is a keyword,
then there is a chance that this might conflict with actual keywords we
interpret.
Main motivation is to be able to re-implement utilities such as
`shadow/50` purely in CSS. It's also something we support in the JS
based APIs, but not in the CSS based one, so while it's a "new" feature,
it's more like a missing feature right now, and often a reason for
people to use the JS based APIs instead.
For consistency reasons, this is also implemented for `--modifier(…)`
such that you can use a default value there. E.g. when re-implementing
`text-sm` where a default `line-height` is set without the explicit use
of a modifier.
Fixes: https://github.com/tailwindlabs/tailwindcss/issues/16824
## Test plan
1. Added a handful of new tests to make sure this functionality works
2. Existing tests still pass
While working on #19989, I noticed that `--value(…)` inside functional
`@utility` definitions is not required right now.
That means that the following CSS is valid:
```css
@utility foo-* {
color: red;
}
```
But this doesn't really makes sense, because this now accepts a value
and `foo-a`, `foo-b` and `foo-c` would generate the following CSS:
```css
.foo-a {
color: red;
}
.foo-b {
color: red;
}
.foo-c {
color: red;
}
```
The `a`, `b`, and `c` are not doing anything here apart from making your
CSS bigger. So this is very likely an actual bug that you forgot to use
`--value(…)`.
Additionally, if a `--value(…)` was used, but it didn't resolve
anything, then we already properly discared the candidate.
## Test plan
1. Add test to ensure `--value(…)` is required in functional `@utility`
definitions
2. Existing tests pass
This PR fixes a bug where CSS was generated for `start` and `end`. This
was accidentally introduced when we moved the `start-*` and `end-*`
utilities to the legacy utilities. But this meant that we now generate
CSS for `start` and `end` even if no value is provided.
Fixes: #20002
## Test plan
1. Updated the tests to make sure of `--spacing: 0.25rem` which made the
tests fail, and are fixed again by applying the fix.
2. Other tests are still passing
Here is everything you need to know about this update. Please take a
good look at what changed and the test results before merging this pull
request.
### What changed?
#### ✳️ enhanced-resolve (5.20.1 → 5.21.0) ·
[Repo](https://github.com/webpack/enhanced-resolve) ·
[Changelog](https://github.com/webpack/enhanced-resolve/blob/main/CHANGELOG.md)
<details>
<summary>Release Notes</summary>
<h4><a
href="https://github.com/webpack/enhanced-resolve/releases/tag/v5.21.0">5.21.0</a></h4>
<blockquote><h3 dir="auto">Minor Changes</h3>
<ul dir="auto">
<li>
<p dir="auto">Added promise API and support to resolve without <code
class="notranslate">context</code> and <code
class="notranslate">resolveContext</code>. (by <a
href="https://bounce.depfu.com/github.com/alexander-akait">@alexander-akait</a>
in <a
href="https://bounce.depfu.com/github.com/webpack/enhanced-resolve/pull/520">#520</a>)</p>
</li>
<li>
<p dir="auto">Add <code
class="notranslate">extensionAliasForExports</code> option. When <code
class="notranslate">true</code>, <code
class="notranslate">extensionAlias</code> also applies to paths resolved
through the <code class="notranslate">package.json</code> <code
class="notranslate">exports</code> field. Off by default to match
Node.js; opt in for full TypeScript-resolver parity with packages that
ship <code class="notranslate">.ts</code> sources alongside the compiled
<code class="notranslate">.js</code> they declare in <code
class="notranslate">exports</code>. (by <a
href="https://bounce.depfu.com/github.com/alexander-akait">@alexander-akait</a>
in <a
href="https://bounce.depfu.com/github.com/webpack/enhanced-resolve/pull/554">#554</a>)</p>
</li>
</ul>
<h3 dir="auto">Patch Changes</h3>
<ul dir="auto">
<li>
<p dir="auto">Properly handle DOS device paths (<code
class="notranslate">\\?\…</code> and <code
class="notranslate">\\.\…</code>). (by <a
href="https://bounce.depfu.com/github.com/alexander-akait">@alexander-akait</a>
in <a
href="https://bounce.depfu.com/github.com/webpack/enhanced-resolve/pull/551">#551</a>)</p>
</li>
<li>
<p dir="auto">Prevent fallback to parent node_modules when the <code
class="notranslate">exports</code> field target file is not found. (by
<a href="https://bounce.depfu.com/github.com/xiaoxiaojx">@xiaoxiaojx</a>
in <a
href="https://bounce.depfu.com/github.com/webpack/enhanced-resolve/pull/495">#495</a>)</p>
</li>
<li>
<p dir="auto">Imports field spec deviation: non-relative targets (e.g.
<code class="notranslate">"#a": "#b"</code>) no longer re-enter imports
resolution, aligning with the Node.js ESM spec where <code
class="notranslate">PACKAGE_IMPORTS_RESOLVE</code> does not recursively
resolve <code class="notranslate">#</code> specifiers. (by <a
href="https://bounce.depfu.com/github.com/xiaoxiaojx">@xiaoxiaojx</a> in
<a
href="https://bounce.depfu.com/github.com/webpack/enhanced-resolve/pull/503">#503</a>)</p>
<p dir="auto">Previously <code class="notranslate">{ "#a": "#b", "#b":
"./the.js" }</code> would chain-resolve <code
class="notranslate">#a</code> to <code
class="notranslate">./the.js</code>; now it correctly fails, matching
Node.js behavior.</p>
</li>
<li>
<p dir="auto">Move <code class="notranslate">cachedJoin</code>/<code
class="notranslate">cachedDirname</code>/<code
class="notranslate">createCachedBasename</code> caches from module-level
globals to per-Resolver instances. This prevents unbounded memory growth
in long-running processes — when a Resolver is garbage collected, its
join/dirname/basename caches are released with it. (by <a
href="https://bounce.depfu.com/github.com/xiaoxiaojx">@xiaoxiaojx</a> in
<a
href="https://bounce.depfu.com/github.com/webpack/enhanced-resolve/pull/507">#507</a>)</p>
</li>
<li>
<p dir="auto">Fixed when <code class="notranslate">tsconfig: true</code>
is used (default config file) and no <code
class="notranslate">tsconfig.json</code> exists. (by <a
href="https://bounce.depfu.com/github.com/xiaoxiaojx">@xiaoxiaojx</a> in
<a
href="https://bounce.depfu.com/github.com/webpack/enhanced-resolve/pull/502">#502</a>)</p>
</li>
<li>
<p dir="auto">Apply the <code class="notranslate">extensionAlias</code>
option to the <code class="notranslate">imports</code> field to be align
with typescript resolution. (by <a
href="https://bounce.depfu.com/github.com/alexander-akait">@alexander-akait</a>
in <a
href="https://bounce.depfu.com/github.com/webpack/enhanced-resolve/pull/549">#549</a>)</p>
</li>
<li>
<p dir="auto">Improved performance of the many plugins. (by <a
href="https://bounce.depfu.com/github.com/alexander-akait">@alexander-akait</a>
in <a
href="https://bounce.depfu.com/github.com/webpack/enhanced-resolve/pull/529">#529</a>)</p>
</li>
<li>
<p dir="auto">Replace the <code
class="notranslate">Set<string></code>-based resolver stack with a
singly-linked <code class="notranslate">StackEntry</code> class that
exposes a Set-compatible API. (by <a
href="https://bounce.depfu.com/github.com/xiaoxiaojx">@xiaoxiaojx</a> in
<a
href="https://bounce.depfu.com/github.com/webpack/enhanced-resolve/pull/526">#526</a>)</p>
<p dir="auto">Each <code class="notranslate">doResolve</code> call now
prepends a single linked-list node instead of cloning the entire Set,
making stack push O(1) in time and memory. Recursion detection walks the
linked list (O(n)), but because the stack is typically shallow this is
much cheaper than cloning a Set per call.</p>
</li>
<li>
<p dir="auto">Cache the result of <code
class="notranslate">stripJsonComments</code> + <code
class="notranslate">JSON.parse</code> in <code
class="notranslate">readJson</code> using a <code
class="notranslate">WeakMap</code> keyed by the raw file buffer. This
avoids redundant comment-stripping and JSON parsing on every resolve
call that reads tsconfig.json files (via <code
class="notranslate">stripComments: true</code>), improving
TsconfigPathsPlugin warm performance by ~20-35% depending on the depth
of the <code class="notranslate">extends</code> chain. (by <a
href="https://bounce.depfu.com/github.com/xiaoxiaojx">@xiaoxiaojx</a> in
<a
href="https://bounce.depfu.com/github.com/webpack/enhanced-resolve/pull/524">#524</a>)</p>
</li>
<li>
<p dir="auto">Avoid OOM in CachedInputFileSystem when duration is
Infinity. (by <a
href="https://bounce.depfu.com/github.com/alexander-akait">@alexander-akait</a>
in <a
href="https://bounce.depfu.com/github.com/webpack/enhanced-resolve/pull/527">#527</a>)</p>
</li>
</ul></blockquote>
<p><em>Does any of this look wrong? <a
href="feedback">Please
let us know.</a></em></p>
</details>
<details>
<summary>Commits</summary>
<p><a
href="ebc67d3896...35035ca158">See
the full diff on Github</a>. The new version differs by more commits
than we can show here.</p>
</details>
---
[Depfu](https://depfu.com) will automatically keep this PR
conflict-free, as long as you don't add any commits to this branch
yourself. You can also trigger a rebase manually by commenting with
`@depfu rebase`.
<details><summary>All Depfu comment commands</summary>
<blockquote><dl>
<dt>@depfu rebase</dt><dd>Rebases against your default branch and
redoes this update</dd>
<dt>@depfu recreate</dt><dd>Recreates this PR, overwriting any edits
that you've made to it</dd>
<dt>@depfu merge</dt><dd>Merges this PR once your tests are passing and
conflicts are resolved</dd>
<dt>@depfu cancel merge</dt><dd>Cancels automatic merging of this
PR</dd>
<dt>@depfu close</dt><dd>Closes this PR and deletes the branch</dd>
<dt>@depfu reopen</dt><dd>Restores the branch and reopens this PR (if
it's closed)</dd>
<dt>@depfu pause</dt><dd>Ignores all future updates for this dependency
and closes this PR</dd>
<dt>@depfu pause [minor|major]</dt><dd>Ignores all future minor/major
updates for this dependency and closes this PR</dd>
<dt>@depfu resume</dt><dd>Future versions of this dependency will
create PRs again (leaves this PR as is)</dd>
</dl></blockquote>
</details>
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
Small PR that improves the overall quality of the codebase. It's a bit
of everything:
1. Using correct variants for the variants we are testing
2. Use `@reference` instead of `@import` in a test, testing the
`@reference` according to the test name
3. Use `using` for Vitest related mocks. They have a `Symbol.dispose`
implemented, so we can don't have to restore mocks ourselves (right now,
some of them are not cleaned up at all).
4. Updated deprecated `.toThrowError` with `.toThrow` APIs
## Test plan
Everything still passes.
[ci-all]
This PR is an internal change only related to how we visualize source
maps.
As part of this PR
(https://github.com/tailwindlabs/tailwindcss/pull/19996) I added a test
for source maps related to how `@variant` is processed. And while the
result was correct, I had a hard time verifying if this was _actually_
correct. I did the mental mapping of comparing locations from the output
to the input.
<img width="495" height="495" alt="image"
src="https://github.com/user-attachments/assets/2b1c12cd-43ee-461a-b93b-bafe6ce1cce5"
/>
With this PR, I want to make that more visual by actually printing the
input source(s) and output file and highlight the necessary parts:
<img width="1101" height="1085" alt="image"
src="https://github.com/user-attachments/assets/14390026-f211-4cfc-8c6c-3293105f6403"
/>
I didn't want to get too clever here. But printing line numbers also
helps in case we point to different spots on the same line:
<img width="1200" height="981" alt="image"
src="https://github.com/user-attachments/assets/e75f7622-eb51-49ee-928e-fdc8672d2c3f"
/>
And if we point to different files, then we visualize these as well:
<img width="851" height="957" alt="image"
src="https://github.com/user-attachments/assets/77e65801-b46b-4579-8659-d919a8750f60"
/>
If you combine this with snapshot tests, then it's very easy to verify
that locations match up correctly. Each source map location is
highlighted and references a symbol starting at `A`, `B`, etc.
A change to the source maps _can_ result in a big diff, and even this PR
introduces a big diff because of the preflight diffs. But at least you
can see how things line up.
## Test plan
1. All tests still pass
2. Added tests for the source map visualizer that is only used in tests
3. No actual source code was touched
This PR improves and simplifies the `@variant` usage.
When we originally added support for `@variant`, we wanted to keep
things simple, where we could only use a single variant at a time. The
original PR did have a more complex system with all these features
enabled, but we wanted to make sure that we only introduced the
additional complexity when the community felt like it was needed.
But of course we still wanted to make sure that you could do compound
and stacked variants, it just required some additional code.
For compound variants, where you want to use variant `a` and variant
`b`, you could duplicate the rules as siblings:
```css
.foo {
@variant a {
display: flex;
}
@variant b {
display: flex;
}
}
```
But with this PR, you can comma separate each variant to get the same
effect:
```css
.foo {
@variant a, b {
display: flex;
}
}
```
You can think of this as-if we are expanding this syntax into the
aforementioned syntax. In other words, we would do the duplication for
you.
Additionally, you also want to be able to stack variants. For that you
had to nest your `@variant` rules:
```css
.foo {
@variant a {
@variant b {
display: flex;
}
}
}
```
Not the end of the world, but it can get pretty nested if you want to
use multiple variants. Luckily we already have a syntax for this in
normal Tailwind CSS classes: `a🅱️flex`. Which is exactly what we can
use here as well:
```css
.foo {
@variant a:b {
display: flex;
}
}
```
Again, conceptually you can think of this syntax being expanded into the
syntax from above.
Last but not least, we can also combine these:
```css
.foo {
background: black;
@variant a, b:c {
background: red;
@variant d, e:f {
background: blue;
}
}
}
```
This conceptually translates into the much more verbose version today:
```css
.foo {
background: black;
@variant a {
background: red;
@variant d {
background: blue;
}
@variant e {
@variant f {
background: blue;
}
}
}
@variant b {
@variant c {
background: red;
@variant d {
background: blue;
}
@variant e {
@variant f {
background: blue;
}
}
}
}
}
```
The biggest downside is that this could potentially easily balloon your
CSS file size if you're not careful. Because with this, it's pretty easy
to add one more variant that introduces a lot of duplicated CSS.
This feature is completely backwards compatible, you can still nest your
`@variant` calls yourself if you want, and combine them with these
features if you want.
This is also a continuation of #19526 and #19884, but for some reason I
don't have push rights, so I'm creating this new PR instead. I did keep
the original commits of those PRs so these contributors are still
properly marked as contributors.
<img width="808" height="135" alt="image"
src="https://github.com/user-attachments/assets/bee334ab-39d7-4d4d-a48f-afa2253cf17b"
/>
<img width="349" height="75" alt="image"
src="https://github.com/user-attachments/assets/fb68906c-db74-43f7-83e4-918ad3d4a036"
/>
Closes: #19526Closes: #19884
## Test plan
1. Added a bunch of new tests to verify this new behavior
2. Added tests that compare the short (new) version, and the long (old)
version
3. Added a sourcemap related test to ensure that the src and dst
locations are correct
4. Existing tests still pass
---------
Co-authored-by: orteth01 <tortega128@gmail.com>
Co-authored-by: Ray Knight <array.knight+github@gmail.com>
## Summary
Fixes#16948
When defining multiple CSS `@utility foo-*` with different value types
(e.g., one for colors, one for numbers), only the first handler was
tried. If it returned `null` (value didn't match), the compile loop
stopped, preventing subsequent handlers from being attempted.
```css
@utility foo-* {
color: --value(--color-*);
}
@utility foo-* {
font-size: --spacing(--value(number));
}
```
Previously, `foo-red-500` worked but `foo-123` did not (or vice versa
depending on definition order).
The fix distinguishes between CSS `@utility` handlers and JS plugin
`matchUtilities` handlers:
- **CSS `@utility`** (no typed options): `null` means "try the next
handler" - allows multiple definitions with different value types to
coexist
- **JS `matchUtilities`** (with explicit types): `null` means "the value
was invalid for this type, stop" - preserves existing behavior where
typed utilities prevent invalid values from falling through
## Test plan
- Added test: two `@utility foo-*` definitions with different value
types - verifies both `foo-red-500` (color) and `foo-123` (number)
produce correct CSS
- All 4621 existing tests pass (including the `matchUtilities`
type-safety tests)
- `pnpm build && pnpm test` passes
This contribution was developed with AI assistance (Claude Code).
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
Fixes a few minor typos across the codebase (e.g. 'overriden' ->
'overridden', 're-use' -> 'reuse').
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
Prevent the upgrade tool from rewriting CSS properties inside inline
`style` attributes.
This fixes cases like `style="flex-grow: 1"` being changed to
`style="grow: 1"` and adds regression tests.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
This PR improves the canonicalization around arbitrary variants
containing `[&:has(…)]`, by converting them to `has-[…]`.
Essentially when you have a variant, with `&:has(…)`, we will convert
it:
```diff
- [&:has([role=checkbox])]:flex
+ has-[[role=checkbox]]:flex
```
This also means that if the arbitrary selector inside of the `&:has(…)`
can be converted to something that aligns with known variants, then we
will do that as well:
```diff
// `data-*` can be hoisted outside of the arbitrary value
- [&:has([data-slot=description])]:flex
+ has-data-[slot=description]:flex
// `aria-visible="true"` can be entirely replaced by `aria-visible`
- [&:has([aria-visible="true"])]:flex
+ has-aria-visible:flex
```
Noticed this while looking into:
https://github.com/tailwindlabs/tailwindcss-intellisense/issues/1562
## Test plan
1. Added additional tests for this use case
2. Existing tests still pass
This PR improves the canonicalization when dealing with arbitrary
values.
As part of the canonicalization process we compute a signature for a
given utility. This way we can ensure that when we canonicalize a
candidate into a simpler candidate that it's still equivalent if the
signatures match.
One thing we do during signature computation is normalizing dimensions
(value + unit) into the same unit to make comparisons easier.
For example:
```css
.foo { margin-top: 20in; }
.bar { margin-top: 1920px; }
```
Will both get converted to `1920px` and therefore `foo` and `bar` will
have the same signature.
Up until this part, everything is fine. However, this normalization also
leaks when we try to canonicalize arbitrary values. One of the things we
do is try to move the `-` into the arbitrary value:
```diff
- -mt-[20in]
+ mt-[calc(20in_*_-1)]
```
This is obviously not cleaner, but we can perform some canonicalization
of the arbitrary value. As part of that we do constant folding _and_ the
normalization of base units. That means that we would see this:
```diff
- -mt-[20in]
- mt-[calc(20in_*_-1)]
+ mt-[-1920px]
```
But this might be very confusing because it might not make sense where
the `1920px` even came from... the only thing we should have done here
is constant fold that calc expression.
That's what this PR does, it only does the constant folding but without
the unit normalization:
```diff
- -mt-[20in]
- mt-[calc(20in_*_-1)]
+ mt-[-20in]
```
Which is exactly what we want!
Fixes:
https://github.com/tailwindlabs/tailwindcss-intellisense/issues/1573
## Test plan
1. Added a regression test based on the linked issue
2. All other tests still pass
This PR fixes a printing bug during canonicalization where it converts:
```
[&:has(~_*_*:checked)]:text-green-500
```
into:
```
[&:has(~**:checked)]:text-green-500
```
This is because the `_` was marked as insignificant and therefore
removed. This PR fixes that and maintains the whitespace (`_`)
characters when needed.
Additionally, in the comments of the linked issue somebody mentioned
that:
```
w-[calc(100%_-_--spacing(60))]
```
was turned into:
```
w-[calc(100%---spacing(60))]
```
...and while that's still correct and parseable, it's not the prettiest.
This PR will still get rid of the whitespace, but introduce wrapping
parens `(…)` instead, in case readability is not ideal.
In this case, we will turn it into:
```diff
- w-[calc(100%_-_--spacing(60))]
- w-[calc(100%---spacing(60))]
+ w-[calc(100%-(--spacing(60)))]
```
Of course there are some cases where we don't need to introduce `(…)`
unnecessarily:
- `shadow-[inset_0px_1px_--theme(--color-white/15%)]` would not be
turned into `shadow-[inset_0px_1px_(--theme(--color-white/15%))]`
because no readability is gained when it's part of a normal space
separated list
- `m-[--spacing(12.34)]` would not be turned into
`m-[(--spacing(12.34))]` because there is nothing else it can conflict
with
- `m-[calc(--spacing(12.34)*2)]` would not be turned into
`m-[calc((--spacing(12.34))*2)]` because it's the first argument and
doesn't conflict with the `*`
- `m-[min(100%,--spacing(12.34))]` would not be turned into
`m-[min(100%,(--spacing(12.34)))]` because a `,` doesn't cause
readability issues
Fixes:
https://github.com/tailwindlabs/tailwindcss-intellisense/issues/1544
## Test plan
1. Added new tests to ensure the bug is fixed
2. Added new tests to ensure readability is improved (and not degraged)
when whitespace was used to improve readability
This PR updates the CI workflows related to NAPI-RS. So far, we've been
using a custom ghcr.io based image, but these run on Node v18.
With this PR, I created a new project using `napi new`, with GitHub
Actions workflow setup. Then essentially ported the changes from that
new project to this project (as minimal as possible).
The main goal was to be able to bump NAPI-RS related dependencies _and_
get an insiders release out. The images used in these CI jobs were
blockers to get an actual (insiders) release out.
## Test plan
1. CI still passes
2. Added a dry-run on the prepare release workflow to test that we got
through the entire workflow without issues
This PR bumps all the NAPI related dependencies
Closes: #19977Closes: #19976Closes: #19973Closes: #19972Closes: #19971Closes: #19970
## Test plan
1. All tests still pass
[ci-all] to verify on Windows and macOS as well
## Summary
`@tailwindcss/postcss` derives `inputBasePath` from `result.opts.from`:
```ts
let inputFile = result.opts.from ?? ''
let inputBasePath = path.dirname(path.resolve(inputFile))
```
When PostCSS calls the plugin without `from` (some bundlers, including
Turbopack, do this for certain CSS inputs), `inputFile` is `''`,
`path.resolve('')` returns `process.cwd()`, and `path.dirname(...)`
therefore returns the **parent of CWD**. The downstream `compileAst({
base: inputBasePath })` call then asks the resolver to find
`tailwindcss` from one level above the project root, which fails with:
```
Can't resolve 'tailwindcss' in '<parent of CWD>'
```
The plugin already computes `base = opts.base ?? process.cwd()` near the
top. Reusing that as the fallback gives a sensible default (CWD) and
respects an explicit `opts.base` when set.
```diff
-let inputBasePath = path.dirname(path.resolve(inputFile))
+let inputBasePath = inputFile
+ ? path.dirname(path.resolve(inputFile))
+ : base
```
## Test plan
Added a test in `packages/@tailwindcss-postcss/src/index.test.ts` that
processes `@import 'tailwindcss'` via `processor.process(input)` with no
`from` option. Before the fix, this throws `Error: Can't resolve
'tailwindcss' in '<parent of CWD>'`; after the fix, the import resolves
and the processor returns non-empty CSS.
I wasn't able to run the suite locally — `pnpm build` requires `cargo`
for `@tailwindcss/oxide` and I don't have a Rust toolchain set up — so
the test has been written to match existing conventions in
`index.test.ts` (vitest, plain
`postcss([tailwindcss({...})]).process(...)`), and I'm relying on CI to
verify.
---------
Co-authored-by: rebasecase <rebasecase@localhost>
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
This PR bumps dependencies in all the packages, typically just bumping
to the latest patch release.
Closes: #19936Closes: #19917Closes: #19899Closes: #19897Closes: #19845Closes: #19832Closes: #19967Closes: #19968
## Test plan
1. All tests still pass
2. All integration tests still pass
[ci-all] to verify Linux, Windows and macOS
Fixes#19964
CSS files imported via JS that only use `@variant` (no `@apply`,
`theme()`, or utility classes) are silently skipped by the Vite plugin.
The `@variant` directive gets passed through raw to the browser, which
drops it as an unknown at-rule.
**Root cause** — `Features.Variants` is missing from the [feature
detection
bitmask](https://github.com/tailwindlabs/tailwindcss/blob/v4.2.4/packages/%40tailwindcss-vite/src/index.ts#L526):
```ts
// before
Features.AtApply | Features.JsPluginCompat | Features.ThemeFunction | Features.Utilities
// after
Features.AtApply | Features.JsPluginCompat | Features.ThemeFunction | Features.Utilities | Features.Variants
```
**Reproduction** — https://github.com/remorses/tailwind-variant-bug
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
This PR fixes an issue where resolving of certain CSS or JS files
results in the wrong paths. The issue happens if you have a setup where
a relative file path _also_ exists in the parent folder:
```css
/* src/foo.css */
.foo-in-root {}
/* src/theme/a.css */
@import "./foo.css"; /* This resolved to the file above, instead of the file below */
/* src/theme/foo.css */
.foo-in-theme {}
```
This happened because we resolved relative to a `base` folder, but Vite
expects an `importer` instead. The difference is subtle, but they expect
a file. On that file they use `let base = path.dirname(importer)` to get
a base path out themselves.
This in turn means that if you pass in a folder, you get this:
```js
path.dirname('/path/to/my-project') // /path/to
```
If we gave it a proper file, then we get the proper base path
```js
path.dirname('/path/to/my-project/index.css') // /path/to/my-project
```
I'm actually surprised that this didn't cause issues earlier... but it
did result in error since we recently started resolving files using
Vite's `aliasOnly: true` feature such taht Vite aliases work as well.
With this change, we now make sure that:
1. We use a proper `importer` instead of the `base` path
2. We refactor the resolving logic such that we try with `aliasOnly:
true` first, then `aliasOnly: false`
We also still ensure that in the CSS resolver we expect a `.css` file,
and in the JS resolver we _don't_ expect a `.css` file (which can happen
if a `"browser": "./dist/index.css"` field in package.json points to a
CSS file, daisyUI does this for example).
Fixes: #19956
## Test plan
1. Added additional (failing) integration tests to reproduce the linked
issue
2. Existing integration tests pass
While the build still worked, the linked issue resulted in a much bigger
file size because the wrong .css files were included. With this fix, the
number is correct again:
<img width="1234" height="1037" alt="image"
src="https://github.com/user-attachments/assets/fdff803c-0db2-4066-92fa-064c2816b35c"
/>
Since this is touching code related to previous PRs, I wanted to
manually make sure that these still work as expected:
- https://github.com/tailwindlabs/tailwindcss/issues/19950: This one is
about daisyUI and the `.css` file referenced in the package.json's
`"browser"` field: <img width="782" height="1229" alt="image"
src="https://github.com/user-attachments/assets/fb7b9d3b-527b-414b-94b0-2be7e96056f1"
/>
- https://github.com/tailwindlabs/tailwindcss/issues/19946: This one is
about the Vite alias being just a single `@` causing issues with
`@plugin "@tailwindcss/typography";` for example: <img width="1694"
height="1856" alt="image"
src="https://github.com/user-attachments/assets/d1935ecf-e80a-4945-a69a-ec3c5223efab"
/>
[ci-all]
Edit: some edits by @RobinMalfait
---
## Summary
Fix a regression in `@tailwindcss/vite` introduced by `#19803` where JS
plugin resolution could incorrectly resolve a package to its `browser`
CSS entry.
In cases like `daisyui`, Vite can resolve `@plugin "daisyui"` to
`daisyui.css` instead of the package's JS entry, which causes Tailwind
to try to load a CSS file as a JS plugin and fail with:
```txt
Unknown file extension ".css"
```
This change keeps the `aliasOnly: false` behavior from `#19803` so
tsconfig path resolution still works, but adds a JS-entry guard to
`customJsResolver` in `@tailwindcss/vite`. If Vite resolves a plugin
request to a non-JS file like `.css`, the custom resolver now returns
`undefined` so Tailwind's internal fallback resolver can resolve the
package as a JS plugin entry instead.
I also added integration coverage for a package whose `main`/`module`
points to JS while `browser` points to CSS, and verified that `@plugin
"pkg"` still resolves to the JS entry in both build and dev mode.
## Test plan
Added new integration tests in `integrations/vite/resolvers.test.ts`
covering a package with:
- `main` / `module` -> JS
- `browser` -> CSS
- `@plugin "pkg"` -> should resolve to JS, not CSS
Verified with:
```sh
pnpm test:integrations vite/resolvers.test.ts -t "browser points to CSS"
pnpm test:integrations vite/resolvers.test.ts -t "resolves tsconfig paths"
```
These verify that:
- `@plugin` no longer resolves to a CSS browser entry
- the original tsconfig paths fix from `#19803` still works in both
build and dev mode
---
Maintainer edits:
Instead of hardcoding file extensions, first try to resolve aliases and
then fallback to the default resolving system we had before. We still
check for a `.css` extension, even in the JS resolver because some
dependencies (like `daisyUI`) put the CSS file there instead of in an
`exports.style`. If we detect that, we still fallback to the default
resolving logic.
This should be compatible with the original issue we were trying to fix
where we wanted to make Vite aliases work.
Fixes: #19950
[ci-all]
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
This PR fixes an issue when using `@tailwindcss/vite` and you're trying
to resolve paths. In the latest 4.2.3 release, we added support for
following the vite `aliases` option.
However, some people run into issues because if you just use `@` as an
alias then using `@tailwindcss/typography` wouldn't resolve because it's
a package, and not something local.
With this PR we fix that by making sure that Vite's resolver can
actually resolve to an absolute path. If not, then we fallback to the
resolving that happens in `@tailwindcss/node`.
Fixes: #19946
## Test plan
1. Added an integration test that reproduces this issue, and is now
solved
2. Tested it on a reproduction provided in the corresponding issue
Before:
<img width="1694" height="1856" alt="image"
src="https://github.com/user-attachments/assets/c50f7104-78b3-476d-9e60-0c83e0976a5c"
/>
After:
<img width="1694" height="1856" alt="image"
src="https://github.com/user-attachments/assets/44ea0e3b-f60f-479f-a4a1-203a6230475b"
/>
<!--
👋 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/tailwindlabs/tailwindcss/blob/main/.github/CONTRIBUTING.md
-->
## Summary
<!--
Provide a summary of the issue and the changes you're making. How does
your change solve the problem?
-->
Removed a duplicated optimize: { minify: false } example from
@tailwindcss/postcss README (doc-only, one file).
## Test plan
<!--
Explain how you tested your changes. Include the exact commands that you
used to verify the change works and include screenshots/screen
recordings of the update behavior in the browser if applicable.
-->
Check the duplicate block is removed, the earlier optimize example still
exists, and only packages/@tailwindcss-postcss/README.md changed.
References https://github.com/tailwindlabs/tailwindcss/pull/19391.
References https://github.com/tailwindlabs/tailwindcss/pull/16274.
Right now, when using the standalone build of the TailwindCSS CLI, you
cannot use a custom `NODE_PATH`, but you can when using it via Node.js
directly.
A custom NODE_PATH allows you to resolve imports from multiple
locations. For example, in [Phoenix
LiveView](https://github.com/phoenixframework/phoenix_live_view/), we
have a feature where you can write scripts in templates that we extract
at compile time to a custom folder and users can import those in their
application bundle by saying
```javascript
import { hooks as colocatedHooks } from "phoenix-colocated/my_app"
```
where the "phoenix-colocated" folder lives in a different location than
the usual `node_modules` folder. This works fine with the default
esbuild setup, as it respects `NODE_PATH`, so we can pass it a custom
location.
We want to also support colocating CSS in templates soon, but the same
approach doesn't work with the standalone Tailwind CLI we ship with
default Phoenix projects. It works when running Tailwind through
Node.js, but we don't want to tell users they need to install it, just
to use the feature.
This patch changes the lookup logic for the standalone CLI to also
account for `NODE_PATH`. Note that you can pass multiple paths, that are
split according the the OS PATH separator.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
<!--
👋 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/tailwindlabs/tailwindcss/blob/main/.github/CONTRIBUTING.md
-->
## Summary
Fix a typo in the @tailwindcss/postcss README by changing Lighting CSS
to Lightning CSS in the optimize option documentation.
<!--
Provide a summary of the issue and the changes you're making. How does
your change solve the problem?
-->
## Test plan
Verified the README now says Lightning CSS and that the diff is
docs-only.
<!--
Explain how you tested your changes. Include the exact commands that you
used to verify the change works and include screenshots/screen
recordings of the update behavior in the browser if applicable.
-->
Here is everything you need to know about this update. Please take a
good look at what changed and the test results before merging this pull
request.
### What changed?
#### ✳️ @vitejs/plugin-react (5.1.3 → 5.2.0) ·
[Repo](https://github.com/vitejs/vite-plugin-react) ·
[Changelog](https://github.com/vitejs/vite-plugin-react/blob/main/packages/plugin-react/CHANGELOG.md)
<details>
<summary>Release Notes</summary>
<h4>5.1.4 (from changelog)</h4>
<blockquote><h3 dir="auto">Fix <code
class="notranslate">canSkipBabel</code> not accounting for <code
class="notranslate">babel.overrides</code> (<a
href="https://bounce.depfu.com/github.com/vitejs/vite-plugin-react/pull/1098">#1098</a>)</h3>
<p dir="auto">When configuring <code
class="notranslate">babel.overrides</code> without top-level plugins or
presets, Babel was incorrectly skipped. The <code
class="notranslate">canSkipBabel</code> function now checks for <code
class="notranslate">overrides.length</code> to ensure override
configurations are processed.</p></blockquote>
<p><em>Does any of this look wrong? <a
href="feedback">Please
let us know.</a></em></p>
</details>
---
[Depfu](https://depfu.com) will automatically keep this PR
conflict-free, as long as you don't add any commits to this branch
yourself. You can also trigger a rebase manually by commenting with
`@depfu rebase`.
<details><summary>All Depfu comment commands</summary>
<blockquote><dl>
<dt>@depfu rebase</dt><dd>Rebases against your default branch and
redoes this update</dd>
<dt>@depfu recreate</dt><dd>Recreates this PR, overwriting any edits
that you've made to it</dd>
<dt>@depfu merge</dt><dd>Merges this PR once your tests are passing and
conflicts are resolved</dd>
<dt>@depfu cancel merge</dt><dd>Cancels automatic merging of this
PR</dd>
<dt>@depfu close</dt><dd>Closes this PR and deletes the branch</dd>
<dt>@depfu reopen</dt><dd>Restores the branch and reopens this PR (if
it's closed)</dd>
<dt>@depfu pause</dt><dd>Ignores all future updates for this dependency
and closes this PR</dd>
<dt>@depfu pause [minor|major]</dt><dd>Ignores all future minor/major
updates for this dependency and closes this PR</dd>
<dt>@depfu resume</dt><dd>Future versions of this dependency will
create PRs again (leaves this PR as is)</dd>
</dl></blockquote>
</details>
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
This PR bumps Next.js and drops ESLint.
We only had ESLint installed because it came with `next lint`. We don't
actively use ESLint, it was just used in the playgrounds where we test
things out. Dropping this reduces the amount of dependencies we have to
deal with.
Closes: #19867Closes: #19852
# Test plan
Tested both the `nextjs` and `v3` playgrounds after bumping the Next.js
dependency and getting rid of ESLint, and they still work as expected.
## Summary
This specializes the `.jsonl` and `.ndjson` file extensions so they're
preprocessed like JSON instead of by the standard scanner. This prevents
them from creating thousands of sub machines and reduces scanning time
(see #17125 where this was done for `.json` files).
It seems reasonable to handle new-line delimited JSON files as well
otherwise scanning these files can take quite a long time.
It's quite unlikely that these will contain classes so, alternatively,
these *could* go in the binary extensions list so they get ignored
entirely.
## Test plan
I ran manual tests inside the `oxide` crate against some large-ish JSONL
files (5MB–15MB). These changes bring down scanning time from 2s–3s on
my M3 Max (via `cargo test --release …`) to less than 20ms.
I also ran tests through a full CLI build pipeline on a low-spec linux
box. This change brought scanning time down from ~90s to ~300ms for a
single ~15MB file.
This PR adds a few more canonicalizations for some cases I noticed on
our templates.
When dealing with arbitrary values, and the utility is a "negative"
utility, then we will try to put the `-` inside of the arbitrary value:
```diff
- -left-[9rem]
+ left-[-9rem]
```
The idea is that the arbitrary value is already an escape hatch for when
a value is not available by default. The `-` in front uses an implicit
`calc(<expression> * -1)` which might be confusion if you have an value
like this already.
This also can allow for some further optimizations. For example
```diff
- -mt-[492px]
↓↓↓↓↓↓↓ Into a simpler arbitrary value
+ mt-[-492px]
↓↓↓↓↓↓↓ Into a bare value
+ mt-123
```
This PR also improve the constant folding of calc expressions a bit more
such that nested calc expressions with 2 constants and an unknown can be
folded. Bit of a mouthful, but it allows us to handle this:
```diff
- mt-[calc(-1*calc(-1*var(--foo)))]
↓↓↓↓↓↓↓ The -1 * -1 becomes a no-op
+ mt-[var(--foo)]
↓↓↓↓↓↓↓ Into the shorthand for CSS variables
+ mt-(--foo)
```
Now that we can handle moving the `-` into the arbitrary value, there
are also cases where we can get the `-` _out_ of the arbitrary value:
```diff
- mt-[calc(-1*var(--foo))]
↓↓↓↓↓↓↓ Simplify calc, move `-` to the front
+ -mt-[var(--foo)]
↓↓↓↓↓↓↓ Into the shorthand for CSS variables
+ -mt-(--foo)
```
Another missing piece that this PR adds is the concept of canonicalizing
or normalizing calc expressions. This is a separate step used when
calculating the signature for each utility. This allows us to normalize
`calc(-1*var(--foo))` and `calc(var(--foo)*-1)`. Without this they would
not be considered the same, but not it will.
It's only used when comparing values, it won't unify the actual
arbitrary values with this logic (at least for now).
With the additional constant folding logic and the canonicalization when
comparing signatures it unlocks the necessary power to perform the above
transformations.
## Test plan
1. Existing tests still pass
2. Added additional tests for the constant folding logic
3. Added tests for the canonicalization of calc expressions
4. Added new tests where we move the `-` inside the value, or move the
`-` outside of the arbitrary value.
This are getting a little bit out of hand here, so this is an initial
refactor.
## Test plan
1. All tests are still there
2. All tests are still passing
This PR adds more canonicalization rules for deprecated utilities.
| Before | After |
| --- | --- |
| `overflow-ellipsis` | `text-ellipsis` |
| `start-full` | `inset-s-full` |
| `-start-full` | `-inset-s-full` |
| `start-auto` | `inset-s-auto` |
| `start-px` | `inset-s-px` |
| `-start-px` | `-inset-s-px` |
| `start-8` | `inset-s-8` |
| `-start-8` | `-inset-s-8` |
| `start-123` | `inset-s-123` |
| `-start-123` | `-inset-s-123` |
| `end-full` | `inset-e-full` |
| `-end-full` | `-inset-e-full` |
| `end-auto` | `inset-e-auto` |
| `end-px` | `inset-e-px` |
| `-end-px` | `-inset-e-px` |
| `end-8` | `inset-e-8` |
| `-end-8` | `-inset-e-8` |
| `end-123` | `inset-e-123` |
| `-end-123` | `-inset-e-123` |
In a few cases we already had canonicalization rules, for example
`start-8` where `8` is one of the default suggested spacing scale
values. But this now adds support for positive and negative values that
exceed the default suggested spacing scale as well as some keywords.
## Test plan
1. Existing tests pass
2. Added new tests to ensure these canonicalizations work
This PR is an attempt to make the upgrade tooling more stable.
### TL;DR
1. When migrating from Tailwind CSS v3 → Tailwind CSS v4, only migrate
files listed in the `config.content` instead of relying on v4's auto
content detection feature
2. Skip writing files that have not been changed
3. Write changed files in a safe way: first write to a temporary file,
then rename the file atomically
4. Never migrate files that are git ignored, even if they are listed in
the `config.content` file
5. Always ignore `.env` and `.env.*` files when scanning for files. Most
people will have this in their `.gitignore` file, but if not, then this
is a fallback mechanism.
---
Looking at the #18972 issue, it looks like some people are running into
weird situations where some of the contents is just gone.
I have never been able to reproduce this on my own devices and in my own
projects unfortunately. But there is definitely _something_ happening
that's not right that people are running into.
Therefore, this PR is an attempt to fix what I think _might_ be wrong,
but I'm not 100% sure if these fixes are enough, or if something else is
still happening here.
This builds on top of the #19779 PR which has some small fixes, but is
incomplete to make this work.
### What's happening
Looking at some of the comments, it looks like a few things are
happening such as:
1. The upgrade tool is emptying out my files — it looks like these are
only happening if you ctrl+c while the process is taking a while. It
could be that a lot of files are being checked and therefore the tooling
looks like its stuck.
6. The upgrade tool is looking at files it shouldn't look at — in
Tailwind CSS v4 we have this concept of the auto-content detection. This
means that we will look at any plain text file that is not git ignored.
### Fixes
#### Emptying out files
The files being emptied looks like it's because how `fs.writeFile`
behaves by default. It opens the file handle with the `w` flag, which
will first truncate the file before writing the new contents. This is
not a single atomic operation, so a killed process in the middle will
cause invalid state.
When we migrate your template files, everything is happening in promises
to migrate things at the same time. When a lot of files are being
scanned, truncating might have happened already before we write the new
content. Since we migrate a bunch of files in parallel, a ctrl+c could
cause data loss in multiple files.
To mitigate this, I switched to an alternative way of writing files.
1. First, we do some quick checks where if the contents didn't change we
just bail out immediately. Files that don't include Tailwind CSS classes
won't change, and therefore we don't need to override these files with
the same contents.
2. When the migrated contents is empty, we bail out as well. I'm 100%
sure that this is not the spot where the "emptying out" happens, I still
believe it happens in the `writeFile` itself, but added it just in case.
7. Next, I introduced a safe write, where we first write to a temporary
file in the same folder. We could write it to `/tmp`, but then we can't
guarantee that we are on the same file system.
If we ctrl+c at this stage, then the worst case scenario is that you
have additional temporary files in your project, but your original files
are still there.
Once that file was written, we will use the atomic `fs.rename`. This
should be atomic as long as we are on the same file system, so either
the rename didn't happen yet, or it completed.
I added an integration test for this, but I had to change the
`writeFile` implementation slightly. In the test, we will truncate the
file first, after that we will write the new contents. This is so that
we have enough time to kill the current process and allows us to verify
that we didn't clear out the file. Again, this is a hacky way of testing
this, just because I can't reproduce this issue myself, let alone
reproduce it reliable in a CI environment.
Note: we are also using `realpath` to make sure that we are updating the
real file. Otherwise, if we were dealing with a symlinked file, we would
override the symlink with a "hard" copy instead.
#### Touching files that should not be touched
During the migration, we rely on the Tailwind CSS v4 auto detection
logic which means that it will scan any plain text file that is not git
ignored. Therefore changes to php files could happen because in theory
they could contain Tailwind CSS classes.
To solve this, when migrating from Tailwind CSS v3 to Tailwind CSS v4,
we will _only_ take the sources into account that were listed in the
`config.content` array. Since this was a requirement in Tailwind CSS v3,
it should be safe to rely on this array.
Additionally, this will make sure that we are dealing with way fewer
files to migrate as well.
On top of that, files that match the patterns in the content array that
are git ignored will also be skipped. This is to prevent that we mutate
files in `node_modules` for example.
In one of the comments I read that `.env` files were emptied out. In
most cases people will have these files gitignored but I explicitly
added `.env` and `.env.*` as files to never ever touch by default when
scanning.
Last but not least, this also updates the output a little bit of the
upgrade tool in case we skip content files (because of git ignore) and
if we changed a file.
<img width="1122" height="1376" alt="image"
src="https://github.com/user-attachments/assets/318fdbbf-e319-4c7e-9648-ee9283842624"
/>
- "Git ignored folder, skipping: `./node_modules`": this is because the
content array looks like this while the `node_modules` are being
ignored:
<img width="1090" height="398" alt="image"
src="https://github.com/user-attachments/assets/7d694720-5671-47ec-bb2e-f24c5f2c4248"
/>
- "Migrated
`./resources/views/vendor/filament-panels/components/logo.blade.php`":
this is because **I** made a change to showcase this feature.
Fixes: #18972Closes: #19779
### Test plan
1. Existing tests still pass
1. Added a dedicated integration test to ensure that we only take
`config.content` into account when migrating from Tailwind CSS v3 to
Tailwind CSS v4 projects.
1. Added a dedicated integration test to make sure that files listed in
`config.content` that are also git ignored, will still be skipped.
1. Added a dedicated integration test to ensure that when `writeFile` is
cancelled mid-write that our old files are still present.
1. Added a dedicated integration test to ensure that we ignore `.env`
and `.env.*` files even if you didn't git ignore them.
[ci-all] To verify on Windows
---------
Co-authored-by: Sami <sychocouldy@gmail.com>
This PR fixes an issue where `placeholder-*` utilities were reading
values from `--background-color` instead of `--placeholder-color`. In
Tailwind CSS v3, we read from `placeholderColor` which is why we should
use `--placeholder-color` here as well.
f38be227df/src/corePlugins.js (L2317)
That said, this is technically a breaking change in case somebody relies
on `--background-color` for `placeholder` values. But since this is text
related, and most people will rely on the default `--color` values
instead, I think it's safe to change this as-is.
In the unlikely event that somebody _does_ rely on this, then we have 2
options:
1. Guide them to make use of `--placeholder-color` instead (preferred
solution)
2. Re-add `--background-color` after the `--placeholder-color` (band-aid
solution, but might be worth it who knows)
Fixes: #19838
## Test plan
1. Existing tests still pass
2. Verified in the Tailwind CSS v3 codebase that we did read from
`placeholderColor` which in turn reads from `color` by default. Which is
equivalent to `--placeholder-color` and `--color` in Tailwind CSS v4.
This PR adds more declaration expansions such that we can collapse more
utilities.
While testing #19837 I noticed that in my tests some utilities weren't
canonicalized correctly. As part of that PR, we check for
`parsedCandidate.value === null`, which means that a functional utility
without a value is skipped. We do have utilities like that such as
`border` (which is equivalent to `border-1`). But while testing, I
noticed that `border-x border-y` should collapse to `border` but they
didn't. This PR fixes that.
By expanding these properties to their long-form physical properties
(instead of the shorter logical properties) we make the signatures of
utilities a bit bigger, but also more correct such that we can collapse
the physical form into logical utilities.
To make this more concrete, this PR allows for the following
canonicalizations now:
| Input | Output |
| --- | --- |
| `border-t-123 border-r-123 border-b-123 border-l-123` | `border-123` |
| `border-t-1 border-r-1 border-b-1 border-l-1` | `border` |
| `border-t-123 border-b-123` | `border-y-123` |
| `border-l-123 border-r-123` | `border-x-123` |
| `border-t-red-500 border-r-red-500 border-b-red-500 border-l-red-500`
| `border-red-500` |
| `border-t-red-500 border-b-red-500` | `border-y-red-500` |
| `border-l-red-500 border-r-red-500` | `border-x-red-500` |
| `scroll-mt-123 scroll-mr-123 scroll-mb-123 scroll-ml-123` |
`scroll-m-123` |
| `scroll-mt-123 scroll-mb-123` | `scroll-my-123` |
| `scroll-ml-123 scroll-mr-123` | `scroll-mx-123` |
| `scroll-pt-123 scroll-pr-123 scroll-pb-123 scroll-pl-123` |
`scroll-p-123` |
| `scroll-pt-123 scroll-pb-123` | `scroll-py-123` |
| `scroll-pl-123 scroll-pr-123` | `scroll-px-123` |
| `overflow-x-hidden overflow-y-hidden` | `overflow-hidden` |
| `overscroll-x-contain overscroll-y-contain` | `overscroll-contain` |
## Test plan
1. Existing tests pass
2. Added a few more tests to verify that these canonicalizations work
The guard on `dynamicUtilities` restricted root-swapping to named
values, so arbitrary values like `px-[1.2rem] py-[1.2rem]` were never
collapsed into `p-[1.2rem]`.
This is what caused #19835 — in `--stream` mode, the collapse only
happened if an earlier line caused the shorthand to be registered in
`STATIC_UTILITIES_KEY` as a side effect, making the output
non-deterministic. The underlying issue is that arbitrary value collapse
wasn't supported at all.
The fix relaxes the guard from `parsedCandidate.value?.kind !== 'named'`
to `parsedCandidate.value === null`. `cloneCandidate` and
`printCandidate` already handle arbitrary values, so the root-swapping
machinery works without other changes.
The iteration in `dynamicUtilities` is over
`designSystem.utilities.keys('functional')` — a fixed set of roots, not
input-proportional — so the performance cost of including arbitrary
values should be negligible.
Fixes#19835.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
<!--
👋 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/tailwindlabs/tailwindcss/blob/main/.github/CONTRIBUTING.md
-->
## Summary
<!--
Provide a summary of the issue and the changes you're making. How does
your change solve the problem?
-->
`@tailwindcss/webpack` currently uses `this.resourcePath` as the cache
key, which ignores the resource query. When the same CSS file is
imported multiple times with different `resourceQuery` values, all of
those imports share a single `CacheEntry`. That means the utilities
discovered for one entry can leak into the CSS output for another entry.
This PR changes the cache key to use `this.resource` (path + query)
instead, while still using `this.resourcePath` for all filesystem work.
## Test plan
<!--
Explain how you tested your changes. Include the exact commands that you
used to verify the change works and include screenshots/screen
recordings of the update behavior in the browser if applicable.
-->
- `pnpm test:integrations -- webpack/loader.test.ts`
- Confirms all existing webpack loader integration tests pass.
- Confirms the new `@tailwindcss/webpack loader isolates cache by
resource including query` test passes, verifying that two entries
importing the same CSS file with different queries produce isolated
outputs (`dist/a.css` only contains `only-a` / `--color-red-500`, and
`dist/b.css` only contains `only-b` / `--color-blue-500`).
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
Change `aliasOnly` from `true` to `false` when calling Vite's resolver
so that the full resolution pipeline runs, including the oxc resolver
responsible for tsconfig path resolution.
When `aliasOnly` was `true`, only the @rollup/plugin-alias plugin ran,
which meant `resolve.tsconfigPaths: true` had no effect on CSS `@import`
or JS `@plugin` resolution in `@tailwindcss/vite`.
Closes#19802.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
This PR fixes an issue where the compiler can crash if it encounters an
invalid codepoint.
When we extract potential candidates from files, it could be that we
encounter values that look like a class or a CSS variable, if it turns
out that it's an invalid CSS variable we can ignore it.
The problem is that sometimes there are escaped values in there that
result in invalid code points crashing the compiler.
This PR fixes that by gracefully handling that and making sure that
invalid code points are replaced by `\uFFFD` as per the spec.
The bug report
(https://github.com/tailwindlabs/tailwindcss/issues/19786) has a clean
example where a piece of text looks like a CSS variable, but contains
invalid code points.
```
--Coding-Projects-CharacterMapper-Master-Workspace\d8819554-4725-4235-9d22-2d0ed572e924
```
Luckily we can fix this today by ignoring the file paths that contain
these strings using `@source not "…";`, but the better way is to
actually fix this.
To solve this, instead of blindly passing numbers to
`String.fromCodePoint`, we will first validate whether it's a valid
codepoint:
1. `0x0000` — `0x10FFFF` (inclusive) is the range of valid code points.
See: https://infra.spec.whatwg.org/#code-point
2. `0xD800` — `0xDBFF` (inclusive) are leading surrogates. See:
https://infra.spec.whatwg.org/#leading-surrogate
3. `0xDC00` — `0xDFFF` (inclusive) are trailing surrogates. See:
https://infra.spec.whatwg.org/#trailing-surrogate
In the code we use the `0xD800` — `0xDFFF` range because the ranges
overlap.
There are various references in the spec to replace surrogates (and
invalid codepoints) with `\uFFFD`. Here is one of them:
https://drafts.csswg.org/css-syntax-3/#consume-escaped-code-point
Fixes: https://github.com/tailwindlabs/tailwindcss/issues/19786Fixes: #19801 (this issue talks about a similar invalid code point
issue)
## Test plan
1. Added a regression test where the above string was used as a CSS
variable
2. Added a regression test for the unescape functionality to make sure
that invalid code points and surrogates are replaced by the `\uFFFD`
replacement character.
[ci-all] Just to verify on Windows as well
This PR adds support for canonicalizations for `tracking-*` utilities.
This one is a bit of a funny one, if you take a look at the linked
issue, there is a beautiful table:
| Utility Name | Value | Arbitrary Value | Throws Suggestion |
| - | -: | - | - |
| tracking-tighter | -0.05em | tracking-[-0.05em] | ✗ |
| tracking-tight | -0.025em | tracking-[-0.025em] | ✗ |
| tracking-normal | 0em | tracking-[0em] | ✗ |
| tracking-wide | 0.025em | tracking-[0.025em] | ✗ |
| tracking-wider | 0.05em | tracking-[0.05em] | ✗ |
| tracking-widest | 0.1em | tracking-[0.1em] | ✓ |
It doesn't really make sense to _why_ only the `tracking-widest` one is
properly suggested here. Until you look a little bit closer.
Turns out that `-tracking-tighter` is equivalent to `tracking-wider`,
`-tracking-tight` is equivalent to `tracking-wide` and so on.
The way the canonicalization works internally is by generating a
signature for a given utility class. If two utilities have the exact
same signature, we can consider them the same. In this case
`tracking-widest` and `tracking-[0.1em]` have the same signature.
One of the rules we have internally is that if we find more than one
replacement utility then we don't really know what to do, so we bail.
Because if you get `foo` or `bar`, which one do you pick?
If we refer to this above table again, the moment we want to
canonicalize the `tracking-[-0.05em]` we get two suggestions:
`tracking-tighter` and `-tracking-wider`, since we don't know what to
do, we bail and we don't suggest anything.
So the reason that `tracking-widest` _was_ suggested is just because we
don't have a `-tracking-tightest`.
How do we fix this? Well, since we have `tracking-*` and `-tracking-*`
utilities, I wanted to deprecate the `-tracking-*` ones for named
utilities (where the values come from your theme) because that doesn't
really make sense.
However, we have this exact pattern documented here:
https://tailwindcss.com/docs/letter-spacing#using-negative-values Which
means that I can't just deprecate those utilities.
<img width="723" height="511" alt="image"
src="https://github.com/user-attachments/assets/164b659b-abe9-4f6e-a176-701dd7ea505a"
/>
Instead, I added a different rule which says that if you get multiple
possible replacements, then we prefer the "positive" one, the one
without the `-`. Also added some additional checks to make sure that if
you get `foo`, `-bar`, `baz`, that we also bail because we know that we
should prefer `foo` or `baz` over `-bar`, but we don't know if we should
pick `foo` or `baz`...
This additional rule does solve the original issue, and we already
prefer possible values over negative values in other places (related to
bare values).
Fixes:
https://github.com/tailwindlabs/tailwindcss-intellisense/issues/1558
## Test plan
1. Existing tests pass
2. Added regression tests to make sure that the table from above _does_
get canonicalized correctly into the expected values.
2026-03-19 19:53:16 +01:00
225 changed files with 38213 additions and 20254 deletions
- Add `@tailwindcss/turbopack` package to run Tailwind CSS with Next.js ([20367](https://github.com/tailwindlabs/tailwindcss/pull/20367))
### Fixed
- Ensure watch mode detects changes to symlinked `@source` files whose real paths aren't otherwise scanned ([#20356](https://github.com/tailwindlabs/tailwindcss/pull/20356))
- Ensure custom variants using `@scope` wrap the generated utilities instead of nesting inside them ([#20369](https://github.com/tailwindlabs/tailwindcss/pull/20369))
- Fix flattening of `@scope` at-rules ([#20369](https://github.com/tailwindlabs/tailwindcss/pull/20369))
- Fix standalone declarations in `@scope`, wrap them in `:where(:scope)` ([#20369](https://github.com/tailwindlabs/tailwindcss/pull/20369))
- Always emit a space for empty fallback values in CSS variables (e.g. `var(--tw-blur,)` → `var(--tw-blur, )`) ([#20373](https://github.com/tailwindlabs/tailwindcss/pull/20373))
- Canonicalization: convert arbitrary breakpoint and container query variants to named equivalents (e.g. `max-[64rem]` → `max-lg`) ([#20380](https://github.com/tailwindlabs/tailwindcss/pull/20380))
- Prevent `@tailwindcss/vite` from crashing on every edit under Vite's experimental `bundledDev` mode ([#20379](https://github.com/tailwindlabs/tailwindcss/pull/20379))
- Ensure `@tailwindcss/oxide` falls back to WASM on platforms without native bindings ([#20383](https://github.com/tailwindlabs/tailwindcss/pull/20383))
- Detect classes in Ruby percent literals using angle brackets or custom delimiters (e.g. `%w<flex>`, `%w|flex|`), including in Slim and Haml templates ([#20387](https://github.com/tailwindlabs/tailwindcss/pull/20387))
- Preserve whitespace in `--default(…)` values in custom functional utilities (e.g. `--default(box alphabetic)` no longer becomes `boxalphabetic`) ([#20392](https://github.com/tailwindlabs/tailwindcss/pull/20392))
- Don't scan gitignored directories (e.g. `node_modules` and `.git`) when the project uses a safelist-style `.gitignore` (e.g. `/*` followed by `!/…` negations) ([#20397](https://github.com/tailwindlabs/tailwindcss/pull/20397))
- Ensure root `theme('…')` namespace lookups in JavaScript plugins and config files return the full namespace object instead of the value of its `DEFAULT` key ([#20399](https://github.com/tailwindlabs/tailwindcss/pull/20399))
- Skip ignored directories entirely when computing watch globs (`scanner.globs`), instead of walking their full contents on every rebuild ([#20408](https://github.com/tailwindlabs/tailwindcss/pull/20408))
- Oxide: drop invalid UTF-8 candidates ([#20389](https://github.com/tailwindlabs/tailwindcss/pull/20389))
- `@tailwindcss/vite` no longer forces a full page reload for external files (e.g.: `.php` files) ([#20414](https://github.com/tailwindlabs/tailwindcss/issues/20414))
- Canonicalization: don't merge utilities that reference different theme variables set to CSS-wide keywords like `unset` ([#20417](https://github.com/tailwindlabs/tailwindcss/pull/20417))
- Don't generate utilities when a modifier is used that would otherwise be silently ignored (e.g. `rounded-sm/[5]`, `shadow-sm/foo`, `stroke-2/50`) ([#20419](https://github.com/tailwindlabs/tailwindcss/pull/20419))
- Only normalize top-level `and`, `or`, and `not` keywords in `supports-[…]` variants (e.g. `selector(a: not (.foo))` → `selector(a:not(.foo))`) ([#20420](https://github.com/tailwindlabs/tailwindcss/pull/20420))
- Don't warn about Angular's `::ng-deep` and `:host-context()` when optimizing CSS ([#20434](https://github.com/tailwindlabs/tailwindcss/pull/20434))
- Don't generate CSS for candidates containing an empty additional modifier (e.g. `bg-red-500/50/` and `group-hover/foo//bar:flex`) ([#20466](https://github.com/tailwindlabs/tailwindcss/pull/20466))
- Sort `min-*`, `max-*`, and container query variants with decimal values numerically (e.g. `min-[40.25rem]` before `min-[40.5rem]`) ([#20512](https://github.com/tailwindlabs/tailwindcss/pull/20512))
- Ensure CSS comments ending with `\*/` are closed correctly instead of swallowing the CSS that follows (e.g. `/* C:\temp\*/`) ([#20508](https://github.com/tailwindlabs/tailwindcss/pull/20508))
- Improve style invalidation performance of `group-*` and `peer-*` variants ([#20513](https://github.com/tailwindlabs/tailwindcss/pull/20513))
## [4.3.3] - 2026-07-16
### Fixed
- Support `--watch --poll[=ms]` in `@tailwindcss/cli` when filesystem events are unreliable or unavailable ([#20297](https://github.com/tailwindlabs/tailwindcss/pull/20297))
- Canonicalization: match arbitrary hex colors against theme colors case-insensitively (e.g. `bg-[#fff]` and `bg-[#FFF]` → `bg-white`) ([#20298](https://github.com/tailwindlabs/tailwindcss/pull/20298))
- Ensure `theme('colors.foo')` in JS plugins resolves correctly when both `--color-foo` and `--color-foo-bar` exist ([#20299](https://github.com/tailwindlabs/tailwindcss/pull/20299))
- Ensure fractional opacity modifiers work with named shadow sizes like `shadow-sm/12.5`, `text-shadow-sm/12.5`, `drop-shadow-sm/12.5`, and `inset-shadow-sm/12.5` ([#20302](https://github.com/tailwindlabs/tailwindcss/pull/20302))
- Parse selectors like `[data-foo]div` as two selectors instead of one ([#20303](https://github.com/tailwindlabs/tailwindcss/pull/20303))
- Ensure `@tailwindcss/postcss` rebuilds when a preprocessor like Sass changes the input CSS without changing the input file on disk ([#20310](https://github.com/tailwindlabs/tailwindcss/pull/20310))
- Ensure CSS nesting is handled even when Lightning CSS isn't run, such as in `@tailwindcss/browser` and Tailwind Play ([#20124](https://github.com/tailwindlabs/tailwindcss/pull/20124))
- Prevent achromatic theme colors from shifting hue when mixed in polar color spaces like `oklch` ([#20314](https://github.com/tailwindlabs/tailwindcss/pull/20314))
- Ensure `--spacing(0)` is optimized to `0px` instead of `0` so it remains a `<length>` when used in `calc(…)` ([#20319](https://github.com/tailwindlabs/tailwindcss/pull/20319))
- Load `@parcel/watcher` only when needed in `@tailwindcss/cli --watch` mode, so one-off builds and `--watch --poll` work when `@parcel/watcher` can't be loaded ([#20325](https://github.com/tailwindlabs/tailwindcss/pull/20325))
- Use explicit platform fonts instead of `system-ui` and `ui-sans-serif` so CJK text respects the page's `lang` attribute on Windows ([#20318](https://github.com/tailwindlabs/tailwindcss/pull/20318))
- Prevent `@tailwindcss/upgrade` from rewriting ignored files when run from a subdirectory ([#20329](https://github.com/tailwindlabs/tailwindcss/pull/20329))
- Ensure earlier `@source` rules pointing to nested files are scanned when later `@source` rules point to files in parent folders ([#20335](https://github.com/tailwindlabs/tailwindcss/pull/20335))
- Prevent `@tailwindcss/vite` from triggering full page reloads when scanned files are processed by Vite but haven't been loaded as modules yet ([#20336](https://github.com/tailwindlabs/tailwindcss/pull/20336))
## [4.3.2] - 2026-06-26
### Fixed
- Support bare spacing values for `auto-rows-*` and `auto-cols-*` utilities (e.g. `auto-rows-12` and `auto-cols-16`) ([#20229](https://github.com/tailwindlabs/tailwindcss/pull/20229))
- Prevent `@tailwindcss/cli` in `--watch` mode from crashing on Windows when `@source` points to a directory that doesn't exist ([#20242](https://github.com/tailwindlabs/tailwindcss/pull/20242))
- Prevent `@tailwindcss/vite` from crashing in Deno v2.8.x when `context.parentURL` is not a valid URL ([#20245](https://github.com/tailwindlabs/tailwindcss/pull/20245))
- Ensure `@tailwindcss/cli` in `--watch` mode rebuilds when the input CSS file changes in an ignored directory ([#20246](https://github.com/tailwindlabs/tailwindcss/pull/20246))
- Allow `@variant` rules used in `addBase(…)` to use custom variants defined later ([#20247](https://github.com/tailwindlabs/tailwindcss/pull/20247))
- Prevent `@tailwindcss/vite` from crashing during HMR when scanned files or directories are deleted ([#20259](https://github.com/tailwindlabs/tailwindcss/pull/20259))
- Generate `font-size` instead of `color` declarations for `text-[--spacing(…)]` ([#20260](https://github.com/tailwindlabs/tailwindcss/pull/20260))
- Prevent `@source` patterns from scanning unrelated sibling files and folders ([#20263](https://github.com/tailwindlabs/tailwindcss/pull/20263))
- Extract class candidates adjacent to Template Toolkit delimiters like `%]…[%` in `.tt`, `.tt2`, and `.tx` files ([#20269](https://github.com/tailwindlabs/tailwindcss/pull/20269))
- Extract class candidates from conditional Maud syntax like `p.text-black[condition]` ([#20269](https://github.com/tailwindlabs/tailwindcss/pull/20269))
- Prevent `@position-try` rules from triggering unknown at-rule warnings when optimizing CSS ([#20277](https://github.com/tailwindlabs/tailwindcss/pull/20277))
- Support class suggestions for named opacity modifiers from `--opacity` theme values ([#20287](https://github.com/tailwindlabs/tailwindcss/pull/20287))
- Prevent type errors in `@tailwindcss/postcss` when used with newer PostCSS patch releases ([#20289](https://github.com/tailwindlabs/tailwindcss/pull/20289))
## [4.3.1] - 2026-06-12
### Added
- Add `--silent` option to suppress output in `@tailwindcss/cli` ([#20100](https://github.com/tailwindlabs/tailwindcss/pull/20100))
### Fixed
- Remove deprecation warnings by using `Module#registerHooks` instead of `Module#register` on Node 26+ ([#20028](https://github.com/tailwindlabs/tailwindcss/pull/20028))
- Canonicalization: don't crash when plugin utilities throw for unsupported values ([#20052](https://github.com/tailwindlabs/tailwindcss/pull/20052))
- Allow `@apply` to be used with CSS mixins ([#19427](https://github.com/tailwindlabs/tailwindcss/pull/19427))
- Ensure `drop-shadow-*` color utilities work with custom shadow values containing `calc(…)` ([#20080](https://github.com/tailwindlabs/tailwindcss/pull/20080))
- Fix 'Sourcemap is likely to be incorrect' warnings when using `@tailwindcss/vite` ([#20103](https://github.com/tailwindlabs/tailwindcss/pull/20103))
- Ensure `@tailwindcss/webpack` can be installed in Rspack projects without requiring `webpack` as a peer dependency ([#20027](https://github.com/tailwindlabs/tailwindcss/pull/20027))
- Canonicalization: avoid suggesting large spacing-scale values for arbitrary lengths (e.g. `left-[99999px]` → `left-[99999px]`, not `left-24999.75`) ([#20130](https://github.com/tailwindlabs/tailwindcss/pull/20130))
- Ensure `@tailwindcss/cli` in `--watch` mode recovers when a tracked dependency is deleted and restored ([#20137](https://github.com/tailwindlabs/tailwindcss/pull/20137))
- Ensure standalone `@tailwindcss/cli` binaries are ignored when scanning for class candidates ([#20139](https://github.com/tailwindlabs/tailwindcss/pull/20139))
- Ensure class candidates are extracted from Twig `addClass(…)` and `removeClass(…)` calls ([#20198](https://github.com/tailwindlabs/tailwindcss/pull/20198))
- Don't crash in the Ruby or Vue preprocessors when scanning files containing invalid UTF-8 bytes ([#19588](https://github.com/tailwindlabs/tailwindcss/pull/19588))
- Allow `@variant` to be used inside `addBase` ([#19480](https://github.com/tailwindlabs/tailwindcss/pull/19480))
- Ensure `@source` globs with symlinks are preserved ([#20203](https://github.com/tailwindlabs/tailwindcss/pull/20203))
- Ensure later `@source` rules can re-include files excluded by earlier `@source not` rules ([#20203](https://github.com/tailwindlabs/tailwindcss/pull/20203))
- Upgrade: don't migrate empty class rules to invalid `@utility` rules ([#20205](https://github.com/tailwindlabs/tailwindcss/pull/20205))
- Ensure transitions between `inset-shadow-none` and other inset shadows work correctly ([#20208](https://github.com/tailwindlabs/tailwindcss/pull/20208))
- Ensure explicitly referenced `@source` directories are scanned even when ignored by git ([#20214](https://github.com/tailwindlabs/tailwindcss/pull/20214))
- Ensure `@source` globs ending in `**/*` preserve dynamic path segments to avoid scanning too many files ([#20217](https://github.com/tailwindlabs/tailwindcss/pull/20217))
- Canonicalization: don't fold `calc(…)` divisions when the result would require high precision (e.g. `w-[calc(100%/3.5)]` → `w-[calc(100%/3.5)]`, not `w-[28.571428571428573%]`) ([#20221](https://github.com/tailwindlabs/tailwindcss/pull/20221))
- Serve ESM type declarations to ESM importers of `@tailwindcss/postcss` ([#20228](https://github.com/tailwindlabs/tailwindcss/pull/20228))
### Changed
- Generate `0` instead of `calc(var(--spacing) * 0)` for spacing utilities like `m-0` and `left-0` ([#20196](https://github.com/tailwindlabs/tailwindcss/pull/20196))
- Generate `var(--spacing)` instead of `calc(var(--spacing) * 1)` for spacing utilities like `m-1` and `left-1` ([#20196](https://github.com/tailwindlabs/tailwindcss/pull/20196))
- Add `scrollbar-{auto,thin,none}` utilities for `scrollbar-width`, and `scrollbar-thumb-*` / `scrollbar-track-*` color utilities for `scrollbar-color` ([#19981](https://github.com/tailwindlabs/tailwindcss/pull/19981), [#20019](https://github.com/tailwindlabs/tailwindcss/pull/20019))
- Allow using `@variant` with stacked variants (e.g. `@variant hover:focus { … }`) ([#19996](https://github.com/tailwindlabs/tailwindcss/pull/19996))
- Allow using `@variant` with compound variants (e.g. `@variant hover, focus { … }`) ([#19996](https://github.com/tailwindlabs/tailwindcss/pull/19996))
- Support `--default(…)` in `--value(…)` and `--modifier(…)` for functional `@utility` definitions ([#19989](https://github.com/tailwindlabs/tailwindcss/pull/19989))
### Fixed
- Ensure `@plugin` resolves package JavaScript entries instead of browser CSS entries when using `@tailwindcss/vite` ([#19949](https://github.com/tailwindlabs/tailwindcss/pull/19949))
- Fix relative `@import` and `@plugin` paths resolving from the wrong directory when using `@tailwindcss/vite` ([#19965](https://github.com/tailwindlabs/tailwindcss/pull/19965))
- Ensure CSS files containing `@variant` are processed by `@tailwindcss/vite` ([#19966](https://github.com/tailwindlabs/tailwindcss/pull/19966))
- Resolve imports relative to `base` when `result.opts.from` is not provided when using `@tailwindcss/postcss` ([#19980](https://github.com/tailwindlabs/tailwindcss/pull/19980))
- Canonicalization: preserve significant `_` whitespace in arbitrary values ([#19986](https://github.com/tailwindlabs/tailwindcss/pull/19986))
- Canonicalization: add parentheses when removing whitespace from arbitrary values would hurt readability (e.g. `w-[calc(100%---spacing(60))]` → `w-[calc(100%-(--spacing(60)))]`) ([#19986](https://github.com/tailwindlabs/tailwindcss/pull/19986))
- Canonicalization: preserve the original unit in arbitrary values instead of normalizing to base units (e.g. `-mt-[20in]` → `mt-[-20in]`, not `mt-[-1920px]`) ([#19988](https://github.com/tailwindlabs/tailwindcss/pull/19988))
- Canonicalization: migrate arbitrary `:has()` variants from `[&:has(…)]` to `has-[…]` ([#19991](https://github.com/tailwindlabs/tailwindcss/pull/19991))
- Allow multiple `@utility` definitions with the same name but different value types ([#19777](https://github.com/tailwindlabs/tailwindcss/pull/19777))
- Export missing `PluginWithConfig` type from `tailwindcss/plugin` to fix errors when inferring plugin config types ([#19707](https://github.com/tailwindlabs/tailwindcss/pull/19707))
- Ensure `start` and `end` legacy utilities without values do not generate CSS ([#20003](https://github.com/tailwindlabs/tailwindcss/pull/20003))
- Ensure `--value(…)` is required in functional `@utility` definitions ([#20005](https://github.com/tailwindlabs/tailwindcss/pull/20005))
- Canonicalization: preserve required whitespace around operators in negated arbitrary values (e.g. `-left-[(var(--a)+var(--b))]`) ([#20011](https://github.com/tailwindlabs/tailwindcss/pull/20011))
## [4.2.4] - 2026-04-21
### Fixed
- Ensure imports in `@import` and `@plugin` still resolve correctly when using Vite aliases in `@tailwindcss/vite` ([#19947](https://github.com/tailwindlabs/tailwindcss/pull/19947))
## [4.2.3] - 2026-04-20
### Fixed
- Canonicalization: improve canonicalization for `tracking-*` utilities by preferring non-negative utilities (e.g. `-tracking-tighter` → `tracking-wider`) ([#19827](https://github.com/tailwindlabs/tailwindcss/pull/19827))
- Fix crash due to invalid characters in candidate (exceeding valid unicode code point range) ([#19829](https://github.com/tailwindlabs/tailwindcss/pull/19829))
- Ensure query params in imports are considered unique resources when using `@tailwindcss/webpack` ([#19723](https://github.com/tailwindlabs/tailwindcss/pull/19723))
- Canonicalization: collapse `border-{t,b}-*` into `border-y-*`, `border-{l,r}-*` into `border-x-*`, and `border-{t,r,b,l}-*` into `border-*` ([#19842](https://github.com/tailwindlabs/tailwindcss/pull/19842))
- Canonicalization: collapse `scroll-m{t,b}-*` into `scroll-my-*`, `scroll-m{l,r}-*` into `scroll-mx-*`, and `scroll-m{t,r,b,l}-*` into `scroll-m-*` ([#19842](https://github.com/tailwindlabs/tailwindcss/pull/19842))
- Canonicalization: collapse `scroll-p{t,b}-*` into `scroll-py-*`, `scroll-p{l,r}-*` into `scroll-px-*`, and `scroll-p{t,r,b,l}-*` into `scroll-p-*` ([#19842](https://github.com/tailwindlabs/tailwindcss/pull/19842))
- Canonicalization: collapse `overflow-{x,y}-*` into `overflow-*` ([#19842](https://github.com/tailwindlabs/tailwindcss/pull/19842))
- Canonicalization: collapse `overscroll-{x,y}-*` into `overscroll-*` ([#19842](https://github.com/tailwindlabs/tailwindcss/pull/19842))
- Read from `--placeholder-color` instead of `--background-color` for `placeholder-*` utilities ([#19843](https://github.com/tailwindlabs/tailwindcss/pull/19843))
- Upgrade: ensure files are not emptied out when killing the upgrade process while it's running ([#19846](https://github.com/tailwindlabs/tailwindcss/pull/19846))
- Upgrade: use `config.content` when migrating from Tailwind CSS v3 to Tailwind CSS v4 ([#19846](https://github.com/tailwindlabs/tailwindcss/pull/19846))
- Upgrade: never migrate files that are ignored by git ([#19846](https://github.com/tailwindlabs/tailwindcss/pull/19846))
- Add `.env` and `.env.*` to default ignored content files ([#19846](https://github.com/tailwindlabs/tailwindcss/pull/19846))
- Canonicalization: migrate `overflow-ellipsis` into `text-ellipsis` ([#19849](https://github.com/tailwindlabs/tailwindcss/pull/19849))
- Canonicalization: migrate `start-full` → `inset-s-full`, `start-auto` → `inset-s-auto`, `start-px` → `inset-s-px`, and `start-<number>` → `inset-s-<number>` as well as negative versions ([#19849](https://github.com/tailwindlabs/tailwindcss/pull/19849))
- Canonicalization: migrate `end-full` → `inset-e-full`, `end-auto` → `inset-e-auto`, `end-px` → `inset-e-px`, and `end-<number>` → `inset-e-<number>` as well as negative versions ([#19849](https://github.com/tailwindlabs/tailwindcss/pull/19849))
- Canonicalization: move the `-` sign inside the arbitrary value `-left-[9rem]` → `left-[-9rem]` ([#19858](https://github.com/tailwindlabs/tailwindcss/pull/19858))
- Canonicalization: move the `-` sign outside the arbitrary value `ml-[calc(-1*var(--width))]` → `-ml-(--width)` ([#19858](https://github.com/tailwindlabs/tailwindcss/pull/19858))
- Improve performance when scanning JSONL / NDJSON files ([#19862](https://github.com/tailwindlabs/tailwindcss/pull/19862))
- Support `NODE_PATH` environment variable in standalone CLI ([#19617](https://github.com/tailwindlabs/tailwindcss/pull/19617))
## [4.2.2] - 2026-03-18
## [4.2.2] - 2026-03-18
@ -22,6 +184,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
- Add support for Vite 8 in `@tailwindcss/vite` ([#19790](https://github.com/tailwindlabs/tailwindcss/pull/19790))
- Add support for Vite 8 in `@tailwindcss/vite` ([#19790](https://github.com/tailwindlabs/tailwindcss/pull/19790))
- Improve canonicalization for bare values exceeding default spacing scale suggestions (e.g. `w-1234 h-1234` → `size-1234`) ([#19809](https://github.com/tailwindlabs/tailwindcss/pull/19809))
- Improve canonicalization for bare values exceeding default spacing scale suggestions (e.g. `w-1234 h-1234` → `size-1234`) ([#19809](https://github.com/tailwindlabs/tailwindcss/pull/19809))
- Fix canonicalization resulting in empty list (e.g. `w-5 h-5 size-5` → `''` instead of `size-5`) ([#19812](https://github.com/tailwindlabs/tailwindcss/pull/19812))
- Fix canonicalization resulting in empty list (e.g. `w-5 h-5 size-5` → `''` instead of `size-5`) ([#19812](https://github.com/tailwindlabs/tailwindcss/pull/19812))
- Resolve tsconfig paths to allow for `@import '@/path/to/file';` when using `@tailwindcss/vite` ([#19803](https://github.com/tailwindlabs/tailwindcss/pull/19803))
`It looks like you're trying to use \`tailwindcss\` directly as a PostCSS plugin. The PostCSS plugin has moved to a separate package, so to continue using Tailwind CSS with PostCSS you'll need to install \`@tailwindcss/postcss\` and update your PostCSS configuration.`,
`It looks like you're trying to use \`tailwindcss\` directly as a PostCSS plugin. The PostCSS plugin has moved to a separate package, so to continue using Tailwind CSS with PostCSS you'll need to install \`@tailwindcss/postcss\` and update your PostCSS configuration.`,
`Failed to load the file watcher. Your platform may not be supported by \`@parcel/watcher\`. As a workaround, you can use polling instead by passing the \`--watch --poll\` flags.`,
