PostCSS: Fix Turbopack 'one-revision-behind' bug - #17554

…minor)

This PR contains the following updates:

| Package | Change | Age | Adoption | Passing | Confidence |
|---|---|---|---|---|---|
| [@tailwindcss/postcss](https://tailwindcss.com) ([source](https://github.com/tailwindlabs/tailwindcss/tree/HEAD/packages/@tailwindcss-postcss)) | [`4.0.17` -> `4.1.3`](https://renovatebot.com/diffs/npm/@tailwindcss%2fpostcss/4.0.17/4.1.3) | [![age](https://developer.mend.io/api/mc/badges/age/npm/@tailwindcss%2fpostcss/4.1.3?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![adoption](https://developer.mend.io/api/mc/badges/adoption/npm/@tailwindcss%2fpostcss/4.1.3?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![passing](https://developer.mend.io/api/mc/badges/compatibility/npm/@tailwindcss%2fpostcss/4.0.17/4.1.3?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![confidence](https://developer.mend.io/api/mc/badges/confidence/npm/@tailwindcss%2fpostcss/4.0.17/4.1.3?slim=true)](https://docs.renovatebot.com/merge-confidence/) |
| [tailwindcss](https://tailwindcss.com) ([source](https://github.com/tailwindlabs/tailwindcss/tree/HEAD/packages/tailwindcss)) | [`4.0.17` -> `4.1.3`](https://renovatebot.com/diffs/npm/tailwindcss/4.0.17/4.1.3) | [![age](https://developer.mend.io/api/mc/badges/age/npm/tailwindcss/4.1.3?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![adoption](https://developer.mend.io/api/mc/badges/adoption/npm/tailwindcss/4.1.3?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![passing](https://developer.mend.io/api/mc/badges/compatibility/npm/tailwindcss/4.0.17/4.1.3?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![confidence](https://developer.mend.io/api/mc/badges/confidence/npm/tailwindcss/4.0.17/4.1.3?slim=true)](https://docs.renovatebot.com/merge-confidence/) |

---

### Release Notes

<details>
<summary>tailwindlabs/tailwindcss (@&#8203;tailwindcss/postcss)</summary>

### [`v4.1.3`](https://github.com/tailwindlabs/tailwindcss/blob/HEAD/CHANGELOG.md#413---2025-04-04)

[Compare Source](tailwindlabs/tailwindcss@v4.1.2...v4.1.3)

##### Fixed

-   Show warning when using unsupported bare value data type in `--value(…)` ([#&#8203;17464](tailwindlabs/tailwindcss#17464))
-   PostCSS: Ensure changes to the input CSS file don't generate stale output when using Turbopack ([#&#8203;17554](tailwindlabs/tailwindcss#17554))
-   Ensure classes are detected in Ruby's `%w` syntax in Slim templates ([#&#8203;17557](tailwindlabs/tailwindcss#17557))

### [`v4.1.2`](https://github.com/tailwindlabs/tailwindcss/blob/HEAD/CHANGELOG.md#412---2025-04-03)

[Compare Source](tailwindlabs/tailwindcss@v4.1.1...v4.1.2)

##### Fixed

-   Don't rely on the presence of `@layer base` to polyfill `@property` ([#&#8203;17506](tailwindlabs/tailwindcss#17506))
-   Support setting multiple inset shadows as arbi...

…input CSS changes (#20582)

This PR fixes an issue where `next dev` with the
`@tailwindcss/turbopack` loader keeps serving the CSS of the previous
edit after you edit the CSS file. Only a restart of the dev server shows
the latest version.

Fixes #20581

The loader caches a compiler for each CSS file. It only does a full
rebuild when the mtime of the input file (or of one of its dependencies)
changes. After a save, Turbopack can run the loader two times:

1. With the previous version of the CSS file. The file on disk already
has the new mtime, so we did a full rebuild from the old source, and
stored the new mtime.
2. With the new version of the CSS file. The mtime did not change since
the first call, so we did an incremental build with the stale compiler
of the first call.

The loader registers the folders that it scans as context dependencies,
and the CSS file is in one of them (e.g. `app/`). So one save
invalidates the loader in two ways, and the first run can still get the
previous content of the file.

`@tailwindcss/postcss` had the same problem with Turbopack
(#17554), and it
compares the input CSS with the input CSS of the last build since
#20310. The loader now
does the same: it stores the source on the cache entry, and does a full
rebuild when the source changes.

`@tailwindcss/turbopack` is a copy of `@tailwindcss/webpack`, so the
webpack loader gets the same fix. With webpack, the problem shows up
when a loader that runs before ours changes the CSS, but not the input
file. For example, `sass-loader` inlines a partial, and you edit that
partial.

The matrix of the integration tests in CI had no `turbopack` entry, so
the tests in `integrations/turbopack` never ran in CI. This PR adds it.

## Test plan

- Added an integration test to `integrations/turbopack/loader.test.ts`.
It edits `app/globals.css` three times during `next dev`, and checks
that the served CSS has each edit. On `main` (with Next.js 16.4.1), the
served CSS still has `.custom-1` after the first edit. With this change,
it passes.
- Added an integration test to `integrations/webpack/loader.test.ts`,
with a loader before `@tailwindcss/webpack` that inlines
`src/partial.css`. In watch mode, it edits that partial. On `main`, the
output keeps `.partial-1`. With this change, it passes.
- Called the built loaders directly, like Turbopack does: first with the
previous source after the file changed on disk, then with the new
source. On `main`, the second call returns the CSS of the previous
version. With this change, each call returns the CSS of the source that
it gets.
- `pnpm run build` passes, and all tests in
`integrations/turbopack/loader.test.ts` and
`integrations/webpack/loader.test.ts` pass.

<sub>Sent by an AI assistant on behalf of @RobinMalfait.</sub>