2024-05-24 15:07:44 +02:00
|
|
|
lockfileVersion: '9.0'
|
2024-03-05 14:23:26 +01:00
|
|
|
|
|
|
|
|
settings:
|
|
|
|
|
autoInstallPeers: true
|
|
|
|
|
excludeLinksFromLockfile: false
|
|
|
|
|
|
2024-12-18 18:06:26 +00:00
|
|
|
catalogs:
|
|
|
|
|
default:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher':
|
|
|
|
|
specifier: 2.6.0
|
|
|
|
|
version: 2.6.0
|
|
|
|
|
'@parcel/watcher-darwin-arm64':
|
|
|
|
|
specifier: 2.6.0
|
|
|
|
|
version: 2.6.0
|
|
|
|
|
'@parcel/watcher-darwin-x64':
|
|
|
|
|
specifier: 2.6.0
|
|
|
|
|
version: 2.6.0
|
|
|
|
|
'@parcel/watcher-linux-arm64-glibc':
|
|
|
|
|
specifier: 2.6.0
|
|
|
|
|
version: 2.6.0
|
|
|
|
|
'@parcel/watcher-linux-arm64-musl':
|
|
|
|
|
specifier: 2.6.0
|
|
|
|
|
version: 2.6.0
|
|
|
|
|
'@parcel/watcher-linux-x64-glibc':
|
|
|
|
|
specifier: 2.6.0
|
|
|
|
|
version: 2.6.0
|
|
|
|
|
'@parcel/watcher-linux-x64-musl':
|
|
|
|
|
specifier: 2.6.0
|
|
|
|
|
version: 2.6.0
|
|
|
|
|
'@parcel/watcher-win32-x64':
|
|
|
|
|
specifier: 2.6.0
|
|
|
|
|
version: 2.6.0
|
2024-12-18 18:06:26 +00:00
|
|
|
'@types/node':
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: 22.20.1
|
|
|
|
|
version: 22.20.1
|
2026-05-21 17:58:55 +02:00
|
|
|
dedent:
|
|
|
|
|
specifier: 1.7.2
|
|
|
|
|
version: 1.7.2
|
|
|
|
|
enhanced-resolve:
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: ^5.24.5
|
|
|
|
|
version: 5.24.5
|
2024-12-18 18:06:26 +00:00
|
|
|
lightningcss:
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: 1.33.0
|
|
|
|
|
version: 1.33.0
|
2025-03-13 11:18:06 +01:00
|
|
|
lightningcss-darwin-arm64:
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: 1.33.0
|
|
|
|
|
version: 1.33.0
|
2025-03-13 11:18:06 +01:00
|
|
|
lightningcss-darwin-x64:
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: 1.33.0
|
|
|
|
|
version: 1.33.0
|
2025-03-13 11:18:06 +01:00
|
|
|
lightningcss-linux-arm64-gnu:
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: 1.33.0
|
|
|
|
|
version: 1.33.0
|
2025-03-13 11:18:06 +01:00
|
|
|
lightningcss-linux-arm64-musl:
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: 1.33.0
|
|
|
|
|
version: 1.33.0
|
2025-03-13 11:18:06 +01:00
|
|
|
lightningcss-linux-x64-gnu:
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: 1.33.0
|
|
|
|
|
version: 1.33.0
|
2025-03-13 11:18:06 +01:00
|
|
|
lightningcss-linux-x64-musl:
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: 1.33.0
|
|
|
|
|
version: 1.33.0
|
2025-03-13 11:18:06 +01:00
|
|
|
lightningcss-win32-x64-msvc:
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: 1.33.0
|
|
|
|
|
version: 1.33.0
|
2026-05-21 17:58:55 +02:00
|
|
|
postcss:
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: ^8.5.25
|
|
|
|
|
version: 8.5.25
|
2025-02-10 10:54:45 +01:00
|
|
|
prettier:
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: 3.9.6
|
|
|
|
|
version: 3.9.6
|
2024-12-18 18:06:26 +00:00
|
|
|
vite:
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: ^8.2.0
|
|
|
|
|
version: 8.2.0
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
webpack:
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: ^5.109.2
|
|
|
|
|
version: 5.109.2
|
2024-12-18 18:06:26 +00:00
|
|
|
|
2024-09-02 15:23:46 +02:00
|
|
|
patchedDependencies:
|
Use wasm as a fallback for `@tailwindcss/oxide` (#20383)
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]
2026-08-04 18:41:43 +02:00
|
|
|
'@napi-rs/cli@3.7.4': 9912bf0a9c2cef8329d11c41fbce4d33ce2bdcf660a630b258c962c0a3c44bed
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher@2.6.0': 705ce75ccea54337110c4d7fe0a8b421658ea0c23e1a77c1fa890a86041179da
|
|
|
|
|
lightningcss@1.33.0: 1d4a8800d60d13d42887b88b3a86576df4b451670308145fb432ec8abbf40930
|
2024-09-02 15:23:46 +02:00
|
|
|
|
2024-03-05 14:23:26 +01:00
|
|
|
importers:
|
2024-12-18 18:06:26 +00:00
|
|
|
|
2024-03-05 14:23:26 +01:00
|
|
|
.:
|
|
|
|
|
devDependencies:
|
|
|
|
|
'@playwright/test':
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: ^1.62.1
|
|
|
|
|
version: 1.62.1
|
2024-03-05 14:23:26 +01:00
|
|
|
'@types/node':
|
2024-08-09 16:12:24 +02:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 22.20.1
|
2024-03-13 22:26:10 +01:00
|
|
|
postcss:
|
2026-05-21 17:58:55 +02:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 8.5.25
|
2024-03-13 22:26:10 +01:00
|
|
|
postcss-import:
|
2025-06-24 09:57:35 -04:00
|
|
|
specifier: ^16.1.1
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 16.1.1(postcss@8.5.25)
|
2024-03-05 14:23:26 +01:00
|
|
|
prettier:
|
2025-02-10 10:54:45 +01:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 3.9.6
|
Add integration test setup and tests for the Vite integration (#14089)
This PR adds a new root `/integrations` folder that will be the home of
integration tests. The idea of these tests is to use Tailwind in various
setups just like our users would (by only using the publishable npm
builds).
To avoid issues with concurrent tests making changes to the file system,
to make it very easy to test through a range of versions, and to avoid
changing configuration objects over and over in test runs, we decided to
inline the scaffolding completely into the test file and have no
examples checked into the repo.
Here's an example of how this can look like for a simple Vite test:
```ts
test('works with production builds', {
fs: {
'package.json': json`
{
"type": "module",
"dependencies": {
"@tailwindcss/vite": "workspace:^",
"tailwindcss": "workspace:^"
},
"devDependencies": {
"vite": "^5.3.5"
}
}
`,
'vite.config.ts': ts`
import tailwindcss from '@tailwindcss/vite'
import { defineConfig } from 'vite'
export default defineConfig({
build: { cssMinify: false },
plugins: [tailwindcss()],
})
`,
'index.html': html`
<head>
<link rel="stylesheet" href="./src/index.css">
</head>
<body>
<div class="underline m-2">Hello, world!</div>
</body>
`,
'src/index.css': css`
@import 'tailwindcss/theme' reference;
@import 'tailwindcss/utilities';
`,
},
},
async ({ fs, exec }) => {
await exec('pnpm vite build')
expect.assertions(2)
for (let [path, content] of await fs.glob('dist/**/*.css')) {
expect(path).toMatch(/\.css$/)
expect(stripTailwindComment(content)).toMatchInlineSnapshot(
`
".m-2 {
margin: var(--spacing-2, .5rem);
}
.underline {
text-decoration-line: underline;
}"
`,
)
}
},
)
```
By defining all dependencies this way, we never have to worry about
which fixtures are checked in and can more easily describe changes to
the setup.
For ergonomics, we've also added the [`embed` prettier
plugin](https://github.com/Sec-ant/prettier-plugin-embed). This will
mean that files inlined in the `fs` setup are properly indented. No
extra work needed!
If you're using VS Code, I can also recommend the [Language
Literals](https://marketplace.visualstudio.com/items?itemName=sissel.language-literals)
extension so that syntax highlighting also _just works_.
A neat feature of inlining the scaffolding like this is to make it very
simple to test through a variety of versions. For example, here's how we
can set up a test against Vite 5 and Vite 4:
```js
;['^4.5.3', '^5.3.5'].forEach(viteVersion => {
test(`works with production builds for Vite ${viteVersion}`, {
fs: {
'package.json': json`
{
"type": "module",
"devDependencies": {
"vite": "${viteVersion}"
}
}
`,
async () => {
// Do something
},
)
})
```
## Philosophy
Before we dive into the specifics, I want to clearly state the design
considerations we have chosen for this new test suite:
- All file mutations should be done in temp folders, nothing should ever
mess with your working directory
- Windows as a first-class citizen
- Have a clean and simple API that describes the test setup only using
public APIs
- Focus on reliability (make sure cleanup scripts work and are tolerant
to various error scenarios)
- If a user reports an issue with a specific configuration, we want to
be able to reproduce them with integration tests, no matter how obscure
the setup (this means the test need to be in control of most of the
variables)
- Tests should be reasonably fast (obviously this depends on the
integration. If we use a slow build tool, we can't magically speed it
up, but our overhead should be minimal).
## How it works
The current implementation provides a custom `test` helper function
that, when used, sets up the environment according to the configuration.
It'll create a new temporary directory and create all files, ensuring
things like proper `\r\n` line endings on Windows.
We do have to patch the `package.json` specifically, since we can not
use public versions of the tailwindcss packages as we want to be able to
test against a development build. To make this happen, every `pnpm
build` run now creates tarballs of the npm modules (that contain only
the files that would also in the published build). We then patch the
`package.json` to rewrite `workspace:^` versions to link to those
tarballs. We found this to work reliably on Windows and macOS as well as
being fast enough to not cause any issues. Furthermore we also decided
to use `pnpm` as the version manager for integration tests because of
it's global module cache (so installing `vite` is fast as soon as you
installed it once).
The test function will receive a few utilities that it can use to more
easily interact with the temp dir. One example is a `fs.glob` function
that you can use to easily find files in eventual `dist/` directories or
helpers around `spawn` and `exec` that make sure that processes are
cleaned up correctly.
Because we use tarballs from our build dependencies, working on changes
requires a workflow where you run `pnpm build` before running `pnpm
test:integrations`. However it also means we can run clients like our
CLI client with no additional overhead—just install the dependency like
any user would and set up your test cases this way.
## Test plan
This PR also includes two Vite specific integration tests: One testing a
static build (`pnpm vite build`) and one a dev mode build (`pnpm vite
dev`) that also makes changes to the file system and asserts that the
resources properly update.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-08-02 11:50:49 +02:00
|
|
|
prettier-plugin-embed:
|
2025-12-26 12:36:51 -05:00
|
|
|
specifier: ^0.5.1
|
|
|
|
|
version: 0.5.1
|
2024-03-05 14:23:26 +01:00
|
|
|
prettier-plugin-organize-imports:
|
2025-09-26 16:10:41 -04:00
|
|
|
specifier: ^4.3.0
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 4.3.0(prettier@3.9.6)(typescript@5.9.3)
|
2024-03-05 14:23:26 +01:00
|
|
|
tsup:
|
2025-11-19 18:18:45 -05:00
|
|
|
specifier: ^8.5.1
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 8.5.1(jiti@2.7.0)(postcss@8.5.25)(typescript@5.9.3)(yaml@2.9.0)
|
2024-03-05 14:23:26 +01:00
|
|
|
turbo:
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: ^2.10.8
|
|
|
|
|
version: 2.10.8
|
2024-03-05 14:23:26 +01:00
|
|
|
typescript:
|
2026-04-24 21:21:12 +02:00
|
|
|
specifier: ^5.9.3
|
|
|
|
|
version: 5.9.3
|
2024-03-05 14:23:26 +01:00
|
|
|
vitest:
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: ^4.1.10
|
|
|
|
|
version: 4.1.10(@types/node@22.20.1)(vite@8.2.0(@types/node@22.20.1)(esbuild@0.27.7)(jiti@2.7.0)(terser@5.48.0)(yaml@2.9.0))
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-03-23 14:00:48 +01:00
|
|
|
crates/node:
|
2026-06-25 19:14:10 +02:00
|
|
|
devDependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@emnapi/core':
|
|
|
|
|
specifier: 1.11.3
|
|
|
|
|
version: 1.11.3
|
|
|
|
|
'@emnapi/runtime':
|
|
|
|
|
specifier: 1.11.3
|
|
|
|
|
version: 1.11.3
|
2026-06-25 19:14:10 +02:00
|
|
|
'@napi-rs/cli':
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: 3.7.4
|
Use wasm as a fallback for `@tailwindcss/oxide` (#20383)
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]
2026-08-04 18:41:43 +02:00
|
|
|
version: 3.7.4(patch_hash=9912bf0a9c2cef8329d11c41fbce4d33ce2bdcf660a630b258c962c0a3c44bed)(@emnapi/core@1.11.3)(@emnapi/runtime@1.11.3)(@types/node@25.9.1)(node-addon-api@8.7.0)
|
2026-06-25 19:14:10 +02:00
|
|
|
'@napi-rs/wasm-runtime':
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: ^1.2.2
|
|
|
|
|
version: 1.2.2(@emnapi/core@1.11.3)(@emnapi/runtime@1.11.3)
|
2026-06-25 19:14:10 +02:00
|
|
|
emnapi:
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: 1.11.3
|
|
|
|
|
version: 1.11.3(node-addon-api@8.7.0)
|
2024-03-05 14:23:26 +01:00
|
|
|
optionalDependencies:
|
2024-03-08 20:08:24 +03:00
|
|
|
'@tailwindcss/oxide-android-arm64':
|
|
|
|
|
specifier: workspace:*
|
|
|
|
|
version: link:npm/android-arm64
|
2024-03-05 14:23:26 +01:00
|
|
|
'@tailwindcss/oxide-darwin-arm64':
|
|
|
|
|
specifier: workspace:*
|
|
|
|
|
version: link:npm/darwin-arm64
|
|
|
|
|
'@tailwindcss/oxide-darwin-x64':
|
|
|
|
|
specifier: workspace:*
|
|
|
|
|
version: link:npm/darwin-x64
|
|
|
|
|
'@tailwindcss/oxide-freebsd-x64':
|
|
|
|
|
specifier: workspace:*
|
|
|
|
|
version: link:npm/freebsd-x64
|
|
|
|
|
'@tailwindcss/oxide-linux-arm-gnueabihf':
|
|
|
|
|
specifier: workspace:*
|
|
|
|
|
version: link:npm/linux-arm-gnueabihf
|
|
|
|
|
'@tailwindcss/oxide-linux-arm64-gnu':
|
|
|
|
|
specifier: workspace:*
|
|
|
|
|
version: link:npm/linux-arm64-gnu
|
|
|
|
|
'@tailwindcss/oxide-linux-arm64-musl':
|
|
|
|
|
specifier: workspace:*
|
|
|
|
|
version: link:npm/linux-arm64-musl
|
|
|
|
|
'@tailwindcss/oxide-linux-x64-gnu':
|
|
|
|
|
specifier: workspace:*
|
|
|
|
|
version: link:npm/linux-x64-gnu
|
|
|
|
|
'@tailwindcss/oxide-linux-x64-musl':
|
|
|
|
|
specifier: workspace:*
|
|
|
|
|
version: link:npm/linux-x64-musl
|
2025-04-11 17:19:55 +02:00
|
|
|
'@tailwindcss/oxide-wasm32-wasi':
|
|
|
|
|
specifier: workspace:*
|
|
|
|
|
version: link:npm/wasm32-wasi
|
2024-10-30 12:26:29 +01:00
|
|
|
'@tailwindcss/oxide-win32-arm64-msvc':
|
|
|
|
|
specifier: workspace:*
|
|
|
|
|
version: link:npm/win32-arm64-msvc
|
2024-03-05 14:23:26 +01:00
|
|
|
'@tailwindcss/oxide-win32-x64-msvc':
|
|
|
|
|
specifier: workspace:*
|
|
|
|
|
version: link:npm/win32-x64-msvc
|
|
|
|
|
|
2024-03-23 14:00:48 +01:00
|
|
|
crates/node/npm/android-arm-eabi: {}
|
2024-03-08 20:08:24 +03:00
|
|
|
|
2024-03-23 14:00:48 +01:00
|
|
|
crates/node/npm/android-arm64: {}
|
2024-03-08 20:08:24 +03:00
|
|
|
|
2024-03-23 14:00:48 +01:00
|
|
|
crates/node/npm/darwin-arm64: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-03-23 14:00:48 +01:00
|
|
|
crates/node/npm/darwin-x64: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-03-23 14:00:48 +01:00
|
|
|
crates/node/npm/freebsd-x64: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-03-23 14:00:48 +01:00
|
|
|
crates/node/npm/linux-arm-gnueabihf: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-03-23 14:00:48 +01:00
|
|
|
crates/node/npm/linux-arm64-gnu: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-03-23 14:00:48 +01:00
|
|
|
crates/node/npm/linux-arm64-musl: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-03-23 14:00:48 +01:00
|
|
|
crates/node/npm/linux-x64-gnu: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-03-23 14:00:48 +01:00
|
|
|
crates/node/npm/linux-x64-musl: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2025-04-11 17:19:55 +02:00
|
|
|
crates/node/npm/wasm32-wasi:
|
|
|
|
|
dependencies:
|
|
|
|
|
'@emnapi/core':
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: ^1.11.3
|
|
|
|
|
version: 1.11.3
|
2025-04-11 17:19:55 +02:00
|
|
|
'@emnapi/runtime':
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: ^1.11.3
|
|
|
|
|
version: 1.11.3
|
2025-04-11 17:19:55 +02:00
|
|
|
'@emnapi/wasi-threads':
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: ^1.2.3
|
|
|
|
|
version: 1.2.3
|
2025-04-11 17:19:55 +02:00
|
|
|
'@napi-rs/wasm-runtime':
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: ^1.2.2
|
|
|
|
|
version: 1.2.2(@emnapi/core@1.11.3)(@emnapi/runtime@1.11.3)
|
2025-04-11 17:19:55 +02:00
|
|
|
'@tybys/wasm-util':
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: ^0.10.3
|
|
|
|
|
version: 0.10.3
|
2025-04-11 17:19:55 +02:00
|
|
|
tslib:
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
specifier: ^2.8.1
|
2025-09-19 17:08:41 +02:00
|
|
|
version: 2.8.1
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2024-10-30 12:26:29 +01:00
|
|
|
crates/node/npm/win32-arm64-msvc: {}
|
|
|
|
|
|
2024-03-23 14:00:48 +01:00
|
|
|
crates/node/npm/win32-x64-msvc: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
Add integration test setup and tests for the Vite integration (#14089)
This PR adds a new root `/integrations` folder that will be the home of
integration tests. The idea of these tests is to use Tailwind in various
setups just like our users would (by only using the publishable npm
builds).
To avoid issues with concurrent tests making changes to the file system,
to make it very easy to test through a range of versions, and to avoid
changing configuration objects over and over in test runs, we decided to
inline the scaffolding completely into the test file and have no
examples checked into the repo.
Here's an example of how this can look like for a simple Vite test:
```ts
test('works with production builds', {
fs: {
'package.json': json`
{
"type": "module",
"dependencies": {
"@tailwindcss/vite": "workspace:^",
"tailwindcss": "workspace:^"
},
"devDependencies": {
"vite": "^5.3.5"
}
}
`,
'vite.config.ts': ts`
import tailwindcss from '@tailwindcss/vite'
import { defineConfig } from 'vite'
export default defineConfig({
build: { cssMinify: false },
plugins: [tailwindcss()],
})
`,
'index.html': html`
<head>
<link rel="stylesheet" href="./src/index.css">
</head>
<body>
<div class="underline m-2">Hello, world!</div>
</body>
`,
'src/index.css': css`
@import 'tailwindcss/theme' reference;
@import 'tailwindcss/utilities';
`,
},
},
async ({ fs, exec }) => {
await exec('pnpm vite build')
expect.assertions(2)
for (let [path, content] of await fs.glob('dist/**/*.css')) {
expect(path).toMatch(/\.css$/)
expect(stripTailwindComment(content)).toMatchInlineSnapshot(
`
".m-2 {
margin: var(--spacing-2, .5rem);
}
.underline {
text-decoration-line: underline;
}"
`,
)
}
},
)
```
By defining all dependencies this way, we never have to worry about
which fixtures are checked in and can more easily describe changes to
the setup.
For ergonomics, we've also added the [`embed` prettier
plugin](https://github.com/Sec-ant/prettier-plugin-embed). This will
mean that files inlined in the `fs` setup are properly indented. No
extra work needed!
If you're using VS Code, I can also recommend the [Language
Literals](https://marketplace.visualstudio.com/items?itemName=sissel.language-literals)
extension so that syntax highlighting also _just works_.
A neat feature of inlining the scaffolding like this is to make it very
simple to test through a variety of versions. For example, here's how we
can set up a test against Vite 5 and Vite 4:
```js
;['^4.5.3', '^5.3.5'].forEach(viteVersion => {
test(`works with production builds for Vite ${viteVersion}`, {
fs: {
'package.json': json`
{
"type": "module",
"devDependencies": {
"vite": "${viteVersion}"
}
}
`,
async () => {
// Do something
},
)
})
```
## Philosophy
Before we dive into the specifics, I want to clearly state the design
considerations we have chosen for this new test suite:
- All file mutations should be done in temp folders, nothing should ever
mess with your working directory
- Windows as a first-class citizen
- Have a clean and simple API that describes the test setup only using
public APIs
- Focus on reliability (make sure cleanup scripts work and are tolerant
to various error scenarios)
- If a user reports an issue with a specific configuration, we want to
be able to reproduce them with integration tests, no matter how obscure
the setup (this means the test need to be in control of most of the
variables)
- Tests should be reasonably fast (obviously this depends on the
integration. If we use a slow build tool, we can't magically speed it
up, but our overhead should be minimal).
## How it works
The current implementation provides a custom `test` helper function
that, when used, sets up the environment according to the configuration.
It'll create a new temporary directory and create all files, ensuring
things like proper `\r\n` line endings on Windows.
We do have to patch the `package.json` specifically, since we can not
use public versions of the tailwindcss packages as we want to be able to
test against a development build. To make this happen, every `pnpm
build` run now creates tarballs of the npm modules (that contain only
the files that would also in the published build). We then patch the
`package.json` to rewrite `workspace:^` versions to link to those
tarballs. We found this to work reliably on Windows and macOS as well as
being fast enough to not cause any issues. Furthermore we also decided
to use `pnpm` as the version manager for integration tests because of
it's global module cache (so installing `vite` is fast as soon as you
installed it once).
The test function will receive a few utilities that it can use to more
easily interact with the temp dir. One example is a `fs.glob` function
that you can use to easily find files in eventual `dist/` directories or
helpers around `spawn` and `exec` that make sure that processes are
cleaned up correctly.
Because we use tarballs from our build dependencies, working on changes
requires a workflow where you run `pnpm build` before running `pnpm
test:integrations`. However it also means we can run clients like our
CLI client with no additional overhead—just install the dependency like
any user would and set up your test cases this way.
## Test plan
This PR also includes two Vite specific integration tests: One testing a
static build (`pnpm vite build`) and one a dev mode build (`pnpm vite
dev`) that also makes changes to the file system and asserts that the
resources properly update.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-08-02 11:50:49 +02:00
|
|
|
integrations:
|
|
|
|
|
devDependencies:
|
|
|
|
|
dedent:
|
2026-05-21 17:58:55 +02:00
|
|
|
specifier: 'catalog:'
|
|
|
|
|
version: 1.7.2
|
Add integration test setup and tests for the Vite integration (#14089)
This PR adds a new root `/integrations` folder that will be the home of
integration tests. The idea of these tests is to use Tailwind in various
setups just like our users would (by only using the publishable npm
builds).
To avoid issues with concurrent tests making changes to the file system,
to make it very easy to test through a range of versions, and to avoid
changing configuration objects over and over in test runs, we decided to
inline the scaffolding completely into the test file and have no
examples checked into the repo.
Here's an example of how this can look like for a simple Vite test:
```ts
test('works with production builds', {
fs: {
'package.json': json`
{
"type": "module",
"dependencies": {
"@tailwindcss/vite": "workspace:^",
"tailwindcss": "workspace:^"
},
"devDependencies": {
"vite": "^5.3.5"
}
}
`,
'vite.config.ts': ts`
import tailwindcss from '@tailwindcss/vite'
import { defineConfig } from 'vite'
export default defineConfig({
build: { cssMinify: false },
plugins: [tailwindcss()],
})
`,
'index.html': html`
<head>
<link rel="stylesheet" href="./src/index.css">
</head>
<body>
<div class="underline m-2">Hello, world!</div>
</body>
`,
'src/index.css': css`
@import 'tailwindcss/theme' reference;
@import 'tailwindcss/utilities';
`,
},
},
async ({ fs, exec }) => {
await exec('pnpm vite build')
expect.assertions(2)
for (let [path, content] of await fs.glob('dist/**/*.css')) {
expect(path).toMatch(/\.css$/)
expect(stripTailwindComment(content)).toMatchInlineSnapshot(
`
".m-2 {
margin: var(--spacing-2, .5rem);
}
.underline {
text-decoration-line: underline;
}"
`,
)
}
},
)
```
By defining all dependencies this way, we never have to worry about
which fixtures are checked in and can more easily describe changes to
the setup.
For ergonomics, we've also added the [`embed` prettier
plugin](https://github.com/Sec-ant/prettier-plugin-embed). This will
mean that files inlined in the `fs` setup are properly indented. No
extra work needed!
If you're using VS Code, I can also recommend the [Language
Literals](https://marketplace.visualstudio.com/items?itemName=sissel.language-literals)
extension so that syntax highlighting also _just works_.
A neat feature of inlining the scaffolding like this is to make it very
simple to test through a variety of versions. For example, here's how we
can set up a test against Vite 5 and Vite 4:
```js
;['^4.5.3', '^5.3.5'].forEach(viteVersion => {
test(`works with production builds for Vite ${viteVersion}`, {
fs: {
'package.json': json`
{
"type": "module",
"devDependencies": {
"vite": "${viteVersion}"
}
}
`,
async () => {
// Do something
},
)
})
```
## Philosophy
Before we dive into the specifics, I want to clearly state the design
considerations we have chosen for this new test suite:
- All file mutations should be done in temp folders, nothing should ever
mess with your working directory
- Windows as a first-class citizen
- Have a clean and simple API that describes the test setup only using
public APIs
- Focus on reliability (make sure cleanup scripts work and are tolerant
to various error scenarios)
- If a user reports an issue with a specific configuration, we want to
be able to reproduce them with integration tests, no matter how obscure
the setup (this means the test need to be in control of most of the
variables)
- Tests should be reasonably fast (obviously this depends on the
integration. If we use a slow build tool, we can't magically speed it
up, but our overhead should be minimal).
## How it works
The current implementation provides a custom `test` helper function
that, when used, sets up the environment according to the configuration.
It'll create a new temporary directory and create all files, ensuring
things like proper `\r\n` line endings on Windows.
We do have to patch the `package.json` specifically, since we can not
use public versions of the tailwindcss packages as we want to be able to
test against a development build. To make this happen, every `pnpm
build` run now creates tarballs of the npm modules (that contain only
the files that would also in the published build). We then patch the
`package.json` to rewrite `workspace:^` versions to link to those
tarballs. We found this to work reliably on Windows and macOS as well as
being fast enough to not cause any issues. Furthermore we also decided
to use `pnpm` as the version manager for integration tests because of
it's global module cache (so installing `vite` is fast as soon as you
installed it once).
The test function will receive a few utilities that it can use to more
easily interact with the temp dir. One example is a `fs.glob` function
that you can use to easily find files in eventual `dist/` directories or
helpers around `spawn` and `exec` that make sure that processes are
cleaned up correctly.
Because we use tarballs from our build dependencies, working on changes
requires a workflow where you run `pnpm build` before running `pnpm
test:integrations`. However it also means we can run clients like our
CLI client with no additional overhead—just install the dependency like
any user would and set up your test cases this way.
## Test plan
This PR also includes two Vite specific integration tests: One testing a
static build (`pnpm vite build`) and one a dev mode build (`pnpm vite
dev`) that also makes changes to the file system and asserts that the
resources properly update.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-08-02 11:50:49 +02:00
|
|
|
fast-glob:
|
2025-01-13 11:11:35 +01:00
|
|
|
specifier: ^3.3.3
|
|
|
|
|
version: 3.3.3
|
Add support for source maps (#17775)
Closes #13694
Closes #13591
# Source Maps Support for Tailwind CSS
This PR adds support for source maps to Tailwind CSS v4 allowing us to
track where styles come from whether that be user CSS, imported
stylesheets, or generated utilities. This will improve debuggability in
browser dev tools and gives us a good foundation for producing better
error messages. I'll go over the details on how end users can enable
source maps, any limitations in our implementation, changes to the
internal `compile(…)` API, and some details and reasoning around the
implementation we chose.
## Usage
### CLI
Source maps can be enabled in the CLI by using the command line argument
`--map` which will generate an inline source map comment at the bottom
of your CSS. A separate file may be generated by passing a file name to
`--map`:
```bash
# Generates an inline source map
npx tailwindcss -i input.css -o output.css --map
# Generates a separate source map file
npx tailwindcss -i input.css -o output.css --map output.css.map
```
### PostCSS
Source maps are supported when using Tailwind as a PostCSS plugin *in
development mode only*. They may or may not be enabled by default
depending on your build tool. If they are not you may be able to
configure them within your PostCSS config:
```jsonc
// package.json
{
// …
"postcss": {
"map": { "inline": true },
"plugins": {
"@tailwindcss/postcss": {},
},
}
}
```
### Vite
Source maps are supported when using the Tailwind CSS Vite plugin in
*development mode only* by enabling the `css.devSourcemap` setting:
```js
import tailwindcss from "@tailwindcss/vite";
import { defineConfig } from "vite";
export default defineConfig({
plugins: [tailwindcss()],
css: {
devSourcemap: true,
},
})
```
Now when a CSS file is requested by the browser it'll have an inline
source map comment that the browser can use.
## Limitations
- Production build source maps are currently disabled due to a bug in
Lightning CSS. See
https://github.com/parcel-bundler/lightningcss/pull/971 for more
details.
- In Vite, minified CSS build source maps are not supported at all. See
https://github.com/vitejs/vite/issues/2830 for more details.
- In PostCSS, minified CSS source maps are not supported. This is due to
the complexity required around re-associating every AST node with a
location in the generated, optimized CSS. This complexity would also
have a non-trivial performance impact.
## Testing
Here's how to test the source map functionality in different
environments:
### Testing the CLI
1. Setup typical project that the CLI can use and with sources to scan.
```css
@import "tailwindcss";
@utilty my-custom-utility {
color: red;
}
/* to test `@apply` */
.card {
@apply bg-white text-center shadow-md;
}
```
2. Build with source maps:
```bash
bun /path/to/tailwindcss/packages/@tailwindcss-cli/src/index.ts --input input.css -o output.css --map
```
3. Open Chrome DevTools, inspect an element with utility classes, and
you should see rules pointing to `input.css` or
`node_modules/tailwindcss/index.css`
### Testing with Vite
Testing in Vite will require building and installing necessary files
under `dist/*.tgz`.
1. Create a Vite project and enable source maps in `vite.config.js`:
```js
import tailwindcss from "@tailwindcss/vite";
import { defineConfig } from "vite";
export default defineConfig({
plugins: [tailwindcss()],
css: {
// This line is required for them to work
devSourcemap: true,
},
})
```
2. Add a component that uses Tailwind classes and custom CSS:
```jsx
// ./src/app.jsx
export default function App() {
return (
<div className="bg-blue-500 my-custom-class">
Hello World
</div>
)
}
```
```css
/* ./src/styles.css */
@import "tailwindcss";
@utilty my-custom-utility {
color: red;
}
/* to test `@apply` */
.card {
@apply bg-white text-center shadow-md;
}
```
3. Run `npm run dev`, open DevTools, and inspect elements to verify
source mapping works for both utility classes and custom CSS.
### Testing with PostCSS CLI
1. Create a test file and update your PostCSS config:
```css
/* input.css */
@import "tailwindcss";
@layer components {
.card {
@apply p-6 rounded-lg shadow-lg;
}
}
```
```jsonc
// package.json
{
// …
"postcss": {
"map": {
"inline": true
},
"plugins": {
"/path/to/tailwindcss/packages/packages/@tailwindcss-postcss/src/index.ts": {}
}
}
}
```
2. Run PostCSS through Bun:
```bash
bunx --bun postcss ./src/index.css -o out.css
```
3. Inspect the output CSS - it should include an inline source map
comment at the bottom.
### Testing with PostCSS + Next.js
Testing in Next.js will require building and installing necessary files
under `dist/*.tgz`. However, I've not been able to get CSS source maps
to work in Next.js without this hack:
```js
const nextConfig: NextConfig = {
// next.js overwrites config.devtool so we prevent it from doing so
// please don't actually do this…
webpack: (config) =>
Object.defineProperty(config, "devtool", {
get: () => "inline-source-map",
set: () => {},
}),
};
```
This is definitely not supported and also doesn't work with turbopack.
This can be used to test them temporarily but I suspect that they just
don't work there.
### Manual source map analysis
You can analyze source maps using Evan Wallace's [Source Map
Visualization](https://evanw.github.io/source-map-visualization/) tool
which will help to verify the accuracy and quality of source maps. This
is what I used extensively while developing this implementation.
It'll help verify that custom, user CSS maps back to itself in the
input, that generated utilities all map back to `@tailwind utilities;`,
that source locations from imported files are also handled correctly,
etc… It also highlights the ranges of stuff so it's easy to see if there
are off-by-one errors.
It's easiest to use inline source maps with this tool because you can
take the CSS file and drop it on the page and it'll analyze it while
showing the file content.
If you're using Vite you'll want to access the CSS file with `?direct`
at the end so you don't get a JS module back.
## Implementation
The source map implementation follows the ECMA-426 specification and
includes several key components to aid in that goal:
### Source Location Tracking
Each emittable AST node in the compilation pipeline tracks two types of
source locations:
- `src`: Original source location - [source file, start offset, end
offset]
- `dst`: Generated source location - [output file, start offset, end
offset]
This dual tracking allows us to maintain mappings between the original
source and generated output for things like user CSS, generated
utilities, uses of `@apply`, and tracking theme variables.
It is important to note that source locations for nodes _never overlap_
within a file which helps simplify source map generation. As such each
type of node tracks a specific piece of itself rather than its entire
"block":
| Node | What a `SourceLocation` represents |
| ----------- |
---------------------------------------------------------------- |
| Style Rule | The selector |
| At Rule | Rule name and params, includes the `@` |
| Declaration | Property name and value, excludes the semicolon |
| Comment | The entire comment, includes the start `/*` and end `*/`
markers |
### Windows line endings when parsing CSS
Because our AST tracks nodes through offsets we must ensure that any
mutations to the file do *not* change the lenth of the string. We were
previously replacing `\r\n` with `\n` (see [filter code
points](https://drafts.csswg.org/css-syntax/#css-filter-code-points)
from the spec) — which changes the length of the string and all offsets
may end up incorrect. The CSS parser was updated to handle the CRLF
token directly by skipping over the `\r` and letting remaining code
handle `\n` as it did previously. Some additional tweaks were required
when "peeking" the input but those changes were fairly small.
### Tracking of imports
Source maps need paths to the actual imported stylesheets but the
resolve step for stylesheets happens inside the call to `loadStylesheet`
which make the file path unavailable to us. Because of this the
`loadStylesheet` API was augmented such that it has to return a `path`
property that we can then use to identify imported sources. I've also
made the same change to the `loadModule` API for consistency but nothing
currently uses this property.
The `path` property likely makes `base` redundant but elminating that
(if we even want to) is a future task.
### Optimizing the AST
Our optimization pass may intoduce some nodes, for example, fallbacks we
create for `@property`. These nodes are linked back to `@tailwind
utilities` as ultimately that is what is responsible for creating them.
### Line Offset Tables
A key component to our source map generation is the line offset table,
which was inspired by some ESBuild internals. It stores a sorted list of
offsets for the start of each line allowing us to translate offsets to
line/column `Position`s in `O(log N)` time and from `Position`s to
offsets in `O(1)` time. Creation of the table takes `O(N)` time.
This means that we can store code point offsets for source locations and
not have to worry about computing or tracking line/column numbers during
parsing and serialization. Only when a source map is generated do these
offsets need to be computed. This ensures the performance penalty when
not using source maps is minimal.
### Source Map Generation
The source map returned by `buildSourceMap()` is designed to follow the
[ECMA-426 spec](https://tc39.es/ecma426). Because that spec is not
completely finalized we consider the result of `buildSourceMap()` to be
internal API that may change as the spec chamges.
The produces source map is a "decoded" map such that all sources and
mappings are in an object graph. A library like `source-map-js` must be
used to convert this to an encoded source map of the right version where
mappings are encoded with base 64 VLQs.
Any specific integration (Vite, PostCSS, etc…) can then use
`toSourceMap()` from `@tailwindcss/node` to convert from the internal
source map to an spec-compliant encoded source map that can be
understood by other tools.
### Handling minification in Lightning
Since we use Lightning CSS for optimization, and it takes in an input
map, we generate an encoded source map that we then pass to lightning.
The output source map *from lighting itself* is then passed back in
during the second optimization pass. The final map is then passed from
lightning to the CLI (but not Vite or PostCSS — see the limitations
section for details).
In some cases we have to "fix up" the output CSS. When this happens we
use `magic-string` to do the replacement in a way that is trackable and
`@amppproject/remapping` to map that change back onto the original
source map. Once the need for these fix ups disappear these dependencies
can go away.
Notes:
- The accuracy of source maps run though lightning is reduced as it only
tracks on a per-rule level. This is sufficient enough for browser dev
tools so should be fine.
- Source maps during optimization do not function properly at this time
because of a bug in Lightning CSS regarding license comments. Once this
bug is fixed they will start working as expected.
### How source locations flow through the system
1. During initial CSS parsing, source locations are preserved.
2. During parsing these source locations are also mapped to the
destinations which supports an optimization for when no utilities are
generated.
3. Throughout the compilation process, transformations maintain source
location data
4. Generated utilities are explicitly pointed to `@tailwind utilities`
unless generated by `@apply`.
5. When optimization is enabled, source maps are remapped through
lightningcss
6. Final source maps are written in the requested format (inline or
separate file)
2025-05-08 16:29:49 -04:00
|
|
|
source-map-js:
|
|
|
|
|
specifier: ^1.2.1
|
|
|
|
|
version: 1.2.1
|
2026-06-25 19:14:10 +02:00
|
|
|
yaml:
|
|
|
|
|
specifier: ^2.9.0
|
|
|
|
|
version: 2.9.0
|
Add integration test setup and tests for the Vite integration (#14089)
This PR adds a new root `/integrations` folder that will be the home of
integration tests. The idea of these tests is to use Tailwind in various
setups just like our users would (by only using the publishable npm
builds).
To avoid issues with concurrent tests making changes to the file system,
to make it very easy to test through a range of versions, and to avoid
changing configuration objects over and over in test runs, we decided to
inline the scaffolding completely into the test file and have no
examples checked into the repo.
Here's an example of how this can look like for a simple Vite test:
```ts
test('works with production builds', {
fs: {
'package.json': json`
{
"type": "module",
"dependencies": {
"@tailwindcss/vite": "workspace:^",
"tailwindcss": "workspace:^"
},
"devDependencies": {
"vite": "^5.3.5"
}
}
`,
'vite.config.ts': ts`
import tailwindcss from '@tailwindcss/vite'
import { defineConfig } from 'vite'
export default defineConfig({
build: { cssMinify: false },
plugins: [tailwindcss()],
})
`,
'index.html': html`
<head>
<link rel="stylesheet" href="./src/index.css">
</head>
<body>
<div class="underline m-2">Hello, world!</div>
</body>
`,
'src/index.css': css`
@import 'tailwindcss/theme' reference;
@import 'tailwindcss/utilities';
`,
},
},
async ({ fs, exec }) => {
await exec('pnpm vite build')
expect.assertions(2)
for (let [path, content] of await fs.glob('dist/**/*.css')) {
expect(path).toMatch(/\.css$/)
expect(stripTailwindComment(content)).toMatchInlineSnapshot(
`
".m-2 {
margin: var(--spacing-2, .5rem);
}
.underline {
text-decoration-line: underline;
}"
`,
)
}
},
)
```
By defining all dependencies this way, we never have to worry about
which fixtures are checked in and can more easily describe changes to
the setup.
For ergonomics, we've also added the [`embed` prettier
plugin](https://github.com/Sec-ant/prettier-plugin-embed). This will
mean that files inlined in the `fs` setup are properly indented. No
extra work needed!
If you're using VS Code, I can also recommend the [Language
Literals](https://marketplace.visualstudio.com/items?itemName=sissel.language-literals)
extension so that syntax highlighting also _just works_.
A neat feature of inlining the scaffolding like this is to make it very
simple to test through a variety of versions. For example, here's how we
can set up a test against Vite 5 and Vite 4:
```js
;['^4.5.3', '^5.3.5'].forEach(viteVersion => {
test(`works with production builds for Vite ${viteVersion}`, {
fs: {
'package.json': json`
{
"type": "module",
"devDependencies": {
"vite": "${viteVersion}"
}
}
`,
async () => {
// Do something
},
)
})
```
## Philosophy
Before we dive into the specifics, I want to clearly state the design
considerations we have chosen for this new test suite:
- All file mutations should be done in temp folders, nothing should ever
mess with your working directory
- Windows as a first-class citizen
- Have a clean and simple API that describes the test setup only using
public APIs
- Focus on reliability (make sure cleanup scripts work and are tolerant
to various error scenarios)
- If a user reports an issue with a specific configuration, we want to
be able to reproduce them with integration tests, no matter how obscure
the setup (this means the test need to be in control of most of the
variables)
- Tests should be reasonably fast (obviously this depends on the
integration. If we use a slow build tool, we can't magically speed it
up, but our overhead should be minimal).
## How it works
The current implementation provides a custom `test` helper function
that, when used, sets up the environment according to the configuration.
It'll create a new temporary directory and create all files, ensuring
things like proper `\r\n` line endings on Windows.
We do have to patch the `package.json` specifically, since we can not
use public versions of the tailwindcss packages as we want to be able to
test against a development build. To make this happen, every `pnpm
build` run now creates tarballs of the npm modules (that contain only
the files that would also in the published build). We then patch the
`package.json` to rewrite `workspace:^` versions to link to those
tarballs. We found this to work reliably on Windows and macOS as well as
being fast enough to not cause any issues. Furthermore we also decided
to use `pnpm` as the version manager for integration tests because of
it's global module cache (so installing `vite` is fast as soon as you
installed it once).
The test function will receive a few utilities that it can use to more
easily interact with the temp dir. One example is a `fs.glob` function
that you can use to easily find files in eventual `dist/` directories or
helpers around `spawn` and `exec` that make sure that processes are
cleaned up correctly.
Because we use tarballs from our build dependencies, working on changes
requires a workflow where you run `pnpm build` before running `pnpm
test:integrations`. However it also means we can run clients like our
CLI client with no additional overhead—just install the dependency like
any user would and set up your test cases this way.
## Test plan
This PR also includes two Vite specific integration tests: One testing a
static build (`pnpm vite build`) and one a dev mode build (`pnpm vite
dev`) that also makes changes to the file system and asserts that the
resources properly update.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-08-02 11:50:49 +02:00
|
|
|
|
2025-01-07 09:57:34 -05:00
|
|
|
packages/@tailwindcss-browser:
|
|
|
|
|
devDependencies:
|
|
|
|
|
h3:
|
2026-04-24 21:21:12 +02:00
|
|
|
specifier: ^1.15.11
|
|
|
|
|
version: 1.15.11
|
2025-01-07 09:57:34 -05:00
|
|
|
listhen:
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: ^1.10.1
|
|
|
|
|
version: 1.10.1(@parcel/watcher@2.6.0(patch_hash=705ce75ccea54337110c4d7fe0a8b421658ea0c23e1a77c1fa890a86041179da))
|
2025-01-07 09:57:34 -05:00
|
|
|
tailwindcss:
|
|
|
|
|
specifier: workspace:*
|
|
|
|
|
version: link:../tailwindcss
|
|
|
|
|
|
2024-03-06 11:41:12 +01:00
|
|
|
packages/@tailwindcss-cli:
|
|
|
|
|
dependencies:
|
|
|
|
|
'@parcel/watcher':
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: 'catalog:'
|
|
|
|
|
version: 2.6.0(patch_hash=705ce75ccea54337110c4d7fe0a8b421658ea0c23e1a77c1fa890a86041179da)
|
2024-09-02 12:03:16 -04:00
|
|
|
'@tailwindcss/node':
|
2025-02-18 11:44:12 +01:00
|
|
|
specifier: workspace:*
|
2024-09-02 12:03:16 -04:00
|
|
|
version: link:../@tailwindcss-node
|
2024-03-06 11:41:12 +01:00
|
|
|
'@tailwindcss/oxide':
|
2025-02-18 11:44:12 +01:00
|
|
|
specifier: workspace:*
|
2024-03-23 14:00:48 +01:00
|
|
|
version: link:../../crates/node
|
2024-09-02 15:23:46 +02:00
|
|
|
enhanced-resolve:
|
2026-05-21 17:58:55 +02:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 5.24.5
|
2024-03-06 11:41:12 +01:00
|
|
|
mri:
|
|
|
|
|
specifier: ^1.2.0
|
|
|
|
|
version: 1.2.0
|
|
|
|
|
picocolors:
|
2024-10-24 11:25:50 +02:00
|
|
|
specifier: ^1.1.1
|
|
|
|
|
version: 1.1.1
|
2024-03-06 11:41:12 +01:00
|
|
|
tailwindcss:
|
Ensure clients pin the `tailwindcss` version (#15011)
We noticed that in the current alpha 34 release, the `package.json` file
of the `@tailwindcss/node` package only defines `tailwindcss` as a dev
dependency. This makes it very easy for version mismatches to happen
when a v3 version (or an earlier v4 alpha for that matter) was installed
in the same project:
```json
{
"name": "@tailwindcss/node",
"version": "4.0.0-alpha.34",
"description": "A utility-first CSS framework for rapidly building custom user interfaces.",
"license": "MIT",
"repository": {
"type": "git",
"url": "https://github.com/tailwindlabs/tailwindcss.git",
"directory": "packages/@tailwindcss-node"
},
"bugs": "https://github.com/tailwindlabs/tailwindcss/issues",
"homepage": "https://tailwindcss.com",
"files": [
"dist/"
],
"publishConfig": {
"provenance": true,
"access": "public"
},
"exports": {
".": {
"types": "./dist/index.d.ts",
"import": "./dist/index.mjs",
"require": "./dist/index.js"
},
"./require-cache": {
"types": "./dist/require-cache.d.ts",
"default": "./dist/require-cache.js"
},
"./esm-cache-loader": {
"types": "./dist/esm-cache.loader.d.mts",
"default": "./dist/esm-cache.loader.mjs"
}
},
"devDependencies": {
"tailwindcss": "4.0.0-alpha.34"
},
"dependencies": {
"enhanced-resolve": "^5.17.1",
"jiti": "^2.0.0-beta.3"
},
"scripts": {
"build": "tsup-node",
"dev": "pnpm run build -- --watch"
}
}
```
Furthermore, we were trying to fix issues where our integration test
setup could not install `tailwindcss@3` because of how we did pnpm
overrides.
This PR fixes this by:
- Ensuring every client that calls into `tailwindcss` core marks it as a
version-pinned dependency. You are still required to install
`tailwindcss` in your project along side a client (e.g.
`@tailwindcss/vite`) but we now only use your installed version for
importing the respective `.css` files. For the core logic, we are now
requiring each package to use `tailwindcss` at the same version. This
should help resolve issues like
https://github.com/tailwindlabs/tailwindcss/discussions/14652
- We tried to eliminate the dependency on `tailwindcss` from the
`@tailwindcss/upgrade` package. Unfortunately this is not possible to do
right now because we need to load the CSS files from v4 to create the
right environment. In a future version we could bundle the required CSS
files with `@tailwidncss/upgrade` but it doesn't seem necessary for now.
- We then changed our integration test overrides to only override the
`tailwindcss` package that are dependencies of the known list of
packages that we have `tailwindcss` dependencies on: `@tailwindcss/node`
and `@tailwindcss/upgrade`. This ensures that we can install v3 of
`tailwindcss` in the integration tests and it will work. Something we
want to do for some upgrade tests.
# Test plan
Integration work again. Furthermore we added a quick setup with the CLI
using the local tarballs and ensured it works:
```bash
pnpm init
pnpm install ../../tailwindcss/dist/tailwindcss-cli.tgz
pnpm install ../../tailwindcss/dist/tailwindcss.tgz
echo '@import "tailwindcss";' > index.css
echo '<div class="underline"></div>' > index.html
pnpm tailwindcss -i index.css -o out.css
cat out.css
```
2024-11-15 17:18:48 +01:00
|
|
|
specifier: workspace:*
|
2024-03-06 11:41:12 +01:00
|
|
|
version: link:../tailwindcss
|
|
|
|
|
|
2024-09-02 12:03:16 -04:00
|
|
|
packages/@tailwindcss-node:
|
2024-09-03 18:35:39 +02:00
|
|
|
dependencies:
|
2025-08-12 15:52:35 +02:00
|
|
|
'@jridgewell/remapping':
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
specifier: ^2.3.5
|
2025-08-12 15:52:35 +02:00
|
|
|
version: 2.3.5
|
Resolve `@import` in core (#14446)
This PR brings `@import` resolution into Tailwind CSS core. This means
that our clients (PostCSS, Vite, and CLI) no longer need to depend on
`postcss` and `postcss-import` to resolve `@import`. Furthermore this
simplifies the handling of relative paths for `@source`, `@plugin`, or
`@config` in transitive CSS files (where the relative root should always
be relative to the CSS file that contains the directive). This PR also
fixes a plugin resolution bug where non-relative imports (e.g. directly
importing node modules like `@plugin '@tailwindcss/typography';`) would
not work in CSS files that are based in a different npm package.
### Resolving `@import`
The core of the `@import` resolution is inside
`packages/tailwindcss/src/at-import.ts`. There, to keep things
performant, we do a two-step process to resolve imports. Imagine the
following input CSS file:
```css
@import "tailwindcss/theme.css";
@import "tailwindcss/utilities.css";
```
Since our AST walks are synchronous, we will do a first traversal where
we start a loading request for each `@import` directive. Once all loads
are started, we will await the promise and do a second walk where we
actually replace the AST nodes with their resolved stylesheets. All of
this is recursive, so that `@import`-ed files can again `@import` other
files.
The core `@import` resolver also includes extensive test cases for
[various combinations of media query and supports conditionals as well
als layered
imports](https://developer.mozilla.org/en-US/docs/Web/CSS/@import).
When the same file is imported multiple times, the AST nodes are
duplicated but duplicate I/O is avoided on a per-file basis, so this
will only load one file, but include the `@theme` rules twice:
```css
@import "tailwindcss/theme.css";
@import "tailwindcss/theme.css";
```
### Adding a new `context` node to the AST
One limitation we had when working with the `postcss-import` plugin was
the need to do an additional traversal to rewrite relative `@source`,
`@plugin`, and `@config` directives. This was needed because we want
these paths to be relative to the CSS file that defines the directive
but when flattening a CSS file, this information is no longer part of
the stringifed CSS representation. We worked around this by rewriting
the content of these directives to be relative to the input CSS file,
which resulted in added complexity and caused a lot of issues with
Windows paths in the beginning.
Now that we are doing the `@import` resolution in core, we can use a
different data structure to persist this information. This PR adds a new
`context` node so that we can store arbitrary context like this inside
the Ast directly. This allows us to share information with the sub tree
_while doing the Ast walk_.
Here's an example of how the new `context` node can be used to share
information with subtrees:
```ts
const ast = [
rule('.foo', [decl('color', 'red')]),
context({ value: 'a' }, [
rule('.bar', [
decl('color', 'blue'),
context({ value: 'b' }, [
rule('.baz', [decl('color', 'green')]),
]),
]),
]),
]
walk(ast, (node, { context }) => {
if (node.kind !== 'declaration') return
switch (node.value) {
case 'red': assert(context.value === undefined)
case 'blue': assert(context.value === 'a')
case 'green': assert(context.value === 'b')
}
})
```
In core, we use this new Ast node specifically to persist the `base`
path of the current CSS file. We put the input CSS file `base` at the
root of the Ast and then overwrite the `base` on every `@import`
substitution.
### Removing the dependency on `postcss-import`
Now that we support `@import` resolution in core, our clients no longer
need a dependency on `postcss-import`. Furthermore, most dependencies
also don't need to know about `postcss` at all anymore (except the
PostCSS client, of course!).
This also means that our workaround for rewriting `@source`, the
`postcss-fix-relative-paths` plugin, can now go away as a shared
dependency between all of our clients. Note that we still have it for
the PostCSS plugin only, where it's possible that users already have
`postcss-import` running _before_ the `@tailwindcss/postcss` plugin.
Here's an example of the changes to the dependencies for our Vite client
✨ :
<img width="854" alt="Screenshot 2024-09-19 at 16 59 45"
src="https://github.com/user-attachments/assets/ae1f9d5f-d93a-4de9-9244-61af3aff1237">
### Performance
Since our Vite and CLI clients now no longer need to use `postcss` at
all, we have also measured a significant improvement to the initial
build times. For a small test setup that contains only a hand full of
files (nothing super-complex), we measured an improvement in the
**3.5x** range:
<img width="1334" alt="Screenshot 2024-09-19 at 14 52 49"
src="https://github.com/user-attachments/assets/06071fb0-7f2a-4de6-8ec8-f202d2cc78e5">
The code for this is in the commit history if you want to reproduce the
results. The test was based on the Vite client.
### Caveats
One thing to note is that we previously relied on finding specific
symbols in the input CSS to _bail out of Tailwind processing
completely_. E.g. if a file does not contain a `@tailwind` or `@apply`
directive, it can never be a Tailwind file.
Since we no longer have a string representation of the flattened CSS
file, we can no longer do this check. However, the current
implementation was already inconsistent with differences on the allowed
symbol list between our clients. Ideally, Tailwind CSS should figure out
wether a CSS file is a Tailwind CSS file. This, however, is left as an
improvement for a future API since it goes hand-in-hand with our planned
API changes for the core `tailwindcss` package.
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-09-23 17:05:55 +02:00
|
|
|
enhanced-resolve:
|
2026-05-21 17:58:55 +02:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 5.24.5
|
2024-09-03 18:35:39 +02:00
|
|
|
jiti:
|
2026-05-13 12:02:13 +02:00
|
|
|
specifier: ^2.7.0
|
|
|
|
|
version: 2.7.0
|
Improve compatibility with Safari 15 (#17435)
This PR improves the compatibility with Tailwind CSS v4 with unsupported
browsers with the goal to greatly improve compatibility with Safari 15.
To make this work, this PR makes the following changes to all code
- Change `oklab(…)` default theme values to use a percentage in the
first place (so instead of `--color-red-500: oklch(0.637 0.237 25.331);`
we now define it as `--color-red-500: oklch(63.7% 0.237 25.331);` since
this syntax has much broader support on Safari).
- Polyfill `@property` with a `@supports` query targeting older versions
of Safari and Firefox *
- Create fallbacks for the `color-mix(…)` function that use _inlined
color values from your theme_ so that they can be computed a compile
time by `lightningcss`. These fallbacks will convert to srgb to increase
compatibility.
- Create fallbacks for the _relative color_ feature used in the new
shadow utilities and using `color-mix(…)` in case _relative color_ is
applied on `currentcolor` (due to limited browser support)
- Create fallbacks for gradient interpolation methods (e.g. to support
`bg-linear-to-r/oklab`)
- Polyfill `@media` queries range syntax.
## A simplified example
Given this example CSS input:
```css
@import 'tailwindcss';
@source inline('from-cyan-500/50 bg-linear-45');
```
Here's the updated output CSS including the newly added polyfills and
updated `oklab` values:
```css
.bg-linear-45 {
--tw-gradient-position: 45deg;
background-image: linear-gradient(var(--tw-gradient-stops));
}
@supports (background-image: linear-gradient(in lab, red, red)) {
.bg-linear-45 {
--tw-gradient-position: 45deg in oklab;
}
}
.from-cyan-500\\/50 {
--tw-gradient-from: oklab(71.5% -.11682 -.08247 / .5);
--tw-gradient-stops: var(--tw-gradient-via-stops, var(--tw-gradient-position), var(--tw-gradient-from) var(--tw-gradient-from-position), var(--tw-gradient-to) var(--tw-gradient-to-position));
}
@supports (color: color-mix(in lab, red, red)) {
.from-cyan-500\\/50 {
--tw-gradient-from: color-mix(in oklab, var(--color-cyan-500) 50%, transparent);
}
}
:root, :host {
--color-cyan-500: oklch(71.5% .143 215.221);
}
@supports (((-webkit-hyphens: none)) and (not (margin-trim: 1lh))) or ((-moz-orient: inline) and (not (color: rgb(from red r g b)))) {
@layer base {
*, :before, :after, ::backdrop {
--tw-gradient-position: initial;
--tw-gradient-from: #0000;
--tw-gradient-via: #0000;
--tw-gradient-to: #0000;
--tw-gradient-stops: initial;
--tw-gradient-via-stops: initial;
--tw-gradient-from-position: 0%;
--tw-gradient-via-position: 50%;
--tw-gradient-to-position: 100%;
}
}
}
@property --tw-gradient-position {
syntax: "*";
inherits: false
}
@property --tw-gradient-from {
syntax: "<color>";
inherits: false;
initial-value: #0000;
}
@property --tw-gradient-via {
syntax: "<color>";
inherits: false;
initial-value: #0000;
}
@property --tw-gradient-to {
syntax: "<color>";
inherits: false;
initial-value: #0000;
}
@property --tw-gradient-stops {
syntax: "*";
inherits: false
}
@property --tw-gradient-via-stops {
syntax: "*";
inherits: false
}
@property --tw-gradient-from-position {
syntax: "<length-percentage>";
inherits: false;
initial-value: 0%;
}
@property --tw-gradient-via-position {
syntax: "<length-percentage>";
inherits: false;
initial-value: 50%;
}
@property --tw-gradient-to-position {
syntax: "<length-percentage>";
inherits: false;
initial-value: 100%;
}
```
## \* A note on `@property` polyfills and CSS modules
On Next.js, CSS module files are required to be _pure_, meaning that all
selectors must either be scoped to a class or an ID. Fortunatnyl for us,
this does not apply to `@property` rules which we've been using before
to initialize CSS variables.
However, since we're now bringing back the `@property` polyfills, that
would cause unexpected rules to be exported from the CSS file as this:
```css
@reference "tailwindcss";
.skew {
@apply skew-7;
}
```
Would turn to the following file:
```css
.skew {
/* … */
}
@supports (/*…*/) {
@layer base {
*, :before, :after, ::backdrop {
--tw-gradient-position: initial;
}
}
}
@property /* … */
```
Notice that this adds a `*` selector which is not considered pure.
Unfortunately there is no way for us to silence this warning or work
around it, as the dependency causing this errors
([`postcss-modules-local-by-default`](https://github.com/css-modules/postcss-modules-local-by-default))
is bundled into Next.js. To work around crashes, these polyfills will
not apply to CSS modules processed by the PostCSS extension for now.
## Testing on tailwindcss.com
To see the changes in effect, take a look at this screencast that
compares tailwindcss.com on iOS 15.5 with a version that has the patches
of this PR applied:
https://github.com/user-attachments/assets/1279d6f5-3c63-4f30-839c-198a789f4292
## Test plan
- Tested on tailwindcss.com via a preview build:
https://tailwindcss-com-git-legacy-browsers-tailwindlabs.vercel.app/
- Updated tests
- Ensure we also test on Chrome 111, Safari 16.4, Firefox 128 to
make sure we have no regressions. Also tested on Safari 16.4, 15.5, 18.0
2025-04-01 13:33:22 +02:00
|
|
|
lightningcss:
|
|
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 1.33.0(patch_hash=1d4a8800d60d13d42887b88b3a86576df4b451670308145fb432ec8abbf40930)
|
Add support for source maps (#17775)
Closes #13694
Closes #13591
# Source Maps Support for Tailwind CSS
This PR adds support for source maps to Tailwind CSS v4 allowing us to
track where styles come from whether that be user CSS, imported
stylesheets, or generated utilities. This will improve debuggability in
browser dev tools and gives us a good foundation for producing better
error messages. I'll go over the details on how end users can enable
source maps, any limitations in our implementation, changes to the
internal `compile(…)` API, and some details and reasoning around the
implementation we chose.
## Usage
### CLI
Source maps can be enabled in the CLI by using the command line argument
`--map` which will generate an inline source map comment at the bottom
of your CSS. A separate file may be generated by passing a file name to
`--map`:
```bash
# Generates an inline source map
npx tailwindcss -i input.css -o output.css --map
# Generates a separate source map file
npx tailwindcss -i input.css -o output.css --map output.css.map
```
### PostCSS
Source maps are supported when using Tailwind as a PostCSS plugin *in
development mode only*. They may or may not be enabled by default
depending on your build tool. If they are not you may be able to
configure them within your PostCSS config:
```jsonc
// package.json
{
// …
"postcss": {
"map": { "inline": true },
"plugins": {
"@tailwindcss/postcss": {},
},
}
}
```
### Vite
Source maps are supported when using the Tailwind CSS Vite plugin in
*development mode only* by enabling the `css.devSourcemap` setting:
```js
import tailwindcss from "@tailwindcss/vite";
import { defineConfig } from "vite";
export default defineConfig({
plugins: [tailwindcss()],
css: {
devSourcemap: true,
},
})
```
Now when a CSS file is requested by the browser it'll have an inline
source map comment that the browser can use.
## Limitations
- Production build source maps are currently disabled due to a bug in
Lightning CSS. See
https://github.com/parcel-bundler/lightningcss/pull/971 for more
details.
- In Vite, minified CSS build source maps are not supported at all. See
https://github.com/vitejs/vite/issues/2830 for more details.
- In PostCSS, minified CSS source maps are not supported. This is due to
the complexity required around re-associating every AST node with a
location in the generated, optimized CSS. This complexity would also
have a non-trivial performance impact.
## Testing
Here's how to test the source map functionality in different
environments:
### Testing the CLI
1. Setup typical project that the CLI can use and with sources to scan.
```css
@import "tailwindcss";
@utilty my-custom-utility {
color: red;
}
/* to test `@apply` */
.card {
@apply bg-white text-center shadow-md;
}
```
2. Build with source maps:
```bash
bun /path/to/tailwindcss/packages/@tailwindcss-cli/src/index.ts --input input.css -o output.css --map
```
3. Open Chrome DevTools, inspect an element with utility classes, and
you should see rules pointing to `input.css` or
`node_modules/tailwindcss/index.css`
### Testing with Vite
Testing in Vite will require building and installing necessary files
under `dist/*.tgz`.
1. Create a Vite project and enable source maps in `vite.config.js`:
```js
import tailwindcss from "@tailwindcss/vite";
import { defineConfig } from "vite";
export default defineConfig({
plugins: [tailwindcss()],
css: {
// This line is required for them to work
devSourcemap: true,
},
})
```
2. Add a component that uses Tailwind classes and custom CSS:
```jsx
// ./src/app.jsx
export default function App() {
return (
<div className="bg-blue-500 my-custom-class">
Hello World
</div>
)
}
```
```css
/* ./src/styles.css */
@import "tailwindcss";
@utilty my-custom-utility {
color: red;
}
/* to test `@apply` */
.card {
@apply bg-white text-center shadow-md;
}
```
3. Run `npm run dev`, open DevTools, and inspect elements to verify
source mapping works for both utility classes and custom CSS.
### Testing with PostCSS CLI
1. Create a test file and update your PostCSS config:
```css
/* input.css */
@import "tailwindcss";
@layer components {
.card {
@apply p-6 rounded-lg shadow-lg;
}
}
```
```jsonc
// package.json
{
// …
"postcss": {
"map": {
"inline": true
},
"plugins": {
"/path/to/tailwindcss/packages/packages/@tailwindcss-postcss/src/index.ts": {}
}
}
}
```
2. Run PostCSS through Bun:
```bash
bunx --bun postcss ./src/index.css -o out.css
```
3. Inspect the output CSS - it should include an inline source map
comment at the bottom.
### Testing with PostCSS + Next.js
Testing in Next.js will require building and installing necessary files
under `dist/*.tgz`. However, I've not been able to get CSS source maps
to work in Next.js without this hack:
```js
const nextConfig: NextConfig = {
// next.js overwrites config.devtool so we prevent it from doing so
// please don't actually do this…
webpack: (config) =>
Object.defineProperty(config, "devtool", {
get: () => "inline-source-map",
set: () => {},
}),
};
```
This is definitely not supported and also doesn't work with turbopack.
This can be used to test them temporarily but I suspect that they just
don't work there.
### Manual source map analysis
You can analyze source maps using Evan Wallace's [Source Map
Visualization](https://evanw.github.io/source-map-visualization/) tool
which will help to verify the accuracy and quality of source maps. This
is what I used extensively while developing this implementation.
It'll help verify that custom, user CSS maps back to itself in the
input, that generated utilities all map back to `@tailwind utilities;`,
that source locations from imported files are also handled correctly,
etc… It also highlights the ranges of stuff so it's easy to see if there
are off-by-one errors.
It's easiest to use inline source maps with this tool because you can
take the CSS file and drop it on the page and it'll analyze it while
showing the file content.
If you're using Vite you'll want to access the CSS file with `?direct`
at the end so you don't get a JS module back.
## Implementation
The source map implementation follows the ECMA-426 specification and
includes several key components to aid in that goal:
### Source Location Tracking
Each emittable AST node in the compilation pipeline tracks two types of
source locations:
- `src`: Original source location - [source file, start offset, end
offset]
- `dst`: Generated source location - [output file, start offset, end
offset]
This dual tracking allows us to maintain mappings between the original
source and generated output for things like user CSS, generated
utilities, uses of `@apply`, and tracking theme variables.
It is important to note that source locations for nodes _never overlap_
within a file which helps simplify source map generation. As such each
type of node tracks a specific piece of itself rather than its entire
"block":
| Node | What a `SourceLocation` represents |
| ----------- |
---------------------------------------------------------------- |
| Style Rule | The selector |
| At Rule | Rule name and params, includes the `@` |
| Declaration | Property name and value, excludes the semicolon |
| Comment | The entire comment, includes the start `/*` and end `*/`
markers |
### Windows line endings when parsing CSS
Because our AST tracks nodes through offsets we must ensure that any
mutations to the file do *not* change the lenth of the string. We were
previously replacing `\r\n` with `\n` (see [filter code
points](https://drafts.csswg.org/css-syntax/#css-filter-code-points)
from the spec) — which changes the length of the string and all offsets
may end up incorrect. The CSS parser was updated to handle the CRLF
token directly by skipping over the `\r` and letting remaining code
handle `\n` as it did previously. Some additional tweaks were required
when "peeking" the input but those changes were fairly small.
### Tracking of imports
Source maps need paths to the actual imported stylesheets but the
resolve step for stylesheets happens inside the call to `loadStylesheet`
which make the file path unavailable to us. Because of this the
`loadStylesheet` API was augmented such that it has to return a `path`
property that we can then use to identify imported sources. I've also
made the same change to the `loadModule` API for consistency but nothing
currently uses this property.
The `path` property likely makes `base` redundant but elminating that
(if we even want to) is a future task.
### Optimizing the AST
Our optimization pass may intoduce some nodes, for example, fallbacks we
create for `@property`. These nodes are linked back to `@tailwind
utilities` as ultimately that is what is responsible for creating them.
### Line Offset Tables
A key component to our source map generation is the line offset table,
which was inspired by some ESBuild internals. It stores a sorted list of
offsets for the start of each line allowing us to translate offsets to
line/column `Position`s in `O(log N)` time and from `Position`s to
offsets in `O(1)` time. Creation of the table takes `O(N)` time.
This means that we can store code point offsets for source locations and
not have to worry about computing or tracking line/column numbers during
parsing and serialization. Only when a source map is generated do these
offsets need to be computed. This ensures the performance penalty when
not using source maps is minimal.
### Source Map Generation
The source map returned by `buildSourceMap()` is designed to follow the
[ECMA-426 spec](https://tc39.es/ecma426). Because that spec is not
completely finalized we consider the result of `buildSourceMap()` to be
internal API that may change as the spec chamges.
The produces source map is a "decoded" map such that all sources and
mappings are in an object graph. A library like `source-map-js` must be
used to convert this to an encoded source map of the right version where
mappings are encoded with base 64 VLQs.
Any specific integration (Vite, PostCSS, etc…) can then use
`toSourceMap()` from `@tailwindcss/node` to convert from the internal
source map to an spec-compliant encoded source map that can be
understood by other tools.
### Handling minification in Lightning
Since we use Lightning CSS for optimization, and it takes in an input
map, we generate an encoded source map that we then pass to lightning.
The output source map *from lighting itself* is then passed back in
during the second optimization pass. The final map is then passed from
lightning to the CLI (but not Vite or PostCSS — see the limitations
section for details).
In some cases we have to "fix up" the output CSS. When this happens we
use `magic-string` to do the replacement in a way that is trackable and
`@amppproject/remapping` to map that change back onto the original
source map. Once the need for these fix ups disappear these dependencies
can go away.
Notes:
- The accuracy of source maps run though lightning is reduced as it only
tracks on a per-rule level. This is sufficient enough for browser dev
tools so should be fine.
- Source maps during optimization do not function properly at this time
because of a bug in Lightning CSS regarding license comments. Once this
bug is fixed they will start working as expected.
### How source locations flow through the system
1. During initial CSS parsing, source locations are preserved.
2. During parsing these source locations are also mapped to the
destinations which supports an optimization for when no utilities are
generated.
3. Throughout the compilation process, transformations maintain source
location data
4. Generated utilities are explicitly pointed to `@tailwind utilities`
unless generated by `@apply`.
5. When optimization is enabled, source maps are remapped through
lightningcss
6. Final source maps are written in the requested format (inline or
separate file)
2025-05-08 16:29:49 -04:00
|
|
|
magic-string:
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: ^1.1.0
|
|
|
|
|
version: 1.1.0
|
Add support for source maps (#17775)
Closes #13694
Closes #13591
# Source Maps Support for Tailwind CSS
This PR adds support for source maps to Tailwind CSS v4 allowing us to
track where styles come from whether that be user CSS, imported
stylesheets, or generated utilities. This will improve debuggability in
browser dev tools and gives us a good foundation for producing better
error messages. I'll go over the details on how end users can enable
source maps, any limitations in our implementation, changes to the
internal `compile(…)` API, and some details and reasoning around the
implementation we chose.
## Usage
### CLI
Source maps can be enabled in the CLI by using the command line argument
`--map` which will generate an inline source map comment at the bottom
of your CSS. A separate file may be generated by passing a file name to
`--map`:
```bash
# Generates an inline source map
npx tailwindcss -i input.css -o output.css --map
# Generates a separate source map file
npx tailwindcss -i input.css -o output.css --map output.css.map
```
### PostCSS
Source maps are supported when using Tailwind as a PostCSS plugin *in
development mode only*. They may or may not be enabled by default
depending on your build tool. If they are not you may be able to
configure them within your PostCSS config:
```jsonc
// package.json
{
// …
"postcss": {
"map": { "inline": true },
"plugins": {
"@tailwindcss/postcss": {},
},
}
}
```
### Vite
Source maps are supported when using the Tailwind CSS Vite plugin in
*development mode only* by enabling the `css.devSourcemap` setting:
```js
import tailwindcss from "@tailwindcss/vite";
import { defineConfig } from "vite";
export default defineConfig({
plugins: [tailwindcss()],
css: {
devSourcemap: true,
},
})
```
Now when a CSS file is requested by the browser it'll have an inline
source map comment that the browser can use.
## Limitations
- Production build source maps are currently disabled due to a bug in
Lightning CSS. See
https://github.com/parcel-bundler/lightningcss/pull/971 for more
details.
- In Vite, minified CSS build source maps are not supported at all. See
https://github.com/vitejs/vite/issues/2830 for more details.
- In PostCSS, minified CSS source maps are not supported. This is due to
the complexity required around re-associating every AST node with a
location in the generated, optimized CSS. This complexity would also
have a non-trivial performance impact.
## Testing
Here's how to test the source map functionality in different
environments:
### Testing the CLI
1. Setup typical project that the CLI can use and with sources to scan.
```css
@import "tailwindcss";
@utilty my-custom-utility {
color: red;
}
/* to test `@apply` */
.card {
@apply bg-white text-center shadow-md;
}
```
2. Build with source maps:
```bash
bun /path/to/tailwindcss/packages/@tailwindcss-cli/src/index.ts --input input.css -o output.css --map
```
3. Open Chrome DevTools, inspect an element with utility classes, and
you should see rules pointing to `input.css` or
`node_modules/tailwindcss/index.css`
### Testing with Vite
Testing in Vite will require building and installing necessary files
under `dist/*.tgz`.
1. Create a Vite project and enable source maps in `vite.config.js`:
```js
import tailwindcss from "@tailwindcss/vite";
import { defineConfig } from "vite";
export default defineConfig({
plugins: [tailwindcss()],
css: {
// This line is required for them to work
devSourcemap: true,
},
})
```
2. Add a component that uses Tailwind classes and custom CSS:
```jsx
// ./src/app.jsx
export default function App() {
return (
<div className="bg-blue-500 my-custom-class">
Hello World
</div>
)
}
```
```css
/* ./src/styles.css */
@import "tailwindcss";
@utilty my-custom-utility {
color: red;
}
/* to test `@apply` */
.card {
@apply bg-white text-center shadow-md;
}
```
3. Run `npm run dev`, open DevTools, and inspect elements to verify
source mapping works for both utility classes and custom CSS.
### Testing with PostCSS CLI
1. Create a test file and update your PostCSS config:
```css
/* input.css */
@import "tailwindcss";
@layer components {
.card {
@apply p-6 rounded-lg shadow-lg;
}
}
```
```jsonc
// package.json
{
// …
"postcss": {
"map": {
"inline": true
},
"plugins": {
"/path/to/tailwindcss/packages/packages/@tailwindcss-postcss/src/index.ts": {}
}
}
}
```
2. Run PostCSS through Bun:
```bash
bunx --bun postcss ./src/index.css -o out.css
```
3. Inspect the output CSS - it should include an inline source map
comment at the bottom.
### Testing with PostCSS + Next.js
Testing in Next.js will require building and installing necessary files
under `dist/*.tgz`. However, I've not been able to get CSS source maps
to work in Next.js without this hack:
```js
const nextConfig: NextConfig = {
// next.js overwrites config.devtool so we prevent it from doing so
// please don't actually do this…
webpack: (config) =>
Object.defineProperty(config, "devtool", {
get: () => "inline-source-map",
set: () => {},
}),
};
```
This is definitely not supported and also doesn't work with turbopack.
This can be used to test them temporarily but I suspect that they just
don't work there.
### Manual source map analysis
You can analyze source maps using Evan Wallace's [Source Map
Visualization](https://evanw.github.io/source-map-visualization/) tool
which will help to verify the accuracy and quality of source maps. This
is what I used extensively while developing this implementation.
It'll help verify that custom, user CSS maps back to itself in the
input, that generated utilities all map back to `@tailwind utilities;`,
that source locations from imported files are also handled correctly,
etc… It also highlights the ranges of stuff so it's easy to see if there
are off-by-one errors.
It's easiest to use inline source maps with this tool because you can
take the CSS file and drop it on the page and it'll analyze it while
showing the file content.
If you're using Vite you'll want to access the CSS file with `?direct`
at the end so you don't get a JS module back.
## Implementation
The source map implementation follows the ECMA-426 specification and
includes several key components to aid in that goal:
### Source Location Tracking
Each emittable AST node in the compilation pipeline tracks two types of
source locations:
- `src`: Original source location - [source file, start offset, end
offset]
- `dst`: Generated source location - [output file, start offset, end
offset]
This dual tracking allows us to maintain mappings between the original
source and generated output for things like user CSS, generated
utilities, uses of `@apply`, and tracking theme variables.
It is important to note that source locations for nodes _never overlap_
within a file which helps simplify source map generation. As such each
type of node tracks a specific piece of itself rather than its entire
"block":
| Node | What a `SourceLocation` represents |
| ----------- |
---------------------------------------------------------------- |
| Style Rule | The selector |
| At Rule | Rule name and params, includes the `@` |
| Declaration | Property name and value, excludes the semicolon |
| Comment | The entire comment, includes the start `/*` and end `*/`
markers |
### Windows line endings when parsing CSS
Because our AST tracks nodes through offsets we must ensure that any
mutations to the file do *not* change the lenth of the string. We were
previously replacing `\r\n` with `\n` (see [filter code
points](https://drafts.csswg.org/css-syntax/#css-filter-code-points)
from the spec) — which changes the length of the string and all offsets
may end up incorrect. The CSS parser was updated to handle the CRLF
token directly by skipping over the `\r` and letting remaining code
handle `\n` as it did previously. Some additional tweaks were required
when "peeking" the input but those changes were fairly small.
### Tracking of imports
Source maps need paths to the actual imported stylesheets but the
resolve step for stylesheets happens inside the call to `loadStylesheet`
which make the file path unavailable to us. Because of this the
`loadStylesheet` API was augmented such that it has to return a `path`
property that we can then use to identify imported sources. I've also
made the same change to the `loadModule` API for consistency but nothing
currently uses this property.
The `path` property likely makes `base` redundant but elminating that
(if we even want to) is a future task.
### Optimizing the AST
Our optimization pass may intoduce some nodes, for example, fallbacks we
create for `@property`. These nodes are linked back to `@tailwind
utilities` as ultimately that is what is responsible for creating them.
### Line Offset Tables
A key component to our source map generation is the line offset table,
which was inspired by some ESBuild internals. It stores a sorted list of
offsets for the start of each line allowing us to translate offsets to
line/column `Position`s in `O(log N)` time and from `Position`s to
offsets in `O(1)` time. Creation of the table takes `O(N)` time.
This means that we can store code point offsets for source locations and
not have to worry about computing or tracking line/column numbers during
parsing and serialization. Only when a source map is generated do these
offsets need to be computed. This ensures the performance penalty when
not using source maps is minimal.
### Source Map Generation
The source map returned by `buildSourceMap()` is designed to follow the
[ECMA-426 spec](https://tc39.es/ecma426). Because that spec is not
completely finalized we consider the result of `buildSourceMap()` to be
internal API that may change as the spec chamges.
The produces source map is a "decoded" map such that all sources and
mappings are in an object graph. A library like `source-map-js` must be
used to convert this to an encoded source map of the right version where
mappings are encoded with base 64 VLQs.
Any specific integration (Vite, PostCSS, etc…) can then use
`toSourceMap()` from `@tailwindcss/node` to convert from the internal
source map to an spec-compliant encoded source map that can be
understood by other tools.
### Handling minification in Lightning
Since we use Lightning CSS for optimization, and it takes in an input
map, we generate an encoded source map that we then pass to lightning.
The output source map *from lighting itself* is then passed back in
during the second optimization pass. The final map is then passed from
lightning to the CLI (but not Vite or PostCSS — see the limitations
section for details).
In some cases we have to "fix up" the output CSS. When this happens we
use `magic-string` to do the replacement in a way that is trackable and
`@amppproject/remapping` to map that change back onto the original
source map. Once the need for these fix ups disappear these dependencies
can go away.
Notes:
- The accuracy of source maps run though lightning is reduced as it only
tracks on a per-rule level. This is sufficient enough for browser dev
tools so should be fine.
- Source maps during optimization do not function properly at this time
because of a bug in Lightning CSS regarding license comments. Once this
bug is fixed they will start working as expected.
### How source locations flow through the system
1. During initial CSS parsing, source locations are preserved.
2. During parsing these source locations are also mapped to the
destinations which supports an optimization for when no utilities are
generated.
3. Throughout the compilation process, transformations maintain source
location data
4. Generated utilities are explicitly pointed to `@tailwind utilities`
unless generated by `@apply`.
5. When optimization is enabled, source maps are remapped through
lightningcss
6. Final source maps are written in the requested format (inline or
separate file)
2025-05-08 16:29:49 -04:00
|
|
|
source-map-js:
|
|
|
|
|
specifier: ^1.2.1
|
|
|
|
|
version: 1.2.1
|
2024-09-02 12:03:16 -04:00
|
|
|
tailwindcss:
|
Ensure clients pin the `tailwindcss` version (#15011)
We noticed that in the current alpha 34 release, the `package.json` file
of the `@tailwindcss/node` package only defines `tailwindcss` as a dev
dependency. This makes it very easy for version mismatches to happen
when a v3 version (or an earlier v4 alpha for that matter) was installed
in the same project:
```json
{
"name": "@tailwindcss/node",
"version": "4.0.0-alpha.34",
"description": "A utility-first CSS framework for rapidly building custom user interfaces.",
"license": "MIT",
"repository": {
"type": "git",
"url": "https://github.com/tailwindlabs/tailwindcss.git",
"directory": "packages/@tailwindcss-node"
},
"bugs": "https://github.com/tailwindlabs/tailwindcss/issues",
"homepage": "https://tailwindcss.com",
"files": [
"dist/"
],
"publishConfig": {
"provenance": true,
"access": "public"
},
"exports": {
".": {
"types": "./dist/index.d.ts",
"import": "./dist/index.mjs",
"require": "./dist/index.js"
},
"./require-cache": {
"types": "./dist/require-cache.d.ts",
"default": "./dist/require-cache.js"
},
"./esm-cache-loader": {
"types": "./dist/esm-cache.loader.d.mts",
"default": "./dist/esm-cache.loader.mjs"
}
},
"devDependencies": {
"tailwindcss": "4.0.0-alpha.34"
},
"dependencies": {
"enhanced-resolve": "^5.17.1",
"jiti": "^2.0.0-beta.3"
},
"scripts": {
"build": "tsup-node",
"dev": "pnpm run build -- --watch"
}
}
```
Furthermore, we were trying to fix issues where our integration test
setup could not install `tailwindcss@3` because of how we did pnpm
overrides.
This PR fixes this by:
- Ensuring every client that calls into `tailwindcss` core marks it as a
version-pinned dependency. You are still required to install
`tailwindcss` in your project along side a client (e.g.
`@tailwindcss/vite`) but we now only use your installed version for
importing the respective `.css` files. For the core logic, we are now
requiring each package to use `tailwindcss` at the same version. This
should help resolve issues like
https://github.com/tailwindlabs/tailwindcss/discussions/14652
- We tried to eliminate the dependency on `tailwindcss` from the
`@tailwindcss/upgrade` package. Unfortunately this is not possible to do
right now because we need to load the CSS files from v4 to create the
right environment. In a future version we could bundle the required CSS
files with `@tailwidncss/upgrade` but it doesn't seem necessary for now.
- We then changed our integration test overrides to only override the
`tailwindcss` package that are dependencies of the known list of
packages that we have `tailwindcss` dependencies on: `@tailwindcss/node`
and `@tailwindcss/upgrade`. This ensures that we can install v3 of
`tailwindcss` in the integration tests and it will work. Something we
want to do for some upgrade tests.
# Test plan
Integration work again. Furthermore we added a quick setup with the CLI
using the local tarballs and ensured it works:
```bash
pnpm init
pnpm install ../../tailwindcss/dist/tailwindcss-cli.tgz
pnpm install ../../tailwindcss/dist/tailwindcss.tgz
echo '@import "tailwindcss";' > index.css
echo '<div class="underline"></div>' > index.html
pnpm tailwindcss -i index.css -o out.css
cat out.css
```
2024-11-15 17:18:48 +01:00
|
|
|
specifier: workspace:*
|
2024-09-02 12:03:16 -04:00
|
|
|
version: link:../tailwindcss
|
|
|
|
|
|
2024-03-05 14:23:26 +01:00
|
|
|
packages/@tailwindcss-postcss:
|
|
|
|
|
dependencies:
|
2024-10-03 16:21:54 +02:00
|
|
|
'@alloc/quick-lru':
|
|
|
|
|
specifier: ^5.2.0
|
|
|
|
|
version: 5.2.0
|
2024-09-02 12:03:16 -04:00
|
|
|
'@tailwindcss/node':
|
2025-02-18 11:44:12 +01:00
|
|
|
specifier: workspace:*
|
2024-09-02 12:03:16 -04:00
|
|
|
version: link:../@tailwindcss-node
|
2024-03-05 14:23:26 +01:00
|
|
|
'@tailwindcss/oxide':
|
2025-02-18 11:44:12 +01:00
|
|
|
specifier: workspace:*
|
2024-03-23 14:00:48 +01:00
|
|
|
version: link:../../crates/node
|
2024-10-22 13:20:02 +02:00
|
|
|
postcss:
|
2026-05-21 17:58:55 +02:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 8.5.25
|
2024-03-05 14:23:26 +01:00
|
|
|
tailwindcss:
|
Ensure clients pin the `tailwindcss` version (#15011)
We noticed that in the current alpha 34 release, the `package.json` file
of the `@tailwindcss/node` package only defines `tailwindcss` as a dev
dependency. This makes it very easy for version mismatches to happen
when a v3 version (or an earlier v4 alpha for that matter) was installed
in the same project:
```json
{
"name": "@tailwindcss/node",
"version": "4.0.0-alpha.34",
"description": "A utility-first CSS framework for rapidly building custom user interfaces.",
"license": "MIT",
"repository": {
"type": "git",
"url": "https://github.com/tailwindlabs/tailwindcss.git",
"directory": "packages/@tailwindcss-node"
},
"bugs": "https://github.com/tailwindlabs/tailwindcss/issues",
"homepage": "https://tailwindcss.com",
"files": [
"dist/"
],
"publishConfig": {
"provenance": true,
"access": "public"
},
"exports": {
".": {
"types": "./dist/index.d.ts",
"import": "./dist/index.mjs",
"require": "./dist/index.js"
},
"./require-cache": {
"types": "./dist/require-cache.d.ts",
"default": "./dist/require-cache.js"
},
"./esm-cache-loader": {
"types": "./dist/esm-cache.loader.d.mts",
"default": "./dist/esm-cache.loader.mjs"
}
},
"devDependencies": {
"tailwindcss": "4.0.0-alpha.34"
},
"dependencies": {
"enhanced-resolve": "^5.17.1",
"jiti": "^2.0.0-beta.3"
},
"scripts": {
"build": "tsup-node",
"dev": "pnpm run build -- --watch"
}
}
```
Furthermore, we were trying to fix issues where our integration test
setup could not install `tailwindcss@3` because of how we did pnpm
overrides.
This PR fixes this by:
- Ensuring every client that calls into `tailwindcss` core marks it as a
version-pinned dependency. You are still required to install
`tailwindcss` in your project along side a client (e.g.
`@tailwindcss/vite`) but we now only use your installed version for
importing the respective `.css` files. For the core logic, we are now
requiring each package to use `tailwindcss` at the same version. This
should help resolve issues like
https://github.com/tailwindlabs/tailwindcss/discussions/14652
- We tried to eliminate the dependency on `tailwindcss` from the
`@tailwindcss/upgrade` package. Unfortunately this is not possible to do
right now because we need to load the CSS files from v4 to create the
right environment. In a future version we could bundle the required CSS
files with `@tailwidncss/upgrade` but it doesn't seem necessary for now.
- We then changed our integration test overrides to only override the
`tailwindcss` package that are dependencies of the known list of
packages that we have `tailwindcss` dependencies on: `@tailwindcss/node`
and `@tailwindcss/upgrade`. This ensures that we can install v3 of
`tailwindcss` in the integration tests and it will work. Something we
want to do for some upgrade tests.
# Test plan
Integration work again. Furthermore we added a quick setup with the CLI
using the local tarballs and ensured it works:
```bash
pnpm init
pnpm install ../../tailwindcss/dist/tailwindcss-cli.tgz
pnpm install ../../tailwindcss/dist/tailwindcss.tgz
echo '@import "tailwindcss";' > index.css
echo '<div class="underline"></div>' > index.html
pnpm tailwindcss -i index.css -o out.css
cat out.css
```
2024-11-15 17:18:48 +01:00
|
|
|
specifier: workspace:*
|
2024-03-05 14:23:26 +01:00
|
|
|
version: link:../tailwindcss
|
|
|
|
|
devDependencies:
|
|
|
|
|
'@types/node':
|
2024-08-02 10:33:14 +02:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 22.20.1
|
2024-03-05 14:23:26 +01:00
|
|
|
'@types/postcss-import':
|
Resolve `@import` in core (#14446)
This PR brings `@import` resolution into Tailwind CSS core. This means
that our clients (PostCSS, Vite, and CLI) no longer need to depend on
`postcss` and `postcss-import` to resolve `@import`. Furthermore this
simplifies the handling of relative paths for `@source`, `@plugin`, or
`@config` in transitive CSS files (where the relative root should always
be relative to the CSS file that contains the directive). This PR also
fixes a plugin resolution bug where non-relative imports (e.g. directly
importing node modules like `@plugin '@tailwindcss/typography';`) would
not work in CSS files that are based in a different npm package.
### Resolving `@import`
The core of the `@import` resolution is inside
`packages/tailwindcss/src/at-import.ts`. There, to keep things
performant, we do a two-step process to resolve imports. Imagine the
following input CSS file:
```css
@import "tailwindcss/theme.css";
@import "tailwindcss/utilities.css";
```
Since our AST walks are synchronous, we will do a first traversal where
we start a loading request for each `@import` directive. Once all loads
are started, we will await the promise and do a second walk where we
actually replace the AST nodes with their resolved stylesheets. All of
this is recursive, so that `@import`-ed files can again `@import` other
files.
The core `@import` resolver also includes extensive test cases for
[various combinations of media query and supports conditionals as well
als layered
imports](https://developer.mozilla.org/en-US/docs/Web/CSS/@import).
When the same file is imported multiple times, the AST nodes are
duplicated but duplicate I/O is avoided on a per-file basis, so this
will only load one file, but include the `@theme` rules twice:
```css
@import "tailwindcss/theme.css";
@import "tailwindcss/theme.css";
```
### Adding a new `context` node to the AST
One limitation we had when working with the `postcss-import` plugin was
the need to do an additional traversal to rewrite relative `@source`,
`@plugin`, and `@config` directives. This was needed because we want
these paths to be relative to the CSS file that defines the directive
but when flattening a CSS file, this information is no longer part of
the stringifed CSS representation. We worked around this by rewriting
the content of these directives to be relative to the input CSS file,
which resulted in added complexity and caused a lot of issues with
Windows paths in the beginning.
Now that we are doing the `@import` resolution in core, we can use a
different data structure to persist this information. This PR adds a new
`context` node so that we can store arbitrary context like this inside
the Ast directly. This allows us to share information with the sub tree
_while doing the Ast walk_.
Here's an example of how the new `context` node can be used to share
information with subtrees:
```ts
const ast = [
rule('.foo', [decl('color', 'red')]),
context({ value: 'a' }, [
rule('.bar', [
decl('color', 'blue'),
context({ value: 'b' }, [
rule('.baz', [decl('color', 'green')]),
]),
]),
]),
]
walk(ast, (node, { context }) => {
if (node.kind !== 'declaration') return
switch (node.value) {
case 'red': assert(context.value === undefined)
case 'blue': assert(context.value === 'a')
case 'green': assert(context.value === 'b')
}
})
```
In core, we use this new Ast node specifically to persist the `base`
path of the current CSS file. We put the input CSS file `base` at the
root of the Ast and then overwrite the `base` on every `@import`
substitution.
### Removing the dependency on `postcss-import`
Now that we support `@import` resolution in core, our clients no longer
need a dependency on `postcss-import`. Furthermore, most dependencies
also don't need to know about `postcss` at all anymore (except the
PostCSS client, of course!).
This also means that our workaround for rewriting `@source`, the
`postcss-fix-relative-paths` plugin, can now go away as a shared
dependency between all of our clients. Note that we still have it for
the PostCSS plugin only, where it's possible that users already have
`postcss-import` running _before_ the `@tailwindcss/postcss` plugin.
Here's an example of the changes to the dependencies for our Vite client
✨ :
<img width="854" alt="Screenshot 2024-09-19 at 16 59 45"
src="https://github.com/user-attachments/assets/ae1f9d5f-d93a-4de9-9244-61af3aff1237">
### Performance
Since our Vite and CLI clients now no longer need to use `postcss` at
all, we have also measured a significant improvement to the initial
build times. For a small test setup that contains only a hand full of
files (nothing super-complex), we measured an improvement in the
**3.5x** range:
<img width="1334" alt="Screenshot 2024-09-19 at 14 52 49"
src="https://github.com/user-attachments/assets/06071fb0-7f2a-4de6-8ec8-f202d2cc78e5">
The code for this is in the commit history if you want to reproduce the
results. The test was based on the Vite client.
### Caveats
One thing to note is that we previously relied on finding specific
symbols in the input CSS to _bail out of Tailwind processing
completely_. E.g. if a file does not contain a `@tailwind` or `@apply`
directive, it can never be a Tailwind file.
Since we no longer have a string representation of the flattened CSS
file, we can no longer do this check. However, the current
implementation was already inconsistent with differences on the allowed
symbol list between our clients. Ideally, Tailwind CSS should figure out
wether a CSS file is a Tailwind CSS file. This, however, is left as an
improvement for a future API since it goes hand-in-hand with our planned
API changes for the core `tailwindcss` package.
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-09-23 17:05:55 +02:00
|
|
|
specifier: 14.0.3
|
2024-03-05 14:23:26 +01:00
|
|
|
version: 14.0.3
|
Improve performance of `@tailwindcss/postcss` and `@tailwindcss/vite` (#15226)
This PR improves the performance of the `@tailwindcss/postcss` and
`@tailwindcss/vite` implementations.
The issue is that in some scenarios, if you have multiple `.css` files,
then all of the CSS files are ran through the Tailwind CSS compiler. The
issue with this is that in a lot of cases, the CSS files aren't even
related to Tailwind CSS at all.
E.g.: in a Next.js project, if you use the `next/font/local` tool, then
every font you used will be in a separate CSS file. This means that we
run Tailwind CSS in all these files as well.
That said, running Tailwind CSS on these files isn't the end of the
world because we still need to handle `@import` in case `@tailwind
utilities` is being used. However, we also run the auto source detection
logic for every CSS file in the system. This part is bad.
To solve this, this PR introduces an internal `features` to collect what
CSS features are used throughout the system (`@import`, `@plugin`,
`@apply`, `@tailwind utilities`, etc…)
The `@tailwindcss/postcss` and `@tailwindcss/vite` plugin can use that
information to decide if they can take some shortcuts or not.
---
Overall, this means that we don't run the slow parts of Tailwind CSS if
we don't need to.
---------
Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-11-29 16:59:29 +01:00
|
|
|
dedent:
|
2026-05-21 17:58:55 +02:00
|
|
|
specifier: 'catalog:'
|
2026-04-24 21:21:12 +02:00
|
|
|
version: 1.7.2
|
2024-07-29 16:58:07 +02:00
|
|
|
internal-example-plugin:
|
|
|
|
|
specifier: workspace:*
|
|
|
|
|
version: link:../internal-example-plugin
|
Resolve `@import` in core (#14446)
This PR brings `@import` resolution into Tailwind CSS core. This means
that our clients (PostCSS, Vite, and CLI) no longer need to depend on
`postcss` and `postcss-import` to resolve `@import`. Furthermore this
simplifies the handling of relative paths for `@source`, `@plugin`, or
`@config` in transitive CSS files (where the relative root should always
be relative to the CSS file that contains the directive). This PR also
fixes a plugin resolution bug where non-relative imports (e.g. directly
importing node modules like `@plugin '@tailwindcss/typography';`) would
not work in CSS files that are based in a different npm package.
### Resolving `@import`
The core of the `@import` resolution is inside
`packages/tailwindcss/src/at-import.ts`. There, to keep things
performant, we do a two-step process to resolve imports. Imagine the
following input CSS file:
```css
@import "tailwindcss/theme.css";
@import "tailwindcss/utilities.css";
```
Since our AST walks are synchronous, we will do a first traversal where
we start a loading request for each `@import` directive. Once all loads
are started, we will await the promise and do a second walk where we
actually replace the AST nodes with their resolved stylesheets. All of
this is recursive, so that `@import`-ed files can again `@import` other
files.
The core `@import` resolver also includes extensive test cases for
[various combinations of media query and supports conditionals as well
als layered
imports](https://developer.mozilla.org/en-US/docs/Web/CSS/@import).
When the same file is imported multiple times, the AST nodes are
duplicated but duplicate I/O is avoided on a per-file basis, so this
will only load one file, but include the `@theme` rules twice:
```css
@import "tailwindcss/theme.css";
@import "tailwindcss/theme.css";
```
### Adding a new `context` node to the AST
One limitation we had when working with the `postcss-import` plugin was
the need to do an additional traversal to rewrite relative `@source`,
`@plugin`, and `@config` directives. This was needed because we want
these paths to be relative to the CSS file that defines the directive
but when flattening a CSS file, this information is no longer part of
the stringifed CSS representation. We worked around this by rewriting
the content of these directives to be relative to the input CSS file,
which resulted in added complexity and caused a lot of issues with
Windows paths in the beginning.
Now that we are doing the `@import` resolution in core, we can use a
different data structure to persist this information. This PR adds a new
`context` node so that we can store arbitrary context like this inside
the Ast directly. This allows us to share information with the sub tree
_while doing the Ast walk_.
Here's an example of how the new `context` node can be used to share
information with subtrees:
```ts
const ast = [
rule('.foo', [decl('color', 'red')]),
context({ value: 'a' }, [
rule('.bar', [
decl('color', 'blue'),
context({ value: 'b' }, [
rule('.baz', [decl('color', 'green')]),
]),
]),
]),
]
walk(ast, (node, { context }) => {
if (node.kind !== 'declaration') return
switch (node.value) {
case 'red': assert(context.value === undefined)
case 'blue': assert(context.value === 'a')
case 'green': assert(context.value === 'b')
}
})
```
In core, we use this new Ast node specifically to persist the `base`
path of the current CSS file. We put the input CSS file `base` at the
root of the Ast and then overwrite the `base` on every `@import`
substitution.
### Removing the dependency on `postcss-import`
Now that we support `@import` resolution in core, our clients no longer
need a dependency on `postcss-import`. Furthermore, most dependencies
also don't need to know about `postcss` at all anymore (except the
PostCSS client, of course!).
This also means that our workaround for rewriting `@source`, the
`postcss-fix-relative-paths` plugin, can now go away as a shared
dependency between all of our clients. Note that we still have it for
the PostCSS plugin only, where it's possible that users already have
`postcss-import` running _before_ the `@tailwindcss/postcss` plugin.
Here's an example of the changes to the dependencies for our Vite client
✨ :
<img width="854" alt="Screenshot 2024-09-19 at 16 59 45"
src="https://github.com/user-attachments/assets/ae1f9d5f-d93a-4de9-9244-61af3aff1237">
### Performance
Since our Vite and CLI clients now no longer need to use `postcss` at
all, we have also measured a significant improvement to the initial
build times. For a small test setup that contains only a hand full of
files (nothing super-complex), we measured an improvement in the
**3.5x** range:
<img width="1334" alt="Screenshot 2024-09-19 at 14 52 49"
src="https://github.com/user-attachments/assets/06071fb0-7f2a-4de6-8ec8-f202d2cc78e5">
The code for this is in the commit history if you want to reproduce the
results. The test was based on the Vite client.
### Caveats
One thing to note is that we previously relied on finding specific
symbols in the input CSS to _bail out of Tailwind processing
completely_. E.g. if a file does not contain a `@tailwind` or `@apply`
directive, it can never be a Tailwind file.
Since we no longer have a string representation of the flattened CSS
file, we can no longer do this check. However, the current
implementation was already inconsistent with differences on the allowed
symbol list between our clients. Ideally, Tailwind CSS should figure out
wether a CSS file is a Tailwind CSS file. This, however, is left as an
improvement for a future API since it goes hand-in-hand with our planned
API changes for the core `tailwindcss` package.
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-09-23 17:05:55 +02:00
|
|
|
postcss-import:
|
2025-06-24 09:57:35 -04:00
|
|
|
specifier: ^16.1.1
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 16.1.1(postcss@8.5.25)
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-09-02 15:23:46 +02:00
|
|
|
packages/@tailwindcss-standalone:
|
|
|
|
|
dependencies:
|
2024-11-19 16:19:08 +01:00
|
|
|
'@tailwindcss/aspect-ratio':
|
|
|
|
|
specifier: ^0.4.2
|
|
|
|
|
version: 0.4.2(tailwindcss@packages+tailwindcss)
|
2024-09-02 15:23:46 +02:00
|
|
|
'@tailwindcss/cli':
|
2025-02-18 11:44:12 +01:00
|
|
|
specifier: workspace:*
|
2024-09-02 15:23:46 +02:00
|
|
|
version: link:../@tailwindcss-cli
|
2024-11-19 16:19:08 +01:00
|
|
|
'@tailwindcss/forms':
|
2025-12-24 17:20:21 -05:00
|
|
|
specifier: ^0.5.11
|
|
|
|
|
version: 0.5.11(tailwindcss@packages+tailwindcss)
|
2024-11-19 16:19:08 +01:00
|
|
|
'@tailwindcss/typography':
|
2026-06-15 13:13:32 +00:00
|
|
|
specifier: ^0.5.20
|
|
|
|
|
version: 0.5.20(tailwindcss@packages+tailwindcss)
|
2024-09-02 15:23:46 +02:00
|
|
|
detect-libc:
|
|
|
|
|
specifier: 1.0.3
|
|
|
|
|
version: 1.0.3
|
|
|
|
|
enhanced-resolve:
|
2026-05-21 17:58:55 +02:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 5.24.5
|
2024-09-02 15:23:46 +02:00
|
|
|
tailwindcss:
|
2025-02-18 11:44:12 +01:00
|
|
|
specifier: workspace:*
|
2024-09-02 15:23:46 +02:00
|
|
|
version: link:../tailwindcss
|
|
|
|
|
devDependencies:
|
|
|
|
|
'@parcel/watcher-darwin-arm64':
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: 'catalog:'
|
|
|
|
|
version: 2.6.0
|
2024-09-02 15:23:46 +02:00
|
|
|
'@parcel/watcher-darwin-x64':
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: 'catalog:'
|
|
|
|
|
version: 2.6.0
|
2024-09-02 15:23:46 +02:00
|
|
|
'@parcel/watcher-linux-arm64-glibc':
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: 'catalog:'
|
|
|
|
|
version: 2.6.0
|
2024-09-02 15:23:46 +02:00
|
|
|
'@parcel/watcher-linux-arm64-musl':
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: 'catalog:'
|
|
|
|
|
version: 2.6.0
|
2024-09-02 15:23:46 +02:00
|
|
|
'@parcel/watcher-linux-x64-glibc':
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: 'catalog:'
|
|
|
|
|
version: 2.6.0
|
2024-09-02 15:23:46 +02:00
|
|
|
'@parcel/watcher-linux-x64-musl':
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: 'catalog:'
|
|
|
|
|
version: 2.6.0
|
2024-09-02 15:23:46 +02:00
|
|
|
'@parcel/watcher-win32-x64':
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: 'catalog:'
|
|
|
|
|
version: 2.6.0
|
2024-09-02 15:23:46 +02:00
|
|
|
'@types/bun':
|
2026-05-21 17:58:55 +02:00
|
|
|
specifier: ^1.3.14
|
|
|
|
|
version: 1.3.14
|
2024-09-02 15:23:46 +02:00
|
|
|
bun:
|
2026-05-21 17:58:55 +02:00
|
|
|
specifier: ^1.3.14
|
|
|
|
|
version: 1.3.14
|
2024-09-02 15:23:46 +02:00
|
|
|
lightningcss-darwin-arm64:
|
2025-03-13 11:18:06 +01:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 1.33.0
|
2024-09-02 15:23:46 +02:00
|
|
|
lightningcss-darwin-x64:
|
2025-03-13 11:18:06 +01:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 1.33.0
|
2024-09-02 15:23:46 +02:00
|
|
|
lightningcss-linux-arm64-gnu:
|
2025-03-13 11:18:06 +01:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 1.33.0
|
2024-09-02 15:23:46 +02:00
|
|
|
lightningcss-linux-arm64-musl:
|
2025-03-13 11:18:06 +01:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 1.33.0
|
2024-09-02 15:23:46 +02:00
|
|
|
lightningcss-linux-x64-gnu:
|
2025-03-13 11:18:06 +01:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 1.33.0
|
2024-09-02 15:23:46 +02:00
|
|
|
lightningcss-linux-x64-musl:
|
2025-03-13 11:18:06 +01:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 1.33.0
|
2024-09-02 15:23:46 +02:00
|
|
|
lightningcss-win32-x64-msvc:
|
2025-03-13 11:18:06 +01:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 1.33.0
|
|
|
|
|
|
|
|
|
|
packages/@tailwindcss-turbopack:
|
|
|
|
|
dependencies:
|
|
|
|
|
'@alloc/quick-lru':
|
|
|
|
|
specifier: ^5.2.0
|
|
|
|
|
version: 5.2.0
|
|
|
|
|
'@tailwindcss/node':
|
|
|
|
|
specifier: workspace:*
|
|
|
|
|
version: link:../@tailwindcss-node
|
|
|
|
|
'@tailwindcss/oxide':
|
|
|
|
|
specifier: workspace:*
|
|
|
|
|
version: link:../../crates/node
|
|
|
|
|
tailwindcss:
|
|
|
|
|
specifier: workspace:*
|
|
|
|
|
version: link:../tailwindcss
|
|
|
|
|
devDependencies:
|
|
|
|
|
'@types/node':
|
|
|
|
|
specifier: 'catalog:'
|
|
|
|
|
version: 22.20.1
|
|
|
|
|
webpack:
|
|
|
|
|
specifier: 'catalog:'
|
|
|
|
|
version: 5.109.2(esbuild@0.27.7)(postcss@8.5.25)
|
2024-09-02 15:23:46 +02:00
|
|
|
|
2024-09-18 16:45:43 +02:00
|
|
|
packages/@tailwindcss-upgrade:
|
|
|
|
|
dependencies:
|
Add setup for template migrations (#14502)
This PR adds the initial setup and a first codemod for the template
migrations. These are a new set of migrations that operate on files
defined in the Tailwind v3 config as part of the `content` option (so
your HTML, JavaScript, TSX files etc.).
The migration for this is integrated in the new `@tailwindcss/upgrade`
package and will require pointing the migration to an input JavaScript
config file, like this:
```
npx @tailwindcss/upgrade --config tailwind.config.js
```
The idea of template migrations is to apply breaking changes from the v3
to v4 migration within your template files.
## Migrating !important syntax
The first migration that I’m adding with this PR is to ensure we use the
v4 important syntax that has the exclamation mark at the end of the
utility.
For example, this:
```html
<div class="!flex sm:!block"></div>
```
Will now turn into:
```html
<div class="flex! sm:block!"></div>
```
## Architecture considerations
Implementation wise, we make use of Oxide to scan the content files fast
and efficiently. By relying on the same scanner als Tailwind v4, we
guarantee that all candidates that are part of the v4 output will have
gone through a migration.
Migrations itself operate on the abstract `Candidate` type, similar to
the type we use in the v4 codebase. It will parse the candidate into its
parts so they can easily be introspected/modified. Migrations are typed
as:
```ts
type TemplateMigration = (candidate: Candidate) => Candidate | null
```
`null` should be returned if the `Candidate` does not need a migration.
We currently use the v4 `parseCandidate` function to get an abstract
definition of the candidate rule that we can operate on. _This will
likely need to change in the future as we need to fork `parseCandidate`
for v3 specific syntax_.
Additionally, we're inlining a `printCandidate` function that can
stringify the abstract `Candidate` type. It is not guaranteed that this
is an identity function since some information can be lost during the
parse step. This is not a problem though, because migrations will only
run selectively and if none of the selectors trigger, the candidates are
not updated. h/t to @RobinMalfait for providing the printer.
So the overall flow of a migration looks like this:
- Scan the config file for `content` files
- Use Oxide to extract a list of candidate and their positions from
these `content` files
- Run a few migrations that operate on the `Candidate` abstract type.
- Print the updated `Candidate` back into the original `content` file.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-09-25 16:20:14 +02:00
|
|
|
'@tailwindcss/node':
|
2025-02-18 11:44:12 +01:00
|
|
|
specifier: workspace:*
|
Add setup for template migrations (#14502)
This PR adds the initial setup and a first codemod for the template
migrations. These are a new set of migrations that operate on files
defined in the Tailwind v3 config as part of the `content` option (so
your HTML, JavaScript, TSX files etc.).
The migration for this is integrated in the new `@tailwindcss/upgrade`
package and will require pointing the migration to an input JavaScript
config file, like this:
```
npx @tailwindcss/upgrade --config tailwind.config.js
```
The idea of template migrations is to apply breaking changes from the v3
to v4 migration within your template files.
## Migrating !important syntax
The first migration that I’m adding with this PR is to ensure we use the
v4 important syntax that has the exclamation mark at the end of the
utility.
For example, this:
```html
<div class="!flex sm:!block"></div>
```
Will now turn into:
```html
<div class="flex! sm:block!"></div>
```
## Architecture considerations
Implementation wise, we make use of Oxide to scan the content files fast
and efficiently. By relying on the same scanner als Tailwind v4, we
guarantee that all candidates that are part of the v4 output will have
gone through a migration.
Migrations itself operate on the abstract `Candidate` type, similar to
the type we use in the v4 codebase. It will parse the candidate into its
parts so they can easily be introspected/modified. Migrations are typed
as:
```ts
type TemplateMigration = (candidate: Candidate) => Candidate | null
```
`null` should be returned if the `Candidate` does not need a migration.
We currently use the v4 `parseCandidate` function to get an abstract
definition of the candidate rule that we can operate on. _This will
likely need to change in the future as we need to fork `parseCandidate`
for v3 specific syntax_.
Additionally, we're inlining a `printCandidate` function that can
stringify the abstract `Candidate` type. It is not guaranteed that this
is an identity function since some information can be lost during the
parse step. This is not a problem though, because migrations will only
run selectively and if none of the selectors trigger, the candidates are
not updated. h/t to @RobinMalfait for providing the printer.
So the overall flow of a migration looks like this:
- Scan the config file for `content` files
- Use Oxide to extract a list of candidate and their positions from
these `content` files
- Run a few migrations that operate on the `Candidate` abstract type.
- Print the updated `Candidate` back into the original `content` file.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-09-25 16:20:14 +02:00
|
|
|
version: link:../@tailwindcss-node
|
|
|
|
|
'@tailwindcss/oxide':
|
2025-02-18 11:44:12 +01:00
|
|
|
specifier: workspace:*
|
Add setup for template migrations (#14502)
This PR adds the initial setup and a first codemod for the template
migrations. These are a new set of migrations that operate on files
defined in the Tailwind v3 config as part of the `content` option (so
your HTML, JavaScript, TSX files etc.).
The migration for this is integrated in the new `@tailwindcss/upgrade`
package and will require pointing the migration to an input JavaScript
config file, like this:
```
npx @tailwindcss/upgrade --config tailwind.config.js
```
The idea of template migrations is to apply breaking changes from the v3
to v4 migration within your template files.
## Migrating !important syntax
The first migration that I’m adding with this PR is to ensure we use the
v4 important syntax that has the exclamation mark at the end of the
utility.
For example, this:
```html
<div class="!flex sm:!block"></div>
```
Will now turn into:
```html
<div class="flex! sm:block!"></div>
```
## Architecture considerations
Implementation wise, we make use of Oxide to scan the content files fast
and efficiently. By relying on the same scanner als Tailwind v4, we
guarantee that all candidates that are part of the v4 output will have
gone through a migration.
Migrations itself operate on the abstract `Candidate` type, similar to
the type we use in the v4 codebase. It will parse the candidate into its
parts so they can easily be introspected/modified. Migrations are typed
as:
```ts
type TemplateMigration = (candidate: Candidate) => Candidate | null
```
`null` should be returned if the `Candidate` does not need a migration.
We currently use the v4 `parseCandidate` function to get an abstract
definition of the candidate rule that we can operate on. _This will
likely need to change in the future as we need to fork `parseCandidate`
for v3 specific syntax_.
Additionally, we're inlining a `printCandidate` function that can
stringify the abstract `Candidate` type. It is not guaranteed that this
is an identity function since some information can be lost during the
parse step. This is not a problem though, because migrations will only
run selectively and if none of the selectors trigger, the candidates are
not updated. h/t to @RobinMalfait for providing the printer.
So the overall flow of a migration looks like this:
- Scan the config file for `content` files
- Use Oxide to extract a list of candidate and their positions from
these `content` files
- Run a few migrations that operate on the `Candidate` abstract type.
- Print the updated `Candidate` back into the original `content` file.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-09-25 16:20:14 +02:00
|
|
|
version: link:../../crates/node
|
2024-10-22 17:41:50 +00:00
|
|
|
dedent:
|
2026-05-21 17:58:55 +02:00
|
|
|
specifier: 'catalog:'
|
2026-04-24 21:21:12 +02:00
|
|
|
version: 1.7.2
|
2024-09-18 16:45:43 +02:00
|
|
|
enhanced-resolve:
|
2026-05-21 17:58:55 +02:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 5.24.5
|
2024-09-18 16:45:43 +02:00
|
|
|
globby:
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: ^16.2.2
|
|
|
|
|
version: 16.2.2
|
Template migrations: Migrate v3 prefixes to v4 (#14557)
This PR adds a new migration that can migrate Tailwind CSS v3 style
prefixes into Tailwind CSS v4.
The migration is split into three separate pieces of work:
1. Firstly, we need to read the full JavaScript config to get the _old_
prefix option. This is necessary because in v4, we will not allow things
like custom-separators for the prefix. From this option we will then try
and compute a new prefix (in 90% of the cases this is going to just
remove the trailing `-` but it can also work in more complex cases).
2. Then we migrate all Candidates. The important thing here is that we
need to operate on the raw candidate string because by relying on
`parseCandidate` (which we do for all other migrations) would not work,
as the candidates are not valid in v4 syntax. More on that in a bit.
3. Lastly we also make sure to update the CSS config to include the new
prefix. This is done by prepending the prefix option like so:
```css
@import "tailwindcss" prefix(tw);
```
### Migrating candidates
The main difference between v3 prefixes and v4 prefixes is that in v3,
the prefix was _part of the utility_ where as in v4 it is _always in
front of the CSS class.
So, for example, this candidate in v3:
```
hover:-tw-mr-4
```
Would be converted to the following in v4:
```
tw:hover:-mr-4
```
Since the first example _won't parse as a valid Candidate in v4, as the
`tw-mr` utility does not exist, we have to operate on the raw candidate
string first. To do this I created a fork of the `parseCandidate`
function _without any validation of utilities or variants_. This is used
to identify part of the candidate that is the `base` and then ensuring
the `base` starts with the old prefix. We then remove this to create an
"unprefixed" candidate that we validate against a version of the
DesignSystem _with no prefixes configured_. If the variant is valid this
way, we can then print it again with the `DesignSystem` that has the new
prefix to get the migrated version.
Since we set up the `DesignSystem` to include the new prefix, we can
also be certain that migrations that happen afterwards would still
disqualify candidates that aren't valid according to the new prefix
policy. This does mean we need to have the prefix fixup be the first
step in our pipeline.
One interesting bit is that in v3, arbitrary properties did not require
prefixes where as in v4 they do. So the following candidate:
```
[color:red]
```
Will be converted to:
```
tw:[color:red]
```
2024-10-01 18:04:08 +02:00
|
|
|
jiti:
|
2026-05-13 12:02:13 +02:00
|
|
|
specifier: ^2.7.0
|
|
|
|
|
version: 2.7.0
|
2024-09-18 16:45:43 +02:00
|
|
|
mri:
|
|
|
|
|
specifier: ^1.2.0
|
|
|
|
|
version: 1.2.0
|
|
|
|
|
picocolors:
|
2024-10-24 11:25:50 +02:00
|
|
|
specifier: ^1.1.1
|
|
|
|
|
version: 1.1.1
|
2024-09-18 16:45:43 +02:00
|
|
|
postcss:
|
2026-05-21 17:58:55 +02:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 8.5.25
|
2024-09-18 16:45:43 +02:00
|
|
|
postcss-import:
|
2025-06-24 09:57:35 -04:00
|
|
|
specifier: ^16.1.1
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 16.1.1(postcss@8.5.25)
|
Add CSS codemods for migrating `@layer utilities` (#14455)
This PR adds CSS codemods for migrating existing `@layer utilities` to
`@utility` directives.
This PR has the ability to migrate the following cases:
---
The most basic case is when you want to migrate a simple class to a
utility directive.
Input:
```css
@layer utilities {
.foo {
color: red;
}
.bar {
color: blue;
}
}
```
Output:
```css
@utility foo {
color: red;
}
@utility bar {
color: blue;
}
```
You'll notice that the class `foo` will be used as the utility name, the
declarations (and the rest of the body of the rule) will become the body
of the `@utility` definition.
---
In v3, every class in a selector will become a utility. To correctly
migrate this to `@utility` directives, we have to register each class in
the selector and generate `n` utilities.
We can use nesting syntax, and replace the current class with `&` to
ensure that the final result behaves the same.
Input:
```css
@layer utilities {
.foo .bar .baz {
color: red;
}
}
```
Output:
```css
@utility foo {
& .bar .baz {
color: red;
}
}
@utility bar {
.foo & .baz {
color: red;
}
}
@utility .baz {
.foo .bar & {
color: red;
}
}
```
In this case, it could be that you know that some of them will never be
used as a utility (e.g.: `hover:bar`), but then you can safely remove
them.
---
Even classes inside of `:has(…)` will become a utility. The only
exception to the rule is that we don't do it for `:not(…)`.
Input:
```css
@layer utilities {
.foo .bar:not(.qux):has(.baz) {
display: none;
}
}
```
Output:
```css
@utility foo {
& .bar:not(.qux):has(.baz) {
display: none;
}
}
@utility bar {
.foo &:not(.qux):has(.baz) {
display: none;
}
}
@utility baz {
.foo .bar:not(.qux):has(&) {
display: none;
}
}
```
Notice that there is no `@utility qux` because it was used inside of
`:not(…)`.
---
When classes are nested inside at-rules, then these classes will also
become utilities. However, the `@utility <name>` will be at the top and
the at-rules will live inside of it. If there are multiple classes
inside a shared at-rule, then the at-rule will be duplicated for each
class.
Let's look at an example to make it more clear:
Input:
```css
@layer utilities {
@media (min-width: 640px) {
.foo {
color: red;
}
.bar {
color: blue;
}
@media (min-width: 1024px) {
.baz {
color: green;
}
@media (min-width: 1280px) {
.qux {
color: yellow;
}
}
}
}
}
```
Output:
```css
@utility foo {
@media (min-width: 640px) {
color: red;
}
}
@utility bar {
@media (min-width: 640px) {
color: blue;
}
}
@utility baz {
@media (min-width: 640px) {
@media (min-width: 1024px) {
color: green;
}
}
}
@utility qux {
@media (min-width: 640px) {
@media (min-width: 1024px) {
@media (min-width: 1280px) {
color: yellow;
}
}
}
}
```
---
When classes result in multiple `@utility` directives with the same
name, then the definitions will be merged together.
Input:
```css
@layer utilities {
.no-scrollbar::-webkit-scrollbar {
display: none;
}
.no-scrollbar {
-ms-overflow-style: none;
scrollbar-width: none;
}
}
```
Intermediate representation:
```css
@utility no-scrollbar {
&::-webkit-scrollbar {
display: none;
}
}
@utility no-scrollbar {
-ms-overflow-style: none;
scrollbar-width: none;
}
```
Output:
```css
@utility no-scrollbar {
&::-webkit-scrollbar {
display: none;
}
-ms-overflow-style: none;
scrollbar-width: none
}
```
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-09-24 18:17:09 +02:00
|
|
|
postcss-selector-parser:
|
2026-06-19 13:11:16 +02:00
|
|
|
specifier: ^7.1.4
|
|
|
|
|
version: 7.1.4
|
Add CSS codemods for migrating `@layer utilities` (#14455)
This PR adds CSS codemods for migrating existing `@layer utilities` to
`@utility` directives.
This PR has the ability to migrate the following cases:
---
The most basic case is when you want to migrate a simple class to a
utility directive.
Input:
```css
@layer utilities {
.foo {
color: red;
}
.bar {
color: blue;
}
}
```
Output:
```css
@utility foo {
color: red;
}
@utility bar {
color: blue;
}
```
You'll notice that the class `foo` will be used as the utility name, the
declarations (and the rest of the body of the rule) will become the body
of the `@utility` definition.
---
In v3, every class in a selector will become a utility. To correctly
migrate this to `@utility` directives, we have to register each class in
the selector and generate `n` utilities.
We can use nesting syntax, and replace the current class with `&` to
ensure that the final result behaves the same.
Input:
```css
@layer utilities {
.foo .bar .baz {
color: red;
}
}
```
Output:
```css
@utility foo {
& .bar .baz {
color: red;
}
}
@utility bar {
.foo & .baz {
color: red;
}
}
@utility .baz {
.foo .bar & {
color: red;
}
}
```
In this case, it could be that you know that some of them will never be
used as a utility (e.g.: `hover:bar`), but then you can safely remove
them.
---
Even classes inside of `:has(…)` will become a utility. The only
exception to the rule is that we don't do it for `:not(…)`.
Input:
```css
@layer utilities {
.foo .bar:not(.qux):has(.baz) {
display: none;
}
}
```
Output:
```css
@utility foo {
& .bar:not(.qux):has(.baz) {
display: none;
}
}
@utility bar {
.foo &:not(.qux):has(.baz) {
display: none;
}
}
@utility baz {
.foo .bar:not(.qux):has(&) {
display: none;
}
}
```
Notice that there is no `@utility qux` because it was used inside of
`:not(…)`.
---
When classes are nested inside at-rules, then these classes will also
become utilities. However, the `@utility <name>` will be at the top and
the at-rules will live inside of it. If there are multiple classes
inside a shared at-rule, then the at-rule will be duplicated for each
class.
Let's look at an example to make it more clear:
Input:
```css
@layer utilities {
@media (min-width: 640px) {
.foo {
color: red;
}
.bar {
color: blue;
}
@media (min-width: 1024px) {
.baz {
color: green;
}
@media (min-width: 1280px) {
.qux {
color: yellow;
}
}
}
}
}
```
Output:
```css
@utility foo {
@media (min-width: 640px) {
color: red;
}
}
@utility bar {
@media (min-width: 640px) {
color: blue;
}
}
@utility baz {
@media (min-width: 640px) {
@media (min-width: 1024px) {
color: green;
}
}
}
@utility qux {
@media (min-width: 640px) {
@media (min-width: 1024px) {
@media (min-width: 1280px) {
color: yellow;
}
}
}
}
```
---
When classes result in multiple `@utility` directives with the same
name, then the definitions will be merged together.
Input:
```css
@layer utilities {
.no-scrollbar::-webkit-scrollbar {
display: none;
}
.no-scrollbar {
-ms-overflow-style: none;
scrollbar-width: none;
}
}
```
Intermediate representation:
```css
@utility no-scrollbar {
&::-webkit-scrollbar {
display: none;
}
}
@utility no-scrollbar {
-ms-overflow-style: none;
scrollbar-width: none;
}
```
Output:
```css
@utility no-scrollbar {
&::-webkit-scrollbar {
display: none;
}
-ms-overflow-style: none;
scrollbar-width: none
}
```
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-09-24 18:17:09 +02:00
|
|
|
prettier:
|
2025-02-10 10:54:45 +01:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 3.9.6
|
Ensure `@tailwindcss/upgrade` runs on Tailwind CSS v4 projects and is idempotent (#17717)
This PR ensures that the `@tailwindcss/upgrade` tool works on existing
Tailwind CSS v4 projects. This PR also ensures that the upgrade tool is
idempotent, meaning that it can be run multiple times and it should
result in the same output.
One awesome feature this unlocks is that you can run the upgrade tool on
your codebase at any time and upgrade classes if you still have some
legacy syntaxes, such as `bg-[var(--my-color)]`, in your muscle memory.
One small note: If something changed in the first run, re-running will
not work immediately because your git repository will not be clean and
the upgrade tool requires your git repo to be clean. But once you
verified and committed your changes, the upgrade tool will be
idempotent.
Idempotency is guaranteed by ensuring that some migrations are skipped
by checking what version of Tailwind CSS you are on _before_ the version
is upgraded.
For the Tailwind CSS version: We will resolve `tailwindcss` itself to
know the _actual_ version that is installed (the one resolved from
`node_modules`). Not the one available in your package.json. Your
`package.json` could be out of sync if you reverted changes but didn't
run `npm install` yet.
Back to Idempotency:
For example, we have migrations where we change the variant order of
stacked variants. If we would run these migrations every time you run
the upgrade tool then we would be flip-flopping the order every run.
See: https://tailwindcss.com/docs/upgrade-guide#variant-stacking-order
Another example is where we rename some utilities. For example, we
rename:
| Before | After |
| ----------- | ----------- |
| `shadow` | `shadow-sm` |
| `shadow-sm` | `shadow-xs` |
Notice how we have `shadow-sm` in both the `before` and `after` column.
If we would run the upgrade tool again, then we would eventually migrate
your original `shadow` to `shadow-sm` (first run) and then to
`shadow-xs` (second run). Which would result in the wrong shadow.
See: https://tailwindcss.com/docs/upgrade-guide#renamed-utilities
---
The order of upgrade steps changed a bit as well to make the internals
are easier to work with and reason about.
1. Find CSS files
2. Link JS config files (if you are in a Tailwind CSS v3 project)
3. Migrate the JS config files (if you are in a Tailwind CSS v3 project)
4. Upgrade Tailwind CSS to v4 (or the latest version at that point)
5. Migrate the stylesheets (we used to migrate the source files first)
6. Migrate the source files
This is done so that step 5 and 6 will always operate on a Tailwind CSS
v4 project and we don't need to check the version number again. This is
also necessary because your CSS file will now very likely contain
`@import "tailwindcss";` which doesn't exist in Tailwind CSS v3.
This also means that we can rely on the same internals that Tailwind CSS
actually uses for locating the source files. We will use
`@tailwindcss/oxide`'s scanner to find the source files (and it also
keeps your custom `@source` directives into account).
This PR also introduces a few actual migrations related to recent
features and changes we shipped.
1. We migrate deprecated classes to their new names:
| Before | After |
| --------------------- | --------------------- |
| `bg-left-top` | `bg-top-left` |
| `bg-left-bottom` | `bg-bottom-left` |
| `bg-right-top` | `bg-top-right` |
| `bg-right-bottom` | `bg-bottom-right` |
| `object-left-top` | `object-top-left` |
| `object-left-bottom` | `object-bottom-left` |
| `object-right-top` | `object-top-right` |
| `object-right-bottom` | `object-bottom-right` |
Introduced in:
- https://github.com/tailwindlabs/tailwindcss/pull/17378
- https://github.com/tailwindlabs/tailwindcss/pull/17437
2. We migrate simple arbitrary variants to their dedicated variant:
| Before | After |
| ----------------------- | ------------------- |
| `[&:user-valid]:flex` | `user-valid:flex` |
| `[&:user-invalid]:flex` | `user-invalid:flex` |
Introduced in:
- https://github.com/tailwindlabs/tailwindcss/pull/12370
3. We migrate `@media` variants to their dedicated variant:
| Before | After |
| ----------------------------------------------------- |
------------------------- |
| `[@media_print]:flex` | `print:flex` |
| `[@media(prefers-reduced-motion:no-preference)]:flex` |
`motion-safe:flex` |
| `[@media(prefers-reduced-motion:reduce)]:flex` | `motion-reduce:flex`
|
| `[@media(prefers-contrast:more)]:flex` | `contrast-more:flex` |
| `[@media(prefers-contrast:less)]:flex` | `contrast-less:flex` |
| `[@media(orientation:portrait)]:flex` | `portrait:flex` |
| `[@media(orientation:landscape)]:flex` | `landscape:flex` |
| `[@media(forced-colors:active)]:flex` | `forced-colors:flex` |
| `[@media(inverted-colors:inverted)]:flex` | `inverted-colors:flex` |
| `[@media(pointer:none)]:flex` | `pointer-none:flex` |
| `[@media(pointer:coarse)]:flex` | `pointer-coarse:flex` |
| `[@media(pointer:fine)]:flex` | `pointer-fine:flex` |
| `[@media(any-pointer:none)]:flex` | `any-pointer-none:flex` |
| `[@media(any-pointer:coarse)]:flex` | `any-pointer-coarse:flex` |
| `[@media(any-pointer:fine)]:flex` | `any-pointer-fine:flex` |
| `[@media(scripting:none)]:flex` | `noscript:flex` |
The new variants related to `inverted-colors`, `pointer`, `any-pointer`
and `scripting` were introduced in:
- https://github.com/tailwindlabs/tailwindcss/pull/11693
- https://github.com/tailwindlabs/tailwindcss/pull/16946
- https://github.com/tailwindlabs/tailwindcss/pull/11929
- https://github.com/tailwindlabs/tailwindcss/pull/17431
This also applies to the `not` case, e.g.:
| Before | After |
| --------------------------------------------------------- |
----------------------------- |
| `[@media_not_print]:flex` | `not-print:flex` |
| `[@media_not(prefers-reduced-motion:no-preference)]:flex` |
`not-motion-safe:flex` |
| `[@media_not(prefers-reduced-motion:reduce)]:flex` |
`not-motion-reduce:flex` |
| `[@media_not(prefers-contrast:more)]:flex` | `not-contrast-more:flex`
|
| `[@media_not(prefers-contrast:less)]:flex` | `not-contrast-less:flex`
|
| `[@media_not(orientation:portrait)]:flex` | `not-portrait:flex` |
| `[@media_not(orientation:landscape)]:flex` | `not-landscape:flex` |
| `[@media_not(forced-colors:active)]:flex` | `not-forced-colors:flex` |
| `[@media_not(inverted-colors:inverted)]:flex` |
`not-inverted-colors:flex` |
| `[@media_not(pointer:none)]:flex` | `not-pointer-none:flex` |
| `[@media_not(pointer:coarse)]:flex` | `not-pointer-coarse:flex` |
| `[@media_not(pointer:fine)]:flex` | `not-pointer-fine:flex` |
| `[@media_not(any-pointer:none)]:flex` | `not-any-pointer-none:flex` |
| `[@media_not(any-pointer:coarse)]:flex` |
`not-any-pointer-coarse:flex` |
| `[@media_not(any-pointer:fine)]:flex` | `not-any-pointer-fine:flex` |
| `[@media_not(scripting:none)]:flex` | `not-noscript:flex` |
For each candidate, we run a set of upgrade migrations. If at the end of
the migrations the original candidate is still the same as the new
candidate, then we will parse & print the candidate one more time to
pretty print into consistent classes. Luckily parsing is cached so there
is no real downside overhead.
Consistency (especially with arbitrary variants and values) will reduce
your CSS file because there will be fewer "versions" of your class.
Concretely, the pretty printing will apply changes such as:
| Before | After |
| ---------------------- | ----------------- |
| `bg-[var(--my-color)]` | `bg-(--my-color)` |
| `bg-[rgb(0,_0,_0)]` | `bg-[rgb(0,0,0)]` |
Another big important reason for this change is that these classes on
their own
would have been migrated _if_ another migration was relevant for this
candidate.
This means that there are were some inconsistencies. E.g.:
| Before | After | Reason |
| ----------------------- | ---------------------- |
------------------------------------ |
| `!bg-[var(--my-color)]` | `bg-(--my-color)!` | Because the `!` is in
the wrong spot |
| `bg-[var(--my-color)]` | `bg-[var(--my-color)]` | Because no
migrations rand |
As you can see, the way the `--my-color` variable is used, is different.
This
changes will make sure it will now always be consistent:
| Before | After |
| ----------------------- | ---------------------- |
| `!bg-[var(--my-color)]` | `bg-(--my-color)!` |
| `bg-[var(--my-color)]` | `bg-(--my-color)` |
Yay!
Of course, if you don't want these more cosmetic changes, you can always
ignore the upgrade and revert these changes and only commit the changes
you want.
# Test plan
- All existing tests still pass.
- But I had to delete 1 test (we tested that Tailwind CSS v3 was
required).
- And had to mock the `version.isMajor` call to ensure we run the
individual migration tests correctly.
- Added new tests to test:
1. Migrating Tailwind CSS v4 projects works
1. Idempotency of the upgrade tool
[ci-all]
2025-04-22 17:10:46 +02:00
|
|
|
semver:
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: ^7.8.5
|
|
|
|
|
version: 7.8.5
|
2024-09-18 16:45:43 +02:00
|
|
|
tailwindcss:
|
Ensure clients pin the `tailwindcss` version (#15011)
We noticed that in the current alpha 34 release, the `package.json` file
of the `@tailwindcss/node` package only defines `tailwindcss` as a dev
dependency. This makes it very easy for version mismatches to happen
when a v3 version (or an earlier v4 alpha for that matter) was installed
in the same project:
```json
{
"name": "@tailwindcss/node",
"version": "4.0.0-alpha.34",
"description": "A utility-first CSS framework for rapidly building custom user interfaces.",
"license": "MIT",
"repository": {
"type": "git",
"url": "https://github.com/tailwindlabs/tailwindcss.git",
"directory": "packages/@tailwindcss-node"
},
"bugs": "https://github.com/tailwindlabs/tailwindcss/issues",
"homepage": "https://tailwindcss.com",
"files": [
"dist/"
],
"publishConfig": {
"provenance": true,
"access": "public"
},
"exports": {
".": {
"types": "./dist/index.d.ts",
"import": "./dist/index.mjs",
"require": "./dist/index.js"
},
"./require-cache": {
"types": "./dist/require-cache.d.ts",
"default": "./dist/require-cache.js"
},
"./esm-cache-loader": {
"types": "./dist/esm-cache.loader.d.mts",
"default": "./dist/esm-cache.loader.mjs"
}
},
"devDependencies": {
"tailwindcss": "4.0.0-alpha.34"
},
"dependencies": {
"enhanced-resolve": "^5.17.1",
"jiti": "^2.0.0-beta.3"
},
"scripts": {
"build": "tsup-node",
"dev": "pnpm run build -- --watch"
}
}
```
Furthermore, we were trying to fix issues where our integration test
setup could not install `tailwindcss@3` because of how we did pnpm
overrides.
This PR fixes this by:
- Ensuring every client that calls into `tailwindcss` core marks it as a
version-pinned dependency. You are still required to install
`tailwindcss` in your project along side a client (e.g.
`@tailwindcss/vite`) but we now only use your installed version for
importing the respective `.css` files. For the core logic, we are now
requiring each package to use `tailwindcss` at the same version. This
should help resolve issues like
https://github.com/tailwindlabs/tailwindcss/discussions/14652
- We tried to eliminate the dependency on `tailwindcss` from the
`@tailwindcss/upgrade` package. Unfortunately this is not possible to do
right now because we need to load the CSS files from v4 to create the
right environment. In a future version we could bundle the required CSS
files with `@tailwidncss/upgrade` but it doesn't seem necessary for now.
- We then changed our integration test overrides to only override the
`tailwindcss` package that are dependencies of the known list of
packages that we have `tailwindcss` dependencies on: `@tailwindcss/node`
and `@tailwindcss/upgrade`. This ensures that we can install v3 of
`tailwindcss` in the integration tests and it will work. Something we
want to do for some upgrade tests.
# Test plan
Integration work again. Furthermore we added a quick setup with the CLI
using the local tarballs and ensured it works:
```bash
pnpm init
pnpm install ../../tailwindcss/dist/tailwindcss-cli.tgz
pnpm install ../../tailwindcss/dist/tailwindcss.tgz
echo '@import "tailwindcss";' > index.css
echo '<div class="underline"></div>' > index.html
pnpm tailwindcss -i index.css -o out.css
cat out.css
```
2024-11-15 17:18:48 +01:00
|
|
|
specifier: workspace:*
|
2024-09-18 16:45:43 +02:00
|
|
|
version: link:../tailwindcss
|
2024-10-14 17:45:36 +02:00
|
|
|
tree-sitter:
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: ^0.25.1
|
|
|
|
|
version: 0.25.1
|
2024-10-14 17:45:36 +02:00
|
|
|
tree-sitter-typescript:
|
2024-11-18 10:23:22 +01:00
|
|
|
specifier: ^0.23.2
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 0.23.2(tree-sitter@0.25.1)
|
2024-09-18 16:45:43 +02:00
|
|
|
devDependencies:
|
|
|
|
|
'@types/node':
|
|
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 22.20.1
|
2024-09-18 16:45:43 +02:00
|
|
|
'@types/postcss-import':
|
|
|
|
|
specifier: ^14.0.3
|
|
|
|
|
version: 14.0.3
|
Ensure `@tailwindcss/upgrade` runs on Tailwind CSS v4 projects and is idempotent (#17717)
This PR ensures that the `@tailwindcss/upgrade` tool works on existing
Tailwind CSS v4 projects. This PR also ensures that the upgrade tool is
idempotent, meaning that it can be run multiple times and it should
result in the same output.
One awesome feature this unlocks is that you can run the upgrade tool on
your codebase at any time and upgrade classes if you still have some
legacy syntaxes, such as `bg-[var(--my-color)]`, in your muscle memory.
One small note: If something changed in the first run, re-running will
not work immediately because your git repository will not be clean and
the upgrade tool requires your git repo to be clean. But once you
verified and committed your changes, the upgrade tool will be
idempotent.
Idempotency is guaranteed by ensuring that some migrations are skipped
by checking what version of Tailwind CSS you are on _before_ the version
is upgraded.
For the Tailwind CSS version: We will resolve `tailwindcss` itself to
know the _actual_ version that is installed (the one resolved from
`node_modules`). Not the one available in your package.json. Your
`package.json` could be out of sync if you reverted changes but didn't
run `npm install` yet.
Back to Idempotency:
For example, we have migrations where we change the variant order of
stacked variants. If we would run these migrations every time you run
the upgrade tool then we would be flip-flopping the order every run.
See: https://tailwindcss.com/docs/upgrade-guide#variant-stacking-order
Another example is where we rename some utilities. For example, we
rename:
| Before | After |
| ----------- | ----------- |
| `shadow` | `shadow-sm` |
| `shadow-sm` | `shadow-xs` |
Notice how we have `shadow-sm` in both the `before` and `after` column.
If we would run the upgrade tool again, then we would eventually migrate
your original `shadow` to `shadow-sm` (first run) and then to
`shadow-xs` (second run). Which would result in the wrong shadow.
See: https://tailwindcss.com/docs/upgrade-guide#renamed-utilities
---
The order of upgrade steps changed a bit as well to make the internals
are easier to work with and reason about.
1. Find CSS files
2. Link JS config files (if you are in a Tailwind CSS v3 project)
3. Migrate the JS config files (if you are in a Tailwind CSS v3 project)
4. Upgrade Tailwind CSS to v4 (or the latest version at that point)
5. Migrate the stylesheets (we used to migrate the source files first)
6. Migrate the source files
This is done so that step 5 and 6 will always operate on a Tailwind CSS
v4 project and we don't need to check the version number again. This is
also necessary because your CSS file will now very likely contain
`@import "tailwindcss";` which doesn't exist in Tailwind CSS v3.
This also means that we can rely on the same internals that Tailwind CSS
actually uses for locating the source files. We will use
`@tailwindcss/oxide`'s scanner to find the source files (and it also
keeps your custom `@source` directives into account).
This PR also introduces a few actual migrations related to recent
features and changes we shipped.
1. We migrate deprecated classes to their new names:
| Before | After |
| --------------------- | --------------------- |
| `bg-left-top` | `bg-top-left` |
| `bg-left-bottom` | `bg-bottom-left` |
| `bg-right-top` | `bg-top-right` |
| `bg-right-bottom` | `bg-bottom-right` |
| `object-left-top` | `object-top-left` |
| `object-left-bottom` | `object-bottom-left` |
| `object-right-top` | `object-top-right` |
| `object-right-bottom` | `object-bottom-right` |
Introduced in:
- https://github.com/tailwindlabs/tailwindcss/pull/17378
- https://github.com/tailwindlabs/tailwindcss/pull/17437
2. We migrate simple arbitrary variants to their dedicated variant:
| Before | After |
| ----------------------- | ------------------- |
| `[&:user-valid]:flex` | `user-valid:flex` |
| `[&:user-invalid]:flex` | `user-invalid:flex` |
Introduced in:
- https://github.com/tailwindlabs/tailwindcss/pull/12370
3. We migrate `@media` variants to their dedicated variant:
| Before | After |
| ----------------------------------------------------- |
------------------------- |
| `[@media_print]:flex` | `print:flex` |
| `[@media(prefers-reduced-motion:no-preference)]:flex` |
`motion-safe:flex` |
| `[@media(prefers-reduced-motion:reduce)]:flex` | `motion-reduce:flex`
|
| `[@media(prefers-contrast:more)]:flex` | `contrast-more:flex` |
| `[@media(prefers-contrast:less)]:flex` | `contrast-less:flex` |
| `[@media(orientation:portrait)]:flex` | `portrait:flex` |
| `[@media(orientation:landscape)]:flex` | `landscape:flex` |
| `[@media(forced-colors:active)]:flex` | `forced-colors:flex` |
| `[@media(inverted-colors:inverted)]:flex` | `inverted-colors:flex` |
| `[@media(pointer:none)]:flex` | `pointer-none:flex` |
| `[@media(pointer:coarse)]:flex` | `pointer-coarse:flex` |
| `[@media(pointer:fine)]:flex` | `pointer-fine:flex` |
| `[@media(any-pointer:none)]:flex` | `any-pointer-none:flex` |
| `[@media(any-pointer:coarse)]:flex` | `any-pointer-coarse:flex` |
| `[@media(any-pointer:fine)]:flex` | `any-pointer-fine:flex` |
| `[@media(scripting:none)]:flex` | `noscript:flex` |
The new variants related to `inverted-colors`, `pointer`, `any-pointer`
and `scripting` were introduced in:
- https://github.com/tailwindlabs/tailwindcss/pull/11693
- https://github.com/tailwindlabs/tailwindcss/pull/16946
- https://github.com/tailwindlabs/tailwindcss/pull/11929
- https://github.com/tailwindlabs/tailwindcss/pull/17431
This also applies to the `not` case, e.g.:
| Before | After |
| --------------------------------------------------------- |
----------------------------- |
| `[@media_not_print]:flex` | `not-print:flex` |
| `[@media_not(prefers-reduced-motion:no-preference)]:flex` |
`not-motion-safe:flex` |
| `[@media_not(prefers-reduced-motion:reduce)]:flex` |
`not-motion-reduce:flex` |
| `[@media_not(prefers-contrast:more)]:flex` | `not-contrast-more:flex`
|
| `[@media_not(prefers-contrast:less)]:flex` | `not-contrast-less:flex`
|
| `[@media_not(orientation:portrait)]:flex` | `not-portrait:flex` |
| `[@media_not(orientation:landscape)]:flex` | `not-landscape:flex` |
| `[@media_not(forced-colors:active)]:flex` | `not-forced-colors:flex` |
| `[@media_not(inverted-colors:inverted)]:flex` |
`not-inverted-colors:flex` |
| `[@media_not(pointer:none)]:flex` | `not-pointer-none:flex` |
| `[@media_not(pointer:coarse)]:flex` | `not-pointer-coarse:flex` |
| `[@media_not(pointer:fine)]:flex` | `not-pointer-fine:flex` |
| `[@media_not(any-pointer:none)]:flex` | `not-any-pointer-none:flex` |
| `[@media_not(any-pointer:coarse)]:flex` |
`not-any-pointer-coarse:flex` |
| `[@media_not(any-pointer:fine)]:flex` | `not-any-pointer-fine:flex` |
| `[@media_not(scripting:none)]:flex` | `not-noscript:flex` |
For each candidate, we run a set of upgrade migrations. If at the end of
the migrations the original candidate is still the same as the new
candidate, then we will parse & print the candidate one more time to
pretty print into consistent classes. Luckily parsing is cached so there
is no real downside overhead.
Consistency (especially with arbitrary variants and values) will reduce
your CSS file because there will be fewer "versions" of your class.
Concretely, the pretty printing will apply changes such as:
| Before | After |
| ---------------------- | ----------------- |
| `bg-[var(--my-color)]` | `bg-(--my-color)` |
| `bg-[rgb(0,_0,_0)]` | `bg-[rgb(0,0,0)]` |
Another big important reason for this change is that these classes on
their own
would have been migrated _if_ another migration was relevant for this
candidate.
This means that there are were some inconsistencies. E.g.:
| Before | After | Reason |
| ----------------------- | ---------------------- |
------------------------------------ |
| `!bg-[var(--my-color)]` | `bg-(--my-color)!` | Because the `!` is in
the wrong spot |
| `bg-[var(--my-color)]` | `bg-[var(--my-color)]` | Because no
migrations rand |
As you can see, the way the `--my-color` variable is used, is different.
This
changes will make sure it will now always be consistent:
| Before | After |
| ----------------------- | ---------------------- |
| `!bg-[var(--my-color)]` | `bg-(--my-color)!` |
| `bg-[var(--my-color)]` | `bg-(--my-color)` |
Yay!
Of course, if you don't want these more cosmetic changes, you can always
ignore the upgrade and revert these changes and only commit the changes
you want.
# Test plan
- All existing tests still pass.
- But I had to delete 1 test (we tested that Tailwind CSS v3 was
required).
- And had to mock the `version.isMajor` call to ensure we run the
individual migration tests correctly.
- Added new tests to test:
1. Migrating Tailwind CSS v4 projects works
1. Idempotency of the upgrade tool
[ci-all]
2025-04-22 17:10:46 +02:00
|
|
|
'@types/semver':
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: ^7.8.0
|
|
|
|
|
version: 7.8.0
|
2026-07-30 15:45:51 -04:00
|
|
|
|
2024-03-05 14:23:26 +01:00
|
|
|
packages/@tailwindcss-vite:
|
|
|
|
|
dependencies:
|
2024-09-02 12:03:16 -04:00
|
|
|
'@tailwindcss/node':
|
2025-02-18 11:44:12 +01:00
|
|
|
specifier: workspace:*
|
2024-09-02 12:03:16 -04:00
|
|
|
version: link:../@tailwindcss-node
|
2024-03-05 14:23:26 +01:00
|
|
|
'@tailwindcss/oxide':
|
2025-02-18 11:44:12 +01:00
|
|
|
specifier: workspace:*
|
2024-03-23 14:00:48 +01:00
|
|
|
version: link:../../crates/node
|
2024-03-05 14:23:26 +01:00
|
|
|
tailwindcss:
|
Ensure clients pin the `tailwindcss` version (#15011)
We noticed that in the current alpha 34 release, the `package.json` file
of the `@tailwindcss/node` package only defines `tailwindcss` as a dev
dependency. This makes it very easy for version mismatches to happen
when a v3 version (or an earlier v4 alpha for that matter) was installed
in the same project:
```json
{
"name": "@tailwindcss/node",
"version": "4.0.0-alpha.34",
"description": "A utility-first CSS framework for rapidly building custom user interfaces.",
"license": "MIT",
"repository": {
"type": "git",
"url": "https://github.com/tailwindlabs/tailwindcss.git",
"directory": "packages/@tailwindcss-node"
},
"bugs": "https://github.com/tailwindlabs/tailwindcss/issues",
"homepage": "https://tailwindcss.com",
"files": [
"dist/"
],
"publishConfig": {
"provenance": true,
"access": "public"
},
"exports": {
".": {
"types": "./dist/index.d.ts",
"import": "./dist/index.mjs",
"require": "./dist/index.js"
},
"./require-cache": {
"types": "./dist/require-cache.d.ts",
"default": "./dist/require-cache.js"
},
"./esm-cache-loader": {
"types": "./dist/esm-cache.loader.d.mts",
"default": "./dist/esm-cache.loader.mjs"
}
},
"devDependencies": {
"tailwindcss": "4.0.0-alpha.34"
},
"dependencies": {
"enhanced-resolve": "^5.17.1",
"jiti": "^2.0.0-beta.3"
},
"scripts": {
"build": "tsup-node",
"dev": "pnpm run build -- --watch"
}
}
```
Furthermore, we were trying to fix issues where our integration test
setup could not install `tailwindcss@3` because of how we did pnpm
overrides.
This PR fixes this by:
- Ensuring every client that calls into `tailwindcss` core marks it as a
version-pinned dependency. You are still required to install
`tailwindcss` in your project along side a client (e.g.
`@tailwindcss/vite`) but we now only use your installed version for
importing the respective `.css` files. For the core logic, we are now
requiring each package to use `tailwindcss` at the same version. This
should help resolve issues like
https://github.com/tailwindlabs/tailwindcss/discussions/14652
- We tried to eliminate the dependency on `tailwindcss` from the
`@tailwindcss/upgrade` package. Unfortunately this is not possible to do
right now because we need to load the CSS files from v4 to create the
right environment. In a future version we could bundle the required CSS
files with `@tailwidncss/upgrade` but it doesn't seem necessary for now.
- We then changed our integration test overrides to only override the
`tailwindcss` package that are dependencies of the known list of
packages that we have `tailwindcss` dependencies on: `@tailwindcss/node`
and `@tailwindcss/upgrade`. This ensures that we can install v3 of
`tailwindcss` in the integration tests and it will work. Something we
want to do for some upgrade tests.
# Test plan
Integration work again. Furthermore we added a quick setup with the CLI
using the local tarballs and ensured it works:
```bash
pnpm init
pnpm install ../../tailwindcss/dist/tailwindcss-cli.tgz
pnpm install ../../tailwindcss/dist/tailwindcss.tgz
echo '@import "tailwindcss";' > index.css
echo '<div class="underline"></div>' > index.html
pnpm tailwindcss -i index.css -o out.css
cat out.css
```
2024-11-15 17:18:48 +01:00
|
|
|
specifier: workspace:*
|
2024-03-05 14:23:26 +01:00
|
|
|
version: link:../tailwindcss
|
|
|
|
|
devDependencies:
|
|
|
|
|
'@types/node':
|
2024-08-02 10:33:14 +02:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 22.20.1
|
2024-03-05 14:23:26 +01:00
|
|
|
vite:
|
2024-08-02 10:33:14 +02:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 8.2.0(@types/node@22.20.1)(esbuild@0.27.7)(jiti@2.7.0)(terser@5.48.0)(yaml@2.9.0)
|
2024-03-05 14:23:26 +01:00
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
packages/@tailwindcss-webpack:
|
|
|
|
|
dependencies:
|
|
|
|
|
'@alloc/quick-lru':
|
|
|
|
|
specifier: ^5.2.0
|
|
|
|
|
version: 5.2.0
|
2026-05-23 17:14:48 +08:00
|
|
|
'@rspack/core':
|
|
|
|
|
specifier: ^1.0.0 || ^2.0.0
|
|
|
|
|
version: 2.0.2(@swc/helpers@0.5.15)
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
'@tailwindcss/node':
|
|
|
|
|
specifier: workspace:*
|
|
|
|
|
version: link:../@tailwindcss-node
|
|
|
|
|
'@tailwindcss/oxide':
|
|
|
|
|
specifier: workspace:*
|
|
|
|
|
version: link:../../crates/node
|
|
|
|
|
tailwindcss:
|
|
|
|
|
specifier: workspace:*
|
|
|
|
|
version: link:../tailwindcss
|
|
|
|
|
devDependencies:
|
|
|
|
|
'@types/node':
|
|
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 22.20.1
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
webpack:
|
|
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 5.109.2(esbuild@0.27.7)(postcss@8.5.25)
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
|
2024-07-29 16:58:07 +02:00
|
|
|
packages/internal-example-plugin: {}
|
|
|
|
|
|
2024-03-05 14:23:26 +01:00
|
|
|
packages/tailwindcss:
|
|
|
|
|
devDependencies:
|
2025-08-12 15:52:35 +02:00
|
|
|
'@jridgewell/remapping':
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
specifier: ^2.3.5
|
2025-08-12 15:52:35 +02:00
|
|
|
version: 2.3.5
|
2024-03-05 14:23:26 +01:00
|
|
|
'@tailwindcss/oxide':
|
|
|
|
|
specifier: workspace:^
|
2024-03-23 14:00:48 +01:00
|
|
|
version: link:../../crates/node
|
2024-03-05 14:23:26 +01:00
|
|
|
'@types/node':
|
2024-08-02 10:33:14 +02:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 22.20.1
|
Resolve `@import` in core (#14446)
This PR brings `@import` resolution into Tailwind CSS core. This means
that our clients (PostCSS, Vite, and CLI) no longer need to depend on
`postcss` and `postcss-import` to resolve `@import`. Furthermore this
simplifies the handling of relative paths for `@source`, `@plugin`, or
`@config` in transitive CSS files (where the relative root should always
be relative to the CSS file that contains the directive). This PR also
fixes a plugin resolution bug where non-relative imports (e.g. directly
importing node modules like `@plugin '@tailwindcss/typography';`) would
not work in CSS files that are based in a different npm package.
### Resolving `@import`
The core of the `@import` resolution is inside
`packages/tailwindcss/src/at-import.ts`. There, to keep things
performant, we do a two-step process to resolve imports. Imagine the
following input CSS file:
```css
@import "tailwindcss/theme.css";
@import "tailwindcss/utilities.css";
```
Since our AST walks are synchronous, we will do a first traversal where
we start a loading request for each `@import` directive. Once all loads
are started, we will await the promise and do a second walk where we
actually replace the AST nodes with their resolved stylesheets. All of
this is recursive, so that `@import`-ed files can again `@import` other
files.
The core `@import` resolver also includes extensive test cases for
[various combinations of media query and supports conditionals as well
als layered
imports](https://developer.mozilla.org/en-US/docs/Web/CSS/@import).
When the same file is imported multiple times, the AST nodes are
duplicated but duplicate I/O is avoided on a per-file basis, so this
will only load one file, but include the `@theme` rules twice:
```css
@import "tailwindcss/theme.css";
@import "tailwindcss/theme.css";
```
### Adding a new `context` node to the AST
One limitation we had when working with the `postcss-import` plugin was
the need to do an additional traversal to rewrite relative `@source`,
`@plugin`, and `@config` directives. This was needed because we want
these paths to be relative to the CSS file that defines the directive
but when flattening a CSS file, this information is no longer part of
the stringifed CSS representation. We worked around this by rewriting
the content of these directives to be relative to the input CSS file,
which resulted in added complexity and caused a lot of issues with
Windows paths in the beginning.
Now that we are doing the `@import` resolution in core, we can use a
different data structure to persist this information. This PR adds a new
`context` node so that we can store arbitrary context like this inside
the Ast directly. This allows us to share information with the sub tree
_while doing the Ast walk_.
Here's an example of how the new `context` node can be used to share
information with subtrees:
```ts
const ast = [
rule('.foo', [decl('color', 'red')]),
context({ value: 'a' }, [
rule('.bar', [
decl('color', 'blue'),
context({ value: 'b' }, [
rule('.baz', [decl('color', 'green')]),
]),
]),
]),
]
walk(ast, (node, { context }) => {
if (node.kind !== 'declaration') return
switch (node.value) {
case 'red': assert(context.value === undefined)
case 'blue': assert(context.value === 'a')
case 'green': assert(context.value === 'b')
}
})
```
In core, we use this new Ast node specifically to persist the `base`
path of the current CSS file. We put the input CSS file `base` at the
root of the Ast and then overwrite the `base` on every `@import`
substitution.
### Removing the dependency on `postcss-import`
Now that we support `@import` resolution in core, our clients no longer
need a dependency on `postcss-import`. Furthermore, most dependencies
also don't need to know about `postcss` at all anymore (except the
PostCSS client, of course!).
This also means that our workaround for rewriting `@source`, the
`postcss-fix-relative-paths` plugin, can now go away as a shared
dependency between all of our clients. Note that we still have it for
the PostCSS plugin only, where it's possible that users already have
`postcss-import` running _before_ the `@tailwindcss/postcss` plugin.
Here's an example of the changes to the dependencies for our Vite client
✨ :
<img width="854" alt="Screenshot 2024-09-19 at 16 59 45"
src="https://github.com/user-attachments/assets/ae1f9d5f-d93a-4de9-9244-61af3aff1237">
### Performance
Since our Vite and CLI clients now no longer need to use `postcss` at
all, we have also measured a significant improvement to the initial
build times. For a small test setup that contains only a hand full of
files (nothing super-complex), we measured an improvement in the
**3.5x** range:
<img width="1334" alt="Screenshot 2024-09-19 at 14 52 49"
src="https://github.com/user-attachments/assets/06071fb0-7f2a-4de6-8ec8-f202d2cc78e5">
The code for this is in the commit history if you want to reproduce the
results. The test was based on the Vite client.
### Caveats
One thing to note is that we previously relied on finding specific
symbols in the input CSS to _bail out of Tailwind processing
completely_. E.g. if a file does not contain a `@tailwind` or `@apply`
directive, it can never be a Tailwind file.
Since we no longer have a string representation of the flattened CSS
file, we can no longer do this check. However, the current
implementation was already inconsistent with differences on the allowed
symbol list between our clients. Ideally, Tailwind CSS should figure out
wether a CSS file is a Tailwind CSS file. This, however, is left as an
improvement for a future API since it goes hand-in-hand with our planned
API changes for the core `tailwindcss` package.
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-09-23 17:05:55 +02:00
|
|
|
dedent:
|
2026-05-21 17:58:55 +02:00
|
|
|
specifier: 'catalog:'
|
2026-04-24 21:21:12 +02:00
|
|
|
version: 1.7.2
|
2024-03-13 17:25:16 +01:00
|
|
|
lightningcss:
|
2024-08-09 16:12:24 +02:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 1.33.0(patch_hash=1d4a8800d60d13d42887b88b3a86576df4b451670308145fb432ec8abbf40930)
|
Add support for source maps (#17775)
Closes #13694
Closes #13591
# Source Maps Support for Tailwind CSS
This PR adds support for source maps to Tailwind CSS v4 allowing us to
track where styles come from whether that be user CSS, imported
stylesheets, or generated utilities. This will improve debuggability in
browser dev tools and gives us a good foundation for producing better
error messages. I'll go over the details on how end users can enable
source maps, any limitations in our implementation, changes to the
internal `compile(…)` API, and some details and reasoning around the
implementation we chose.
## Usage
### CLI
Source maps can be enabled in the CLI by using the command line argument
`--map` which will generate an inline source map comment at the bottom
of your CSS. A separate file may be generated by passing a file name to
`--map`:
```bash
# Generates an inline source map
npx tailwindcss -i input.css -o output.css --map
# Generates a separate source map file
npx tailwindcss -i input.css -o output.css --map output.css.map
```
### PostCSS
Source maps are supported when using Tailwind as a PostCSS plugin *in
development mode only*. They may or may not be enabled by default
depending on your build tool. If they are not you may be able to
configure them within your PostCSS config:
```jsonc
// package.json
{
// …
"postcss": {
"map": { "inline": true },
"plugins": {
"@tailwindcss/postcss": {},
},
}
}
```
### Vite
Source maps are supported when using the Tailwind CSS Vite plugin in
*development mode only* by enabling the `css.devSourcemap` setting:
```js
import tailwindcss from "@tailwindcss/vite";
import { defineConfig } from "vite";
export default defineConfig({
plugins: [tailwindcss()],
css: {
devSourcemap: true,
},
})
```
Now when a CSS file is requested by the browser it'll have an inline
source map comment that the browser can use.
## Limitations
- Production build source maps are currently disabled due to a bug in
Lightning CSS. See
https://github.com/parcel-bundler/lightningcss/pull/971 for more
details.
- In Vite, minified CSS build source maps are not supported at all. See
https://github.com/vitejs/vite/issues/2830 for more details.
- In PostCSS, minified CSS source maps are not supported. This is due to
the complexity required around re-associating every AST node with a
location in the generated, optimized CSS. This complexity would also
have a non-trivial performance impact.
## Testing
Here's how to test the source map functionality in different
environments:
### Testing the CLI
1. Setup typical project that the CLI can use and with sources to scan.
```css
@import "tailwindcss";
@utilty my-custom-utility {
color: red;
}
/* to test `@apply` */
.card {
@apply bg-white text-center shadow-md;
}
```
2. Build with source maps:
```bash
bun /path/to/tailwindcss/packages/@tailwindcss-cli/src/index.ts --input input.css -o output.css --map
```
3. Open Chrome DevTools, inspect an element with utility classes, and
you should see rules pointing to `input.css` or
`node_modules/tailwindcss/index.css`
### Testing with Vite
Testing in Vite will require building and installing necessary files
under `dist/*.tgz`.
1. Create a Vite project and enable source maps in `vite.config.js`:
```js
import tailwindcss from "@tailwindcss/vite";
import { defineConfig } from "vite";
export default defineConfig({
plugins: [tailwindcss()],
css: {
// This line is required for them to work
devSourcemap: true,
},
})
```
2. Add a component that uses Tailwind classes and custom CSS:
```jsx
// ./src/app.jsx
export default function App() {
return (
<div className="bg-blue-500 my-custom-class">
Hello World
</div>
)
}
```
```css
/* ./src/styles.css */
@import "tailwindcss";
@utilty my-custom-utility {
color: red;
}
/* to test `@apply` */
.card {
@apply bg-white text-center shadow-md;
}
```
3. Run `npm run dev`, open DevTools, and inspect elements to verify
source mapping works for both utility classes and custom CSS.
### Testing with PostCSS CLI
1. Create a test file and update your PostCSS config:
```css
/* input.css */
@import "tailwindcss";
@layer components {
.card {
@apply p-6 rounded-lg shadow-lg;
}
}
```
```jsonc
// package.json
{
// …
"postcss": {
"map": {
"inline": true
},
"plugins": {
"/path/to/tailwindcss/packages/packages/@tailwindcss-postcss/src/index.ts": {}
}
}
}
```
2. Run PostCSS through Bun:
```bash
bunx --bun postcss ./src/index.css -o out.css
```
3. Inspect the output CSS - it should include an inline source map
comment at the bottom.
### Testing with PostCSS + Next.js
Testing in Next.js will require building and installing necessary files
under `dist/*.tgz`. However, I've not been able to get CSS source maps
to work in Next.js without this hack:
```js
const nextConfig: NextConfig = {
// next.js overwrites config.devtool so we prevent it from doing so
// please don't actually do this…
webpack: (config) =>
Object.defineProperty(config, "devtool", {
get: () => "inline-source-map",
set: () => {},
}),
};
```
This is definitely not supported and also doesn't work with turbopack.
This can be used to test them temporarily but I suspect that they just
don't work there.
### Manual source map analysis
You can analyze source maps using Evan Wallace's [Source Map
Visualization](https://evanw.github.io/source-map-visualization/) tool
which will help to verify the accuracy and quality of source maps. This
is what I used extensively while developing this implementation.
It'll help verify that custom, user CSS maps back to itself in the
input, that generated utilities all map back to `@tailwind utilities;`,
that source locations from imported files are also handled correctly,
etc… It also highlights the ranges of stuff so it's easy to see if there
are off-by-one errors.
It's easiest to use inline source maps with this tool because you can
take the CSS file and drop it on the page and it'll analyze it while
showing the file content.
If you're using Vite you'll want to access the CSS file with `?direct`
at the end so you don't get a JS module back.
## Implementation
The source map implementation follows the ECMA-426 specification and
includes several key components to aid in that goal:
### Source Location Tracking
Each emittable AST node in the compilation pipeline tracks two types of
source locations:
- `src`: Original source location - [source file, start offset, end
offset]
- `dst`: Generated source location - [output file, start offset, end
offset]
This dual tracking allows us to maintain mappings between the original
source and generated output for things like user CSS, generated
utilities, uses of `@apply`, and tracking theme variables.
It is important to note that source locations for nodes _never overlap_
within a file which helps simplify source map generation. As such each
type of node tracks a specific piece of itself rather than its entire
"block":
| Node | What a `SourceLocation` represents |
| ----------- |
---------------------------------------------------------------- |
| Style Rule | The selector |
| At Rule | Rule name and params, includes the `@` |
| Declaration | Property name and value, excludes the semicolon |
| Comment | The entire comment, includes the start `/*` and end `*/`
markers |
### Windows line endings when parsing CSS
Because our AST tracks nodes through offsets we must ensure that any
mutations to the file do *not* change the lenth of the string. We were
previously replacing `\r\n` with `\n` (see [filter code
points](https://drafts.csswg.org/css-syntax/#css-filter-code-points)
from the spec) — which changes the length of the string and all offsets
may end up incorrect. The CSS parser was updated to handle the CRLF
token directly by skipping over the `\r` and letting remaining code
handle `\n` as it did previously. Some additional tweaks were required
when "peeking" the input but those changes were fairly small.
### Tracking of imports
Source maps need paths to the actual imported stylesheets but the
resolve step for stylesheets happens inside the call to `loadStylesheet`
which make the file path unavailable to us. Because of this the
`loadStylesheet` API was augmented such that it has to return a `path`
property that we can then use to identify imported sources. I've also
made the same change to the `loadModule` API for consistency but nothing
currently uses this property.
The `path` property likely makes `base` redundant but elminating that
(if we even want to) is a future task.
### Optimizing the AST
Our optimization pass may intoduce some nodes, for example, fallbacks we
create for `@property`. These nodes are linked back to `@tailwind
utilities` as ultimately that is what is responsible for creating them.
### Line Offset Tables
A key component to our source map generation is the line offset table,
which was inspired by some ESBuild internals. It stores a sorted list of
offsets for the start of each line allowing us to translate offsets to
line/column `Position`s in `O(log N)` time and from `Position`s to
offsets in `O(1)` time. Creation of the table takes `O(N)` time.
This means that we can store code point offsets for source locations and
not have to worry about computing or tracking line/column numbers during
parsing and serialization. Only when a source map is generated do these
offsets need to be computed. This ensures the performance penalty when
not using source maps is minimal.
### Source Map Generation
The source map returned by `buildSourceMap()` is designed to follow the
[ECMA-426 spec](https://tc39.es/ecma426). Because that spec is not
completely finalized we consider the result of `buildSourceMap()` to be
internal API that may change as the spec chamges.
The produces source map is a "decoded" map such that all sources and
mappings are in an object graph. A library like `source-map-js` must be
used to convert this to an encoded source map of the right version where
mappings are encoded with base 64 VLQs.
Any specific integration (Vite, PostCSS, etc…) can then use
`toSourceMap()` from `@tailwindcss/node` to convert from the internal
source map to an spec-compliant encoded source map that can be
understood by other tools.
### Handling minification in Lightning
Since we use Lightning CSS for optimization, and it takes in an input
map, we generate an encoded source map that we then pass to lightning.
The output source map *from lighting itself* is then passed back in
during the second optimization pass. The final map is then passed from
lightning to the CLI (but not Vite or PostCSS — see the limitations
section for details).
In some cases we have to "fix up" the output CSS. When this happens we
use `magic-string` to do the replacement in a way that is trackable and
`@amppproject/remapping` to map that change back onto the original
source map. Once the need for these fix ups disappear these dependencies
can go away.
Notes:
- The accuracy of source maps run though lightning is reduced as it only
tracks on a per-rule level. This is sufficient enough for browser dev
tools so should be fine.
- Source maps during optimization do not function properly at this time
because of a bug in Lightning CSS regarding license comments. Once this
bug is fixed they will start working as expected.
### How source locations flow through the system
1. During initial CSS parsing, source locations are preserved.
2. During parsing these source locations are also mapped to the
destinations which supports an optimization for when no utilities are
generated.
3. Throughout the compilation process, transformations maintain source
location data
4. Generated utilities are explicitly pointed to `@tailwind utilities`
unless generated by `@apply`.
5. When optimization is enabled, source maps are remapped through
lightningcss
6. Final source maps are written in the requested format (inline or
separate file)
2025-05-08 16:29:49 -04:00
|
|
|
magic-string:
|
2026-08-04 13:55:03 +02:00
|
|
|
specifier: ^1.1.0
|
|
|
|
|
version: 1.1.0
|
Add support for source maps (#17775)
Closes #13694
Closes #13591
# Source Maps Support for Tailwind CSS
This PR adds support for source maps to Tailwind CSS v4 allowing us to
track where styles come from whether that be user CSS, imported
stylesheets, or generated utilities. This will improve debuggability in
browser dev tools and gives us a good foundation for producing better
error messages. I'll go over the details on how end users can enable
source maps, any limitations in our implementation, changes to the
internal `compile(…)` API, and some details and reasoning around the
implementation we chose.
## Usage
### CLI
Source maps can be enabled in the CLI by using the command line argument
`--map` which will generate an inline source map comment at the bottom
of your CSS. A separate file may be generated by passing a file name to
`--map`:
```bash
# Generates an inline source map
npx tailwindcss -i input.css -o output.css --map
# Generates a separate source map file
npx tailwindcss -i input.css -o output.css --map output.css.map
```
### PostCSS
Source maps are supported when using Tailwind as a PostCSS plugin *in
development mode only*. They may or may not be enabled by default
depending on your build tool. If they are not you may be able to
configure them within your PostCSS config:
```jsonc
// package.json
{
// …
"postcss": {
"map": { "inline": true },
"plugins": {
"@tailwindcss/postcss": {},
},
}
}
```
### Vite
Source maps are supported when using the Tailwind CSS Vite plugin in
*development mode only* by enabling the `css.devSourcemap` setting:
```js
import tailwindcss from "@tailwindcss/vite";
import { defineConfig } from "vite";
export default defineConfig({
plugins: [tailwindcss()],
css: {
devSourcemap: true,
},
})
```
Now when a CSS file is requested by the browser it'll have an inline
source map comment that the browser can use.
## Limitations
- Production build source maps are currently disabled due to a bug in
Lightning CSS. See
https://github.com/parcel-bundler/lightningcss/pull/971 for more
details.
- In Vite, minified CSS build source maps are not supported at all. See
https://github.com/vitejs/vite/issues/2830 for more details.
- In PostCSS, minified CSS source maps are not supported. This is due to
the complexity required around re-associating every AST node with a
location in the generated, optimized CSS. This complexity would also
have a non-trivial performance impact.
## Testing
Here's how to test the source map functionality in different
environments:
### Testing the CLI
1. Setup typical project that the CLI can use and with sources to scan.
```css
@import "tailwindcss";
@utilty my-custom-utility {
color: red;
}
/* to test `@apply` */
.card {
@apply bg-white text-center shadow-md;
}
```
2. Build with source maps:
```bash
bun /path/to/tailwindcss/packages/@tailwindcss-cli/src/index.ts --input input.css -o output.css --map
```
3. Open Chrome DevTools, inspect an element with utility classes, and
you should see rules pointing to `input.css` or
`node_modules/tailwindcss/index.css`
### Testing with Vite
Testing in Vite will require building and installing necessary files
under `dist/*.tgz`.
1. Create a Vite project and enable source maps in `vite.config.js`:
```js
import tailwindcss from "@tailwindcss/vite";
import { defineConfig } from "vite";
export default defineConfig({
plugins: [tailwindcss()],
css: {
// This line is required for them to work
devSourcemap: true,
},
})
```
2. Add a component that uses Tailwind classes and custom CSS:
```jsx
// ./src/app.jsx
export default function App() {
return (
<div className="bg-blue-500 my-custom-class">
Hello World
</div>
)
}
```
```css
/* ./src/styles.css */
@import "tailwindcss";
@utilty my-custom-utility {
color: red;
}
/* to test `@apply` */
.card {
@apply bg-white text-center shadow-md;
}
```
3. Run `npm run dev`, open DevTools, and inspect elements to verify
source mapping works for both utility classes and custom CSS.
### Testing with PostCSS CLI
1. Create a test file and update your PostCSS config:
```css
/* input.css */
@import "tailwindcss";
@layer components {
.card {
@apply p-6 rounded-lg shadow-lg;
}
}
```
```jsonc
// package.json
{
// …
"postcss": {
"map": {
"inline": true
},
"plugins": {
"/path/to/tailwindcss/packages/packages/@tailwindcss-postcss/src/index.ts": {}
}
}
}
```
2. Run PostCSS through Bun:
```bash
bunx --bun postcss ./src/index.css -o out.css
```
3. Inspect the output CSS - it should include an inline source map
comment at the bottom.
### Testing with PostCSS + Next.js
Testing in Next.js will require building and installing necessary files
under `dist/*.tgz`. However, I've not been able to get CSS source maps
to work in Next.js without this hack:
```js
const nextConfig: NextConfig = {
// next.js overwrites config.devtool so we prevent it from doing so
// please don't actually do this…
webpack: (config) =>
Object.defineProperty(config, "devtool", {
get: () => "inline-source-map",
set: () => {},
}),
};
```
This is definitely not supported and also doesn't work with turbopack.
This can be used to test them temporarily but I suspect that they just
don't work there.
### Manual source map analysis
You can analyze source maps using Evan Wallace's [Source Map
Visualization](https://evanw.github.io/source-map-visualization/) tool
which will help to verify the accuracy and quality of source maps. This
is what I used extensively while developing this implementation.
It'll help verify that custom, user CSS maps back to itself in the
input, that generated utilities all map back to `@tailwind utilities;`,
that source locations from imported files are also handled correctly,
etc… It also highlights the ranges of stuff so it's easy to see if there
are off-by-one errors.
It's easiest to use inline source maps with this tool because you can
take the CSS file and drop it on the page and it'll analyze it while
showing the file content.
If you're using Vite you'll want to access the CSS file with `?direct`
at the end so you don't get a JS module back.
## Implementation
The source map implementation follows the ECMA-426 specification and
includes several key components to aid in that goal:
### Source Location Tracking
Each emittable AST node in the compilation pipeline tracks two types of
source locations:
- `src`: Original source location - [source file, start offset, end
offset]
- `dst`: Generated source location - [output file, start offset, end
offset]
This dual tracking allows us to maintain mappings between the original
source and generated output for things like user CSS, generated
utilities, uses of `@apply`, and tracking theme variables.
It is important to note that source locations for nodes _never overlap_
within a file which helps simplify source map generation. As such each
type of node tracks a specific piece of itself rather than its entire
"block":
| Node | What a `SourceLocation` represents |
| ----------- |
---------------------------------------------------------------- |
| Style Rule | The selector |
| At Rule | Rule name and params, includes the `@` |
| Declaration | Property name and value, excludes the semicolon |
| Comment | The entire comment, includes the start `/*` and end `*/`
markers |
### Windows line endings when parsing CSS
Because our AST tracks nodes through offsets we must ensure that any
mutations to the file do *not* change the lenth of the string. We were
previously replacing `\r\n` with `\n` (see [filter code
points](https://drafts.csswg.org/css-syntax/#css-filter-code-points)
from the spec) — which changes the length of the string and all offsets
may end up incorrect. The CSS parser was updated to handle the CRLF
token directly by skipping over the `\r` and letting remaining code
handle `\n` as it did previously. Some additional tweaks were required
when "peeking" the input but those changes were fairly small.
### Tracking of imports
Source maps need paths to the actual imported stylesheets but the
resolve step for stylesheets happens inside the call to `loadStylesheet`
which make the file path unavailable to us. Because of this the
`loadStylesheet` API was augmented such that it has to return a `path`
property that we can then use to identify imported sources. I've also
made the same change to the `loadModule` API for consistency but nothing
currently uses this property.
The `path` property likely makes `base` redundant but elminating that
(if we even want to) is a future task.
### Optimizing the AST
Our optimization pass may intoduce some nodes, for example, fallbacks we
create for `@property`. These nodes are linked back to `@tailwind
utilities` as ultimately that is what is responsible for creating them.
### Line Offset Tables
A key component to our source map generation is the line offset table,
which was inspired by some ESBuild internals. It stores a sorted list of
offsets for the start of each line allowing us to translate offsets to
line/column `Position`s in `O(log N)` time and from `Position`s to
offsets in `O(1)` time. Creation of the table takes `O(N)` time.
This means that we can store code point offsets for source locations and
not have to worry about computing or tracking line/column numbers during
parsing and serialization. Only when a source map is generated do these
offsets need to be computed. This ensures the performance penalty when
not using source maps is minimal.
### Source Map Generation
The source map returned by `buildSourceMap()` is designed to follow the
[ECMA-426 spec](https://tc39.es/ecma426). Because that spec is not
completely finalized we consider the result of `buildSourceMap()` to be
internal API that may change as the spec chamges.
The produces source map is a "decoded" map such that all sources and
mappings are in an object graph. A library like `source-map-js` must be
used to convert this to an encoded source map of the right version where
mappings are encoded with base 64 VLQs.
Any specific integration (Vite, PostCSS, etc…) can then use
`toSourceMap()` from `@tailwindcss/node` to convert from the internal
source map to an spec-compliant encoded source map that can be
understood by other tools.
### Handling minification in Lightning
Since we use Lightning CSS for optimization, and it takes in an input
map, we generate an encoded source map that we then pass to lightning.
The output source map *from lighting itself* is then passed back in
during the second optimization pass. The final map is then passed from
lightning to the CLI (but not Vite or PostCSS — see the limitations
section for details).
In some cases we have to "fix up" the output CSS. When this happens we
use `magic-string` to do the replacement in a way that is trackable and
`@amppproject/remapping` to map that change back onto the original
source map. Once the need for these fix ups disappear these dependencies
can go away.
Notes:
- The accuracy of source maps run though lightning is reduced as it only
tracks on a per-rule level. This is sufficient enough for browser dev
tools so should be fine.
- Source maps during optimization do not function properly at this time
because of a bug in Lightning CSS regarding license comments. Once this
bug is fixed they will start working as expected.
### How source locations flow through the system
1. During initial CSS parsing, source locations are preserved.
2. During parsing these source locations are also mapped to the
destinations which supports an optimization for when no utilities are
generated.
3. Throughout the compilation process, transformations maintain source
location data
4. Generated utilities are explicitly pointed to `@tailwind utilities`
unless generated by `@apply`.
5. When optimization is enabled, source maps are remapped through
lightningcss
6. Final source maps are written in the requested format (inline or
separate file)
2025-05-08 16:29:49 -04:00
|
|
|
source-map-js:
|
|
|
|
|
specifier: ^1.2.1
|
|
|
|
|
version: 1.2.1
|
2024-03-05 14:23:26 +01:00
|
|
|
|
|
|
|
|
playgrounds/nextjs:
|
|
|
|
|
dependencies:
|
|
|
|
|
'@tailwindcss/postcss':
|
|
|
|
|
specifier: workspace:^
|
|
|
|
|
version: link:../../packages/@tailwindcss-postcss
|
|
|
|
|
fast-glob:
|
2025-01-13 11:11:35 +01:00
|
|
|
specifier: ^3.3.3
|
|
|
|
|
version: 3.3.3
|
2024-03-05 14:23:26 +01:00
|
|
|
next:
|
2026-06-09 12:38:33 +02:00
|
|
|
specifier: 16.2.7
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 16.2.7(@playwright/test@1.62.1)(react-dom@19.2.7(react@19.2.7))(react@19.2.7)
|
2024-03-05 14:23:26 +01:00
|
|
|
react:
|
2026-06-09 10:44:01 +00:00
|
|
|
specifier: 19.2.7
|
|
|
|
|
version: 19.2.7
|
2024-03-05 14:23:26 +01:00
|
|
|
react-dom:
|
2026-06-09 10:44:01 +00:00
|
|
|
specifier: 19.2.7
|
|
|
|
|
version: 19.2.7(react@19.2.7)
|
2024-03-05 14:23:26 +01:00
|
|
|
tailwindcss:
|
|
|
|
|
specifier: workspace:^
|
|
|
|
|
version: link:../../packages/tailwindcss
|
|
|
|
|
devDependencies:
|
|
|
|
|
'@types/node':
|
2024-08-02 10:33:14 +02:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 22.20.1
|
2024-03-05 14:23:26 +01:00
|
|
|
'@types/react':
|
2026-05-21 17:58:55 +02:00
|
|
|
specifier: 19.2.15
|
|
|
|
|
version: 19.2.15
|
2025-09-22 11:34:40 +02:00
|
|
|
'@types/react-dom':
|
2026-04-03 21:07:27 +02:00
|
|
|
specifier: 19.2.3
|
2026-05-21 17:58:55 +02:00
|
|
|
version: 19.2.3(@types/react@19.2.15)
|
2024-03-05 14:23:26 +01:00
|
|
|
typescript:
|
2026-04-23 12:51:20 +02:00
|
|
|
specifier: ^6.0.3
|
|
|
|
|
version: 6.0.3
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-10-24 11:00:25 -04:00
|
|
|
playgrounds/v3:
|
|
|
|
|
dependencies:
|
|
|
|
|
next:
|
2026-06-09 12:38:33 +02:00
|
|
|
specifier: 16.2.7
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 16.2.7(@playwright/test@1.62.1)(react-dom@19.2.7(react@19.2.7))(react@19.2.7)
|
2024-10-24 11:00:25 -04:00
|
|
|
react:
|
2026-06-09 10:44:01 +00:00
|
|
|
specifier: 19.2.7
|
|
|
|
|
version: 19.2.7
|
2024-10-24 11:00:25 -04:00
|
|
|
react-dom:
|
2026-06-09 10:44:01 +00:00
|
|
|
specifier: 19.2.7
|
|
|
|
|
version: 19.2.7(react@19.2.7)
|
2024-10-24 11:00:25 -04:00
|
|
|
tailwindcss:
|
|
|
|
|
specifier: ^3
|
2026-06-25 19:14:10 +02:00
|
|
|
version: 3.4.19(yaml@2.9.0)
|
2024-10-24 11:00:25 -04:00
|
|
|
devDependencies:
|
|
|
|
|
'@types/node':
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 22.20.1
|
2024-10-24 11:00:25 -04:00
|
|
|
'@types/react':
|
2026-05-21 17:58:55 +02:00
|
|
|
specifier: 19.2.15
|
|
|
|
|
version: 19.2.15
|
2025-09-22 11:34:40 +02:00
|
|
|
'@types/react-dom':
|
2026-04-03 21:07:27 +02:00
|
|
|
specifier: 19.2.3
|
2026-05-21 17:58:55 +02:00
|
|
|
version: 19.2.3(@types/react@19.2.15)
|
2024-10-24 11:00:25 -04:00
|
|
|
autoprefixer:
|
2026-04-23 12:51:20 +02:00
|
|
|
specifier: ^10.5.0
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 10.5.0(postcss@8.5.25)
|
2024-10-24 11:00:25 -04:00
|
|
|
typescript:
|
2026-04-23 12:51:20 +02:00
|
|
|
specifier: ^6.0.3
|
|
|
|
|
version: 6.0.3
|
2024-10-24 11:00:25 -04:00
|
|
|
|
2024-03-05 14:23:26 +01:00
|
|
|
playgrounds/vite:
|
|
|
|
|
dependencies:
|
|
|
|
|
'@tailwindcss/vite':
|
|
|
|
|
specifier: workspace:^
|
|
|
|
|
version: link:../../packages/@tailwindcss-vite
|
|
|
|
|
'@vitejs/plugin-react':
|
2026-05-21 17:58:55 +02:00
|
|
|
specifier: ^6.0.2
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 6.0.2(vite@8.2.0(@types/node@25.9.1)(esbuild@0.27.7)(jiti@2.7.0)(terser@5.48.0)(yaml@2.9.0))
|
2024-03-05 14:23:26 +01:00
|
|
|
react:
|
2026-05-21 17:58:55 +02:00
|
|
|
specifier: ^19.2.6
|
|
|
|
|
version: 19.2.6
|
2024-03-05 14:23:26 +01:00
|
|
|
react-dom:
|
2026-05-21 17:58:55 +02:00
|
|
|
specifier: ^19.2.6
|
|
|
|
|
version: 19.2.6(react@19.2.6)
|
2024-03-05 14:23:26 +01:00
|
|
|
tailwindcss:
|
|
|
|
|
specifier: workspace:^
|
|
|
|
|
version: link:../../packages/tailwindcss
|
|
|
|
|
devDependencies:
|
|
|
|
|
'@types/react':
|
2026-05-21 17:58:55 +02:00
|
|
|
specifier: ^19.2.15
|
|
|
|
|
version: 19.2.15
|
2025-09-22 11:34:40 +02:00
|
|
|
'@types/react-dom':
|
2025-11-19 10:30:36 +00:00
|
|
|
specifier: ^19.2.3
|
2026-05-21 17:58:55 +02:00
|
|
|
version: 19.2.3(@types/react@19.2.15)
|
2024-03-05 14:23:26 +01:00
|
|
|
bun:
|
2026-05-21 17:58:55 +02:00
|
|
|
specifier: ^1.3.14
|
|
|
|
|
version: 1.3.14
|
2024-03-05 14:23:26 +01:00
|
|
|
vite:
|
2024-08-02 10:33:14 +02:00
|
|
|
specifier: 'catalog:'
|
2026-08-04 13:55:03 +02:00
|
|
|
version: 8.2.0(@types/node@25.9.1)(esbuild@0.27.7)(jiti@2.7.0)(terser@5.48.0)(yaml@2.9.0)
|
2024-03-05 14:23:26 +01:00
|
|
|
|
|
|
|
|
packages:
|
2024-12-18 18:06:26 +00:00
|
|
|
|
2024-10-03 16:21:54 +02:00
|
|
|
'@alloc/quick-lru@5.2.0':
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-UrcABB+4bUrFABwbluTIBErXwvbsU/V7TZWfmbgJfbkwiBuziS9gxdODUyuiecfdGQ85jglMW6juS3+z5TsKLw==}
|
|
|
|
|
engines: {node: '>=10'}
|
2024-10-03 16:21:54 +02:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
'@emnapi/core@1.10.0':
|
|
|
|
|
resolution: {integrity: sha512-yq6OkJ4p82CAfPl0u9mQebQHKPJkY7WrIuk205cTYnYe+k2Z8YBh11FrbRG/H6ihirqcacOgl2BIO8oyMQLeXw==}
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@emnapi/core@1.11.3':
|
|
|
|
|
resolution: {integrity: sha512-zLpS5asjEb7lq8jYLq37N6XKaE41DIexlY1rF/z4/tIl3wo13Sqm28fRyfIsKZD+NZ8mM5RoKkpW/rBcuoSZSg==}
|
|
|
|
|
|
|
|
|
|
'@emnapi/core@2.0.0-alpha.3':
|
|
|
|
|
resolution: {integrity: sha512-AZypUeJ/yByuxyS7BlSNRDOMLMlROYtjYdIAuBmJssVz1UJDSeYxLrdizhXCFYhedC5bqd/ASy8EuNXbVVXp9g==}
|
2026-06-15 13:13:32 +00:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
'@emnapi/runtime@1.10.0':
|
|
|
|
|
resolution: {integrity: sha512-ewvYlk86xUoGI0zQRNq/mC+16R1QeDlKQy21Ki3oSYXNgLb45GV1P6A0M+/s6nyCuNDqe5VpaY84BzXGwVbwFA==}
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@emnapi/runtime@1.11.3':
|
|
|
|
|
resolution: {integrity: sha512-Xz4Tpyki7XyrpbUK1jR1AhdAdaXyhhY4lZ3neLodmhpuWfy2PAQN5B46sAiU4liOXGLkHypn/qU+jvfWSCYYLA==}
|
|
|
|
|
|
|
|
|
|
'@emnapi/runtime@2.0.0-alpha.3':
|
|
|
|
|
resolution: {integrity: sha512-hFPAhMUjJD9BSyCANEISPOogeXC9Zo9ZQl7L6vKnaVsMkCtzznaW/naYypeyl0Gv5rYfWYsZbpixTMpjDJzQeA==}
|
2026-06-15 13:13:32 +00:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
'@emnapi/wasi-threads@1.2.1':
|
|
|
|
|
resolution: {integrity: sha512-uTII7OYF+/Mes/MrcIOYp5yOtSMLBWSIoLPpcgwipoiKbli6k322tcoFsxoIIxPDqW01SQGAgko4EzZi2BNv2w==}
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@emnapi/wasi-threads@1.2.3':
|
|
|
|
|
resolution: {integrity: sha512-ELEBe8PsLvvJ6QMr0zLt8ffvOHW/dc1m3CEzNMg7aJUv3bMaoDtw2TXyDAwkYBuroxxuHEwhRTLJSe5sya547g==}
|
|
|
|
|
|
|
|
|
|
'@emnapi/wasi-threads@2.0.1':
|
|
|
|
|
resolution: {integrity: sha512-9DsSk+o5NBX0CCJT8s0EROGSGxjR/tKu6aBTaVyq+SjAEQH4XcdcRxPBRzsBLizTTJ49MJjF+jgu3qnO9GLQcQ==}
|
2026-06-15 13:13:32 +00:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/aix-ppc64@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-EKX3Qwmhz1eMdEJokhALr0YiD0lhQNwDqkPYyPhiSwKrh7/4KRjQc04sZ8db+5DVVnZ1LmbNDI1uAMPEUBnQPg==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=18'}
|
2024-11-13 11:38:43 +01:00
|
|
|
cpu: [ppc64]
|
|
|
|
|
os: [aix]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/android-arm64@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-62dPZHpIXzvChfvfLJow3q5dDtiNMkwiRzPylSCfriLvZeq0a1bWChrGx/BbUbPwOrsWKMn8idSllklzBy+dgQ==}
|
2025-11-19 18:18:45 -05:00
|
|
|
engines: {node: '>=18'}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [android]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/android-arm@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-jbPXvB4Yj2yBV7HUfE2KHe4GJX51QplCN1pGbYjvsyCZbQmies29EoJbkEc+vYuU5o45AfQn37vZlyXy4YJ8RQ==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=18'}
|
2024-11-13 11:38:43 +01:00
|
|
|
cpu: [arm]
|
|
|
|
|
os: [android]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/android-x64@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-x5VpMODneVDb70PYV2VQOmIUUiBtY3D3mPBG8NxVk5CogneYhkR7MmM3yR/uMdITLrC1ml/NV1rj4bMJuy9MCg==}
|
2025-11-19 18:18:45 -05:00
|
|
|
engines: {node: '>=18'}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [android]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/darwin-arm64@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-5lckdqeuBPlKUwvoCXIgI2D9/ABmPq3Rdp7IfL70393YgaASt7tbju3Ac+ePVi3KDH6N2RqePfHnXkaDtY9fkw==}
|
2025-11-19 18:18:45 -05:00
|
|
|
engines: {node: '>=18'}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/darwin-x64@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-rYnXrKcXuT7Z+WL5K980jVFdvVKhCHhUwid+dDYQpH+qu+TefcomiMAJpIiC2EM3Rjtq0sO3StMV/+3w3MyyqQ==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=18'}
|
2024-11-13 11:38:43 +01:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/freebsd-arm64@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-B48PqeCsEgOtzME2GbNM2roU29AMTuOIN91dsMO30t+Ydis3z/3Ngoj5hhnsOSSwNzS+6JppqWsuhTp6E82l2w==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=18'}
|
2024-11-13 11:38:43 +01:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [freebsd]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/freebsd-x64@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-jOBDK5XEjA4m5IJK3bpAQF9/Lelu/Z9ZcdhTRLf4cajlB+8VEhFFRjWgfy3M1O4rO2GQ/b2dLwCUGpiF/eATNQ==}
|
2025-11-19 18:18:45 -05:00
|
|
|
engines: {node: '>=18'}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [freebsd]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/linux-arm64@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-RZPHBoxXuNnPQO9rvjh5jdkRmVizktkT7TCDkDmQ0W2SwHInKCAV95GRuvdSvA7w4VMwfCjUiPwDi0ZO6Nfe9A==}
|
2025-11-19 18:18:45 -05:00
|
|
|
engines: {node: '>=18'}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [linux]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/linux-arm@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-RkT/YXYBTSULo3+af8Ib0ykH8u2MBh57o7q/DAs3lTJlyVQkgQvlrPTnjIzzRPQyavxtPtfg0EopvDyIt0j1rA==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=18'}
|
2024-11-13 11:38:43 +01:00
|
|
|
cpu: [arm]
|
|
|
|
|
os: [linux]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/linux-ia32@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-GA48aKNkyQDbd3KtkplYWT102C5sn/EZTY4XROkxONgruHPU72l+gW+FfF8tf2cFjeHaRbWpOYa/uRBz/Xq1Pg==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=18'}
|
2024-11-13 11:38:43 +01:00
|
|
|
cpu: [ia32]
|
|
|
|
|
os: [linux]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/linux-loong64@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-a4POruNM2oWsD4WKvBSEKGIiWQF8fZOAsycHOt6JBpZ+JN2n2JH9WAv56SOyu9X5IqAjqSIPTaJkqN8F7XOQ5Q==}
|
2025-11-19 18:18:45 -05:00
|
|
|
engines: {node: '>=18'}
|
|
|
|
|
cpu: [loong64]
|
|
|
|
|
os: [linux]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/linux-mips64el@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-KabT5I6StirGfIz0FMgl1I+R1H73Gp0ofL9A3nG3i/cYFJzKHhouBV5VWK1CSgKvVaG4q1RNpCTR2LuTVB3fIw==}
|
2025-11-19 18:18:45 -05:00
|
|
|
engines: {node: '>=18'}
|
|
|
|
|
cpu: [mips64el]
|
|
|
|
|
os: [linux]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/linux-ppc64@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-gRsL4x6wsGHGRqhtI+ifpN/vpOFTQtnbsupUF5R5YTAg+y/lKelYR1hXbnBdzDjGbMYjVJLJTd2OFmMewAgwlQ==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=18'}
|
2024-11-13 11:38:43 +01:00
|
|
|
cpu: [ppc64]
|
|
|
|
|
os: [linux]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/linux-riscv64@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-hL25LbxO1QOngGzu2U5xeXtxXcW+/GvMN3ejANqXkxZ/opySAZMrc+9LY/WyjAan41unrR3YrmtTsUpwT66InQ==}
|
2025-11-19 18:18:45 -05:00
|
|
|
engines: {node: '>=18'}
|
|
|
|
|
cpu: [riscv64]
|
|
|
|
|
os: [linux]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/linux-s390x@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-2k8go8Ycu1Kb46vEelhu1vqEP+UeRVj2zY1pSuPdgvbd5ykAw82Lrro28vXUrRmzEsUV0NzCf54yARIK8r0fdw==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=18'}
|
2024-11-13 11:38:43 +01:00
|
|
|
cpu: [s390x]
|
|
|
|
|
os: [linux]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/linux-x64@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-hzznmADPt+OmsYzw1EE33ccA+HPdIqiCRq7cQeL1Jlq2gb1+OyWBkMCrYGBJ+sxVzve2ZJEVeePbLM2iEIZSxA==}
|
2025-11-19 18:18:45 -05:00
|
|
|
engines: {node: '>=18'}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [linux]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/netbsd-arm64@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-b6pqtrQdigZBwZxAn1UpazEisvwaIDvdbMbmrly7cDTMFnw/+3lVxxCTGOrkPVnsYIosJJXAsILG9XcQS+Yu6w==}
|
2025-11-19 18:18:45 -05:00
|
|
|
engines: {node: '>=18'}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [netbsd]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/netbsd-x64@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-OfatkLojr6U+WN5EDYuoQhtM+1xco+/6FSzJJnuWiUw5eVcicbyK3dq5EeV/QHT1uy6GoDhGbFpprUiHUYggrw==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=18'}
|
2024-11-13 11:38:43 +01:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [netbsd]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/openbsd-arm64@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-AFuojMQTxAz75Fo8idVcqoQWEHIXFRbOc1TrVcFSgCZtQfSdc1RXgB3tjOn/krRHENUB4j00bfGjyl2mJrU37A==}
|
2025-11-19 18:18:45 -05:00
|
|
|
engines: {node: '>=18'}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [openbsd]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/openbsd-x64@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-+A1NJmfM8WNDv5CLVQYJ5PshuRm/4cI6WMZRg1by1GwPIQPCTs1GLEUHwiiQGT5zDdyLiRM/l1G0Pv54gvtKIg==}
|
2025-11-19 18:18:45 -05:00
|
|
|
engines: {node: '>=18'}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [openbsd]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/openharmony-arm64@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-+KrvYb/C8zA9CU/g0sR6w2RBw7IGc5J2BPnc3dYc5VJxHCSF1yNMxTV5LQ7GuKteQXZtspjFbiuW5/dOj7H4Yw==}
|
2025-11-19 18:18:45 -05:00
|
|
|
engines: {node: '>=18'}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [openharmony]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/sunos-x64@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-ikktIhFBzQNt/QDyOL580ti9+5mL/YZeUPKU2ivGtGjdTYoqz6jObj6nOMfhASpS4GU4Q/Clh1QtxWAvcYKamA==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=18'}
|
2024-11-13 11:38:43 +01:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [sunos]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/win32-arm64@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-7yRhbHvPqSpRUV7Q20VuDwbjW5kIMwTHpptuUzV+AA46kiPze5Z7qgt6CLCK3pWFrHeNfDd1VKgyP4O+ng17CA==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=18'}
|
2024-11-13 11:38:43 +01:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/win32-ia32@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-SmwKXe6VHIyZYbBLJrhOoCJRB/Z1tckzmgTLfFYOfpMAx63BJEaL9ExI8x7v0oAO3Zh6D/Oi1gVxEYr5oUCFhw==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=18'}
|
2024-11-13 11:38:43 +01:00
|
|
|
cpu: [ia32]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/win32-x64@0.27.7':
|
|
|
|
|
resolution: {integrity: sha512-56hiAJPhwQ1R4i+21FVF7V8kSD5zZTdHcVuRFMW0hn753vVfQN8xlx4uOPT4xoGH0Z/oVATuR82AiqSTDIpaHg==}
|
2025-11-19 18:18:45 -05:00
|
|
|
engines: {node: '>=18'}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@img/colour@1.1.0':
|
|
|
|
|
resolution: {integrity: sha512-Td76q7j57o/tLVdgS746cYARfSyxk8iEfRxewL9h4OMzYhbW4TAcppl0mT4eyqXddh6L/jwoM75mo7ixa/pCeQ==}
|
2025-11-20 10:54:23 -05:00
|
|
|
engines: {node: '>=18'}
|
|
|
|
|
|
|
|
|
|
'@img/sharp-darwin-arm64@0.34.5':
|
|
|
|
|
resolution: {integrity: sha512-imtQ3WMJXbMY4fxb/Ndp6HBTNVtWCUI0WdobyheGf5+ad6xX8VIDO8u2xE4qc/fr08CKG/7dDseFtn6M6g/r3w==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
|
2024-11-26 18:31:12 +01:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-darwin-x64@0.34.5':
|
|
|
|
|
resolution: {integrity: sha512-YNEFAF/4KQ/PeW0N+r+aVVsoIY0/qxxikF2SWdp+NRkmMB7y9LBZAVqQ4yhGCm/H3H270OSykqmQMKLBhBJDEw==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
|
2024-11-26 18:31:12 +01:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-darwin-arm64@1.2.4':
|
|
|
|
|
resolution: {integrity: sha512-zqjjo7RatFfFoP0MkQ51jfuFZBnVE2pRiaydKJ1G/rHZvnsrHAOcQALIi9sA5co5xenQdTugCvtb1cuf78Vf4g==}
|
2024-11-26 18:31:12 +01:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-darwin-x64@1.2.4':
|
|
|
|
|
resolution: {integrity: sha512-1IOd5xfVhlGwX+zXv2N93k0yMONvUlANylbJw1eTah8K/Jtpi15KC+WSiaX/nBmbm2HxRM1gZ0nSdjSsrZbGKg==}
|
2024-11-26 18:31:12 +01:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-linux-arm64@1.2.4':
|
|
|
|
|
resolution: {integrity: sha512-excjX8DfsIcJ10x1Kzr4RcWe1edC9PquDRRPx3YVCvQv+U5p7Yin2s32ftzikXojb1PIFc/9Mt28/y+iRklkrw==}
|
2024-11-26 18:31:12 +01:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2024-11-26 18:31:12 +01:00
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-linux-arm@1.2.4':
|
|
|
|
|
resolution: {integrity: sha512-bFI7xcKFELdiNCVov8e44Ia4u2byA+l3XtsAj+Q8tfCwO6BQ8iDojYdvoPMqsKDkuoOo+X6HZA0s0q11ANMQ8A==}
|
2024-11-26 18:31:12 +01:00
|
|
|
cpu: [arm]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2024-11-26 18:31:12 +01:00
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-linux-ppc64@1.2.4':
|
|
|
|
|
resolution: {integrity: sha512-FMuvGijLDYG6lW+b/UvyilUWu5Ayu+3r2d1S8notiGCIyYU/76eig1UfMmkZ7vwgOrzKzlQbFSuQfgm7GYUPpA==}
|
2025-04-25 09:56:24 +00:00
|
|
|
cpu: [ppc64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2025-04-25 09:56:24 +00:00
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-linux-riscv64@1.2.4':
|
|
|
|
|
resolution: {integrity: sha512-oVDbcR4zUC0ce82teubSm+x6ETixtKZBh/qbREIOcI3cULzDyb18Sr/Wcyx7NRQeQzOiHTNbZFF1UwPS2scyGA==}
|
|
|
|
|
cpu: [riscv64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2025-11-20 10:54:23 -05:00
|
|
|
|
|
|
|
|
'@img/sharp-libvips-linux-s390x@1.2.4':
|
|
|
|
|
resolution: {integrity: sha512-qmp9VrzgPgMoGZyPvrQHqk02uyjA0/QrTO26Tqk6l4ZV0MPWIW6LTkqOIov+J1yEu7MbFQaDpwdwJKhbJvuRxQ==}
|
2024-11-26 18:31:12 +01:00
|
|
|
cpu: [s390x]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2024-11-26 18:31:12 +01:00
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-linux-x64@1.2.4':
|
|
|
|
|
resolution: {integrity: sha512-tJxiiLsmHc9Ax1bz3oaOYBURTXGIRDODBqhveVHonrHJ9/+k89qbLl0bcJns+e4t4rvaNBxaEZsFtSfAdquPrw==}
|
2024-11-26 18:31:12 +01:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2024-11-26 18:31:12 +01:00
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-linuxmusl-arm64@1.2.4':
|
|
|
|
|
resolution: {integrity: sha512-FVQHuwx1IIuNow9QAbYUzJ+En8KcVm9Lk5+uGUQJHaZmMECZmOlix9HnH7n1TRkXMS0pGxIJokIVB9SuqZGGXw==}
|
2024-11-26 18:31:12 +01:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [musl]
|
2024-11-26 18:31:12 +01:00
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-linuxmusl-x64@1.2.4':
|
|
|
|
|
resolution: {integrity: sha512-+LpyBk7L44ZIXwz/VYfglaX/okxezESc6UxDSoyo2Ks6Jxc4Y7sGjpgU9s4PMgqgjj1gZCylTieNamqA1MF7Dg==}
|
2024-11-26 18:31:12 +01:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [musl]
|
2024-11-26 18:31:12 +01:00
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-linux-arm64@0.34.5':
|
|
|
|
|
resolution: {integrity: sha512-bKQzaJRY/bkPOXyKx5EVup7qkaojECG6NLYswgktOZjaXecSAeCWiZwwiFf3/Y+O1HrauiE3FVsGxFg8c24rZg==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
|
2024-11-26 18:31:12 +01:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2024-11-26 18:31:12 +01:00
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-linux-arm@0.34.5':
|
|
|
|
|
resolution: {integrity: sha512-9dLqsvwtg1uuXBGZKsxem9595+ujv0sJ6Vi8wcTANSFpwV/GONat5eCkzQo/1O6zRIkh0m/8+5BjrRr7jDUSZw==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
|
2024-11-26 18:31:12 +01:00
|
|
|
cpu: [arm]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2024-11-26 18:31:12 +01:00
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-linux-ppc64@0.34.5':
|
|
|
|
|
resolution: {integrity: sha512-7zznwNaqW6YtsfrGGDA6BRkISKAAE1Jo0QdpNYXNMHu2+0dTrPflTLNkpc8l7MUP5M16ZJcUvysVWWrMefZquA==}
|
2025-07-30 10:32:16 -04:00
|
|
|
engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
|
|
|
|
|
cpu: [ppc64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2025-07-30 10:32:16 -04:00
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-linux-riscv64@0.34.5':
|
|
|
|
|
resolution: {integrity: sha512-51gJuLPTKa7piYPaVs8GmByo7/U7/7TZOq+cnXJIHZKavIRHAP77e3N2HEl3dgiqdD/w0yUfiJnII77PuDDFdw==}
|
|
|
|
|
engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
|
|
|
|
|
cpu: [riscv64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2025-11-20 10:54:23 -05:00
|
|
|
|
|
|
|
|
'@img/sharp-linux-s390x@0.34.5':
|
|
|
|
|
resolution: {integrity: sha512-nQtCk0PdKfho3eC5MrbQoigJ2gd1CgddUMkabUj+rBevs8tZ2cULOx46E7oyX+04WGfABgIwmMC0VqieTiR4jg==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
|
2024-11-26 18:31:12 +01:00
|
|
|
cpu: [s390x]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2024-11-26 18:31:12 +01:00
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-linux-x64@0.34.5':
|
|
|
|
|
resolution: {integrity: sha512-MEzd8HPKxVxVenwAa+JRPwEC7QFjoPWuS5NZnBt6B3pu7EG2Ge0id1oLHZpPJdn3OQK+BQDiw9zStiHBTJQQQQ==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
|
2024-11-26 18:31:12 +01:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2024-11-26 18:31:12 +01:00
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-linuxmusl-arm64@0.34.5':
|
|
|
|
|
resolution: {integrity: sha512-fprJR6GtRsMt6Kyfq44IsChVZeGN97gTD331weR1ex1c1rypDEABN6Tm2xa1wE6lYb5DdEnk03NZPqA7Id21yg==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
|
2024-11-26 18:31:12 +01:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [musl]
|
2024-11-26 18:31:12 +01:00
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-linuxmusl-x64@0.34.5':
|
|
|
|
|
resolution: {integrity: sha512-Jg8wNT1MUzIvhBFxViqrEhWDGzqymo3sV7z7ZsaWbZNDLXRJZoRGrjulp60YYtV4wfY8VIKcWidjojlLcWrd8Q==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
|
2024-11-26 18:31:12 +01:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [musl]
|
2024-11-26 18:31:12 +01:00
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-wasm32@0.34.5':
|
|
|
|
|
resolution: {integrity: sha512-OdWTEiVkY2PHwqkbBI8frFxQQFekHaSSkUIJkwzclWZe64O1X4UlUjqqqLaPbUpMOQk6FBu/HtlGXNblIs0huw==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
|
2024-11-26 18:31:12 +01:00
|
|
|
cpu: [wasm32]
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-win32-arm64@0.34.5':
|
|
|
|
|
resolution: {integrity: sha512-WQ3AgWCWYSb2yt+IG8mnC6Jdk9Whs7O0gxphblsLvdhSpSTtmu69ZG1Gkb6NuvxsNACwiPV6cNSZNzt0KPsw7g==}
|
2025-07-30 10:32:16 -04:00
|
|
|
engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-win32-ia32@0.34.5':
|
|
|
|
|
resolution: {integrity: sha512-FV9m/7NmeCmSHDD5j4+4pNI8Cp3aW+JvLoXcTUo0IqyjSfAZJ8dIUmijx1qaJsIiU+Hosw6xM5KijAWRJCSgNg==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
|
2024-11-26 18:31:12 +01:00
|
|
|
cpu: [ia32]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-win32-x64@0.34.5':
|
|
|
|
|
resolution: {integrity: sha512-+29YMsqY2/9eFEiW93eqWnuLcWcufowXewwSNIT6UwZdUUCrM3oFjMWH/Z6/TMmb4hlFenmfAVbpWeup2jryCw==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
|
2024-11-26 18:31:12 +01:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/ansi@2.0.7':
|
|
|
|
|
resolution: {integrity: sha512-3eTuUO1vH2cZm2ZKHeQxnOqlTi9EfZDGgIe3BL3I4u+rJHocr9Fz86M4fjYABPvFnQG/gGK551HqDiIcETwU6Q==}
|
|
|
|
|
engines: {node: '>=23.5.0 || ^22.13.0 || ^20.17.0'}
|
2025-09-19 17:08:41 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/checkbox@5.2.1':
|
|
|
|
|
resolution: {integrity: sha512-b6xmA/VlTe0ZgDQHDui+Nav470u7u49nRd8/iuhOcQPO9Ch7lGuogydhi2VOmNlZ+zXcM8IcPuNSwQcdJaF/kw==}
|
|
|
|
|
engines: {node: '>=23.5.0 || ^22.13.0 || ^20.17.0'}
|
2025-04-11 17:19:55 +02:00
|
|
|
peerDependencies:
|
|
|
|
|
'@types/node': '>=18'
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@types/node':
|
|
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/confirm@6.1.1':
|
|
|
|
|
resolution: {integrity: sha512-eb8DBZcz/2qHWQda4rk2JiQk5h9QV/cVHi1yjt0f69WFZMRFn0sJTye3EAP8icut8UDMjQPsaH5KbcOogefrFQ==}
|
|
|
|
|
engines: {node: '>=23.5.0 || ^22.13.0 || ^20.17.0'}
|
2025-04-11 17:19:55 +02:00
|
|
|
peerDependencies:
|
|
|
|
|
'@types/node': '>=18'
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@types/node':
|
|
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/core@11.2.1':
|
|
|
|
|
resolution: {integrity: sha512-Qd6GJT1yVyrZZCfN8W2qKF5ApmqryXRhRKCuip8h01x2w/esJQ2XIYc6f9abMIHgKQdBfFTSOdbHRLAhuM09UA==}
|
|
|
|
|
engines: {node: '>=23.5.0 || ^22.13.0 || ^20.17.0'}
|
2025-04-11 17:19:55 +02:00
|
|
|
peerDependencies:
|
|
|
|
|
'@types/node': '>=18'
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@types/node':
|
|
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/editor@5.2.2':
|
|
|
|
|
resolution: {integrity: sha512-ZRVd/oD+sYsUd5zVm0NflqEzlqfYCyHNsqkHl2oWXEUHs12tCbcSFi+wVFEvD8+LGRaMUsVrE7qeo6lSG/S1Vg==}
|
|
|
|
|
engines: {node: '>=23.5.0 || ^22.13.0 || ^20.17.0'}
|
2025-04-11 17:19:55 +02:00
|
|
|
peerDependencies:
|
|
|
|
|
'@types/node': '>=18'
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@types/node':
|
|
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/expand@5.1.1':
|
|
|
|
|
resolution: {integrity: sha512-YmQpenjbFSHAK3sOd44puHh3V1KXXr+JiNpUztoSQ4drLh2rTVzTap/YtlAVu/5xavifIlBfNEzJ/neZJ1a/1g==}
|
|
|
|
|
engines: {node: '>=23.5.0 || ^22.13.0 || ^20.17.0'}
|
2025-04-11 17:19:55 +02:00
|
|
|
peerDependencies:
|
|
|
|
|
'@types/node': '>=18'
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@types/node':
|
|
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/external-editor@3.0.3':
|
|
|
|
|
resolution: {integrity: sha512-6thf5I8q7lZwzGLAxPaaGEREEkZ3nyePPDQ1oyobblxmEE8mqTLguScP7pDjUTAibiyb4hfXl+qjUEJ+di/aNA==}
|
|
|
|
|
engines: {node: '>=23.5.0 || ^22.13.0 || ^20.17.0'}
|
2025-09-19 17:08:41 +02:00
|
|
|
peerDependencies:
|
|
|
|
|
'@types/node': '>=18'
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@types/node':
|
|
|
|
|
optional: true
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/figures@2.0.7':
|
|
|
|
|
resolution: {integrity: sha512-aJ8TBPOGB6f/2qziPfElISTCEd5XOYTFckA2SGjhNmiKzfK/u4ot3v0DUzGVdUnKjN10EqnnEPck36BkyfLnJw==}
|
|
|
|
|
engines: {node: '>=23.5.0 || ^22.13.0 || ^20.17.0'}
|
2025-09-19 17:08:41 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/input@5.1.2':
|
|
|
|
|
resolution: {integrity: sha512-9K/DDBSQpOyZSkt6sOVP9Vo0TR7atX2kuILsUu0x3wVcVbe97lJwIJKMLdMw25tDYuXl/qp6erT0Xs1rfmcfZg==}
|
|
|
|
|
engines: {node: '>=23.5.0 || ^22.13.0 || ^20.17.0'}
|
2025-04-11 17:19:55 +02:00
|
|
|
peerDependencies:
|
|
|
|
|
'@types/node': '>=18'
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@types/node':
|
|
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/number@4.1.1':
|
|
|
|
|
resolution: {integrity: sha512-XF4IXAbPnGPgw0wsbC/i2tPcyfdZgDpUlhsqU0SfT4IRIGWha6Xm9VRgN5yYxJq+jnyXlfXI/nQ3ulfk0iEICA==}
|
|
|
|
|
engines: {node: '>=23.5.0 || ^22.13.0 || ^20.17.0'}
|
2025-04-11 17:19:55 +02:00
|
|
|
peerDependencies:
|
|
|
|
|
'@types/node': '>=18'
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@types/node':
|
|
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/password@5.1.1':
|
|
|
|
|
resolution: {integrity: sha512-3XBfF7DAsp5qeDsvN5Rd1HmbNokVvEQoUM0QLrRcybC9nX96w3Pbmu7qUsb3IT3J3jBvs2+mTXaKHOUsgHMLzg==}
|
|
|
|
|
engines: {node: '>=23.5.0 || ^22.13.0 || ^20.17.0'}
|
2025-04-11 17:19:55 +02:00
|
|
|
peerDependencies:
|
|
|
|
|
'@types/node': '>=18'
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@types/node':
|
|
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/prompts@8.5.2':
|
|
|
|
|
resolution: {integrity: sha512-IYR/3C/paEVVQYQvdDlFZVjRCJVYHHON0XXMH91KO9GSxs0TdKYWlUdvfQl2EfAHDxUaN3IBffkE/BDTh5nJ6g==}
|
|
|
|
|
engines: {node: '>=23.5.0 || ^22.13.0 || ^20.17.0'}
|
2025-04-11 17:19:55 +02:00
|
|
|
peerDependencies:
|
|
|
|
|
'@types/node': '>=18'
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@types/node':
|
|
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/rawlist@5.3.1':
|
|
|
|
|
resolution: {integrity: sha512-QqdTqQddL3qPX/PPrjobpsO25NZ4dWXgTLenrR445L2ptLEYE6Z+PD5c5CNDJNx4ugRgELAIpSIJxZaO2jJ2Og==}
|
|
|
|
|
engines: {node: '>=23.5.0 || ^22.13.0 || ^20.17.0'}
|
2025-04-11 17:19:55 +02:00
|
|
|
peerDependencies:
|
|
|
|
|
'@types/node': '>=18'
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@types/node':
|
|
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/search@4.2.1':
|
|
|
|
|
resolution: {integrity: sha512-xJj8QWKRSrfKoBIITLZK61dD3zwo0Rz11fgDImku30/Oe81zMdIdGgrLY2h6RkJ+KZ/GhNYIRMKnH/62qBTA5g==}
|
|
|
|
|
engines: {node: '>=23.5.0 || ^22.13.0 || ^20.17.0'}
|
2025-04-11 17:19:55 +02:00
|
|
|
peerDependencies:
|
|
|
|
|
'@types/node': '>=18'
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@types/node':
|
|
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/select@5.2.1':
|
|
|
|
|
resolution: {integrity: sha512-FlDndEUww8m7BfukO2nJa25vhD+H5jxxCv4oGioKqzyWz3nPHhhw4LKdYRSlXuAx7DsdWia7iyaBPKKS95Evfw==}
|
|
|
|
|
engines: {node: '>=23.5.0 || ^22.13.0 || ^20.17.0'}
|
2025-04-11 17:19:55 +02:00
|
|
|
peerDependencies:
|
|
|
|
|
'@types/node': '>=18'
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@types/node':
|
|
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/type@4.0.7':
|
|
|
|
|
resolution: {integrity: sha512-t28inv14nMQ1PhKpsJPY+kEs/c00qzeCOS2gTNRyTjG5d6qsVA2fItxW4hkvGZ5lvanGLdtCzVIx5dwdRpN1+g==}
|
|
|
|
|
engines: {node: '>=23.5.0 || ^22.13.0 || ^20.17.0'}
|
2025-04-11 17:19:55 +02:00
|
|
|
peerDependencies:
|
|
|
|
|
'@types/node': '>=18'
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@types/node':
|
|
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@jridgewell/gen-mapping@0.3.13':
|
|
|
|
|
resolution: {integrity: sha512-2kkt/7niJ6MgEPxF0bYdQ6etZaA+fQvDcLKckhy1yIQOzaoKjBBjSj63/aLVjYE3qhRt5dvM+uUyfCg6UKCBbA==}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2025-08-12 15:52:35 +02:00
|
|
|
'@jridgewell/remapping@2.3.5':
|
|
|
|
|
resolution: {integrity: sha512-LI9u/+laYG4Ds1TDKSJW2YPrIlcVYOwi2fUC6xB43lueCjgxV4lffOCZCtYFiH6TNOX+tQKXx97T4IKHbhyHEQ==}
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
'@jridgewell/resolve-uri@3.1.2':
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-bRISgCIjP20/tbWSPWMEi54QVPRZExkuD9lJL+UIxUKtwVJA8wW1Trb1jMs1RFXo1CBTNZ/5hpC9QvmKWdopKw==}
|
|
|
|
|
engines: {node: '>=6.0.0'}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@jridgewell/source-map@0.3.11':
|
|
|
|
|
resolution: {integrity: sha512-ZMp1V8ZFcPG5dIWnQLr3NSI1MiCU7UETdS/A0G8V/XWHvJv3ZsFqutJn1Y5RPmAPX6F3BiE397OqveU/9NCuIA==}
|
2024-09-04 10:09:24 +02:00
|
|
|
|
2025-08-29 14:22:19 +00:00
|
|
|
'@jridgewell/sourcemap-codec@1.5.5':
|
|
|
|
|
resolution: {integrity: sha512-cYQ9310grqxueWbl+WuIUIaiUaDcj7WOq5fVhEljNVgRfOUhY9fy2zTvfoqWsnebh8Sl70VScFbICvJnLKB0Og==}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@jridgewell/trace-mapping@0.3.31':
|
|
|
|
|
resolution: {integrity: sha512-zzNR+SdQSDJzc8joaeP8QQoCQr8NuYx2dIIytl1QeBEZHJ9uW6hebsrYgbz8hJwUQao3TWCMtmfV8Nu1twOLAw==}
|
2025-07-25 07:13:25 -04:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@napi-rs/cli@3.7.4':
|
|
|
|
|
resolution: {integrity: sha512-idELIUceJ9zPgx/shcMt1fSSsteFG68v56RIXi4qUm7OYuJOt7CoMj2KnHVmbOqXgUHWQU1lCULrtQdZDG4F5A==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 16'}
|
2024-03-05 14:23:26 +01:00
|
|
|
hasBin: true
|
2025-04-11 17:19:55 +02:00
|
|
|
peerDependencies:
|
2026-04-26 17:49:06 +02:00
|
|
|
'@emnapi/runtime': ^1.7.1
|
2025-04-11 17:19:55 +02:00
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@emnapi/runtime':
|
|
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/cross-toolchain@1.0.3':
|
|
|
|
|
resolution: {integrity: sha512-ENPfLe4937bsKVTDA6zdABx4pq9w0tHqRrJHyaGxgaPq03a2Bd1unD5XSKjXJjebsABJ+MjAv1A2OvCgK9yehg==}
|
2025-04-11 17:19:55 +02:00
|
|
|
peerDependencies:
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/cross-toolchain-arm64-target-aarch64': ^1.0.3
|
|
|
|
|
'@napi-rs/cross-toolchain-arm64-target-armv7': ^1.0.3
|
|
|
|
|
'@napi-rs/cross-toolchain-arm64-target-ppc64le': ^1.0.3
|
|
|
|
|
'@napi-rs/cross-toolchain-arm64-target-s390x': ^1.0.3
|
|
|
|
|
'@napi-rs/cross-toolchain-arm64-target-x86_64': ^1.0.3
|
|
|
|
|
'@napi-rs/cross-toolchain-x64-target-aarch64': ^1.0.3
|
|
|
|
|
'@napi-rs/cross-toolchain-x64-target-armv7': ^1.0.3
|
|
|
|
|
'@napi-rs/cross-toolchain-x64-target-ppc64le': ^1.0.3
|
|
|
|
|
'@napi-rs/cross-toolchain-x64-target-s390x': ^1.0.3
|
|
|
|
|
'@napi-rs/cross-toolchain-x64-target-x86_64': ^1.0.3
|
2025-04-11 17:19:55 +02:00
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@napi-rs/cross-toolchain-arm64-target-aarch64':
|
|
|
|
|
optional: true
|
|
|
|
|
'@napi-rs/cross-toolchain-arm64-target-armv7':
|
|
|
|
|
optional: true
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/cross-toolchain-arm64-target-ppc64le':
|
|
|
|
|
optional: true
|
|
|
|
|
'@napi-rs/cross-toolchain-arm64-target-s390x':
|
|
|
|
|
optional: true
|
2025-04-11 17:19:55 +02:00
|
|
|
'@napi-rs/cross-toolchain-arm64-target-x86_64':
|
|
|
|
|
optional: true
|
|
|
|
|
'@napi-rs/cross-toolchain-x64-target-aarch64':
|
|
|
|
|
optional: true
|
|
|
|
|
'@napi-rs/cross-toolchain-x64-target-armv7':
|
|
|
|
|
optional: true
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/cross-toolchain-x64-target-ppc64le':
|
|
|
|
|
optional: true
|
|
|
|
|
'@napi-rs/cross-toolchain-x64-target-s390x':
|
|
|
|
|
optional: true
|
2025-04-11 17:19:55 +02:00
|
|
|
'@napi-rs/cross-toolchain-x64-target-x86_64':
|
|
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-android-arm-eabi@1.4.5':
|
|
|
|
|
resolution: {integrity: sha512-Up4gpyw2SacmyKWWEib06GhiDdF+H+CCU0LAV8pnM4aJIDqKKd5LHSlBht83Jut6frkB0vwEPmAkv4NjQ5u//Q==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [arm]
|
|
|
|
|
os: [android]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-android-arm64@1.4.5':
|
|
|
|
|
resolution: {integrity: sha512-uwa8sLlWEzkAM0MWyoZJg0JTD3BkPknvejAFG2acUA1raXM8jLrqujWCdOStisXhqQjZ2nDMp3FV6cs//zjfuQ==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [android]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-darwin-arm64@1.4.5':
|
|
|
|
|
resolution: {integrity: sha512-0Y0TQLQ2xAjVabrMDem1NhIssOZzF/y/dqetc6OT8mD3xMTDtF8u5BqZoX3MyPc9FzpsZw4ksol+w7DsxHrpMA==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-darwin-x64@1.4.5':
|
|
|
|
|
resolution: {integrity: sha512-vR2IUyJY3En+V1wJkwmbGWcYiT8pHloTAWdW4pG24+51GIq+intst6Uf6D/r46citObGZrlX0QvMarOkQeHWpw==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-freebsd-x64@1.4.5':
|
|
|
|
|
resolution: {integrity: sha512-XpnYQC5SVovO35tF0xGkbHYjsS6kqyNCjuaLQ2dbEblFRr5cAZVvsJ/9h7zj/5FluJPJRDojVNxGyRhTp4z2lw==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [freebsd]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-linux-arm-gnueabihf@1.4.5':
|
|
|
|
|
resolution: {integrity: sha512-ic1ZZMoRfRMwtSwxkyw4zIlbDZGC6davC9r+2oX6x9QiF247BRqqT94qGeL5ZP4Vtz0Hyy7TEViWhx5j6Bpzvw==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [arm]
|
|
|
|
|
os: [linux]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-linux-arm64-gnu@1.4.5':
|
|
|
|
|
resolution: {integrity: sha512-asEp7FPd7C1Yi6DQb45a3KPHKOFBSfGuJWXcAd4/bL2Fjetb2n/KK2z14yfW8YC/Fv6x3rBM0VAZKmJuz4tysg==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-linux-arm64-musl@1.4.5':
|
|
|
|
|
resolution: {integrity: sha512-yWjcPDgJ2nIL3KNvi4536dlT/CcCWO0DUyEOlBs/SacG7BeD6IjGh6yYzd3/X1Y3JItCbZoDoLUH8iB1lTXo3w==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [musl]
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-linux-ppc64-gnu@1.4.5':
|
|
|
|
|
resolution: {integrity: sha512-0XRhKuIU/9ZjT4WDIG/qnX7Xz7mSQHYZo9Gb3MP2gcvBgr6BA4zywQ9k3gmQaPn9ECE+CZg2V7DV7kT+x2pUMQ==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [ppc64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-linux-riscv64-gnu@1.4.5':
|
|
|
|
|
resolution: {integrity: sha512-QrqDIPEUUB23GCpyQj/QFyMlr8SGxxyExeZz9OWFnHfb70kXdTLWrHS/hEI1Ru+lSbQ/6xRqeoGyQ4Aqdg+/RA==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [riscv64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-linux-s390x-gnu@1.4.5':
|
|
|
|
|
resolution: {integrity: sha512-k8RVM5aMhW86E9H0QXdquwojew4H3SwPxbRVbl49/COJQWCUjGi79X6mYruMnMPEznZinUiT1jgKbFo2A00NdA==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [s390x]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-linux-x64-gnu@1.4.5':
|
|
|
|
|
resolution: {integrity: sha512-6rMtBgnIq2Wcl1rQdZsnM+rtCcVCbws1nF8S2NzaUsVaZv8bjrPiAa0lwg4Eqnn1d9lgwqT+cZgm5m+//K08Kw==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-linux-x64-musl@1.4.5':
|
|
|
|
|
resolution: {integrity: sha512-eiadGBKi7Vd0bCArBUOO/qqRYPHt/VQVvGyYvDFt6C2ZSIjlD+HuOl+2oS1sjf4CFjK4eDIog6EdXnL0NE6iyQ==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [musl]
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-wasm32-wasi@1.4.5':
|
|
|
|
|
resolution: {integrity: sha512-+VyHHlr68dvey6fXc2hehw9gHVFIW3TtGF1XkcbAu65qVXsA9D/T+uuoRVqhE+JCyFHFrO0ixRbZDRK1XJt1sA==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>=14.0.0'}
|
|
|
|
|
cpu: [wasm32]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-win32-arm64-msvc@1.4.5':
|
|
|
|
|
resolution: {integrity: sha512-eewnqvIyyhHi3KaZtBOJXohLvwwN27gfS2G/YDWdfHlbz1jrmfeHAmzMsP5qv8vGB+T80TMHNkro4kYjeh6Deg==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-win32-ia32-msvc@1.4.5':
|
|
|
|
|
resolution: {integrity: sha512-OeacFVRCJOKNU/a0ephUfYZ2Yt+NvaHze/4TgOwJ0J0P4P7X1mHzN+ig9Iyd74aQDXYqc7kaCXA2dpAOcH87Cg==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [ia32]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-win32-x64-msvc@1.4.5':
|
|
|
|
|
resolution: {integrity: sha512-T4I1SamdSmtyZgDXGAGP+y5LEK5vxHUFwe8mz6D4R7Sa5/WCxTcCIgPJ9BD7RkpO17lzhlaM2vmVvMy96Lvk9Q==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma@1.4.5':
|
|
|
|
|
resolution: {integrity: sha512-zS5LuN1OBPAyZpda2ZZgYOEDC+xecUdAGnrvbYzjnLXkrq/OBC3B9qcRvlxbDR3k5H/gVfvef1/jyUqPknqjbg==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-android-arm-eabi@1.1.0':
|
|
|
|
|
resolution: {integrity: sha512-h2Ryndraj/YiKgMV/r5by1cDusluYIRT0CaE0/PekQ4u+Wpy2iUVqvzVU98ZPnhXaNeYxEvVJHNGafpOfaD0TA==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [arm]
|
|
|
|
|
os: [android]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-android-arm64@1.1.0':
|
|
|
|
|
resolution: {integrity: sha512-DJFyQHr1ZxNZorm/gzc1qBNLF/FcKzcH0V0Vwan5P+o0aE2keQIGEjJ09FudkF9v6uOuJjHCVDdK6S6uHtShAw==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [android]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-darwin-arm64@1.1.0':
|
|
|
|
|
resolution: {integrity: sha512-Zz2sXRzjIX4e532zD6xm2SjXEym6MkvfCvL2RMpG2+UwNVDVscHNcz3d47Pf3sysP2e2af7fBB3TIoK2f6trPw==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-darwin-x64@1.1.0':
|
|
|
|
|
resolution: {integrity: sha512-EI+CptIMNweT0ms9S3mkP/q+J6FNZ1Q6pvpJOEcWglRfyfQpLqjlC0O+dptruTPE8VamKYuqdjxfqD8hifZDOA==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-freebsd-x64@1.1.0':
|
|
|
|
|
resolution: {integrity: sha512-J0PIqX+pl6lBIAckL/c87gpodLbjZB1OtIK+RDscKC9NLdpVv6VGOxzUV/fYev/hctcE8EfkLbgFOfpmVQPg2g==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [freebsd]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-linux-arm-gnueabihf@1.1.0':
|
|
|
|
|
resolution: {integrity: sha512-SLgIQo3f3EjkZ82ZwvrEgFvMdDAhsxCYjyoSuWfHCz0U16qx3SuGCp8+FYOPYCECHN3ZlGjXnoAIt9ERd0dEUg==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [arm]
|
|
|
|
|
os: [linux]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-linux-arm64-gnu@1.1.0':
|
|
|
|
|
resolution: {integrity: sha512-d014cdle52EGaH6GpYTQOP9Py7glMO1zz/+ynJPjjzYFSxvdYx0byrjumZk2UQdIyGZiJO2MEFpCkEEKFSgPYA==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-linux-arm64-musl@1.1.0':
|
|
|
|
|
resolution: {integrity: sha512-L/y1/26q9L/uBqiW/JdOb/Dc94egFvNALUZV2WCGKQXc6UByPBMgdiEyW2dtoYxYYYYc+AKD+jr+wQPcvX2vrQ==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [musl]
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-linux-ppc64-gnu@1.1.0':
|
|
|
|
|
resolution: {integrity: sha512-EPE1K/80RQvPbLRJDJs1QmCIcH+7WRi0F73+oTe1582y9RtfGRuzAkzeBuAGRXAQEjRQw/RjtNqr6UTJ+8UuWQ==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [ppc64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-linux-s390x-gnu@1.1.0':
|
|
|
|
|
resolution: {integrity: sha512-B2jhWiB1ffw1nQBqLUP1h4+J1ovAxBOoe5N2IqDMOc63fsPZKNqF1PvO/dIem8z7LL4U4bsfmhy3gBfu547oNQ==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [s390x]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-linux-x64-gnu@1.1.0':
|
|
|
|
|
resolution: {integrity: sha512-tbZDHnb9617lTnsDMGo/eAMZxnsQFnaRe+MszRqHguKfMwkisc9CCJnks/r1o84u5fECI+J/HOrKXgczq/3Oww==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-linux-x64-musl@1.1.0':
|
|
|
|
|
resolution: {integrity: sha512-dV6cODlzbO8u6Anmv2N/ilQHq/AWz0xyltuXoLU3yUyXbZcnWYZuB2rL8OBGPmqNcD+x9NdScBNXh7vWN0naSQ==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [musl]
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-wasm32-wasi@1.1.0':
|
|
|
|
|
resolution: {integrity: sha512-jIa9nb2HzOrfH0F8QQ9g3WE4aMH5vSI5/1NYVNm9ysCmNjCCtMXCAhlI3WKCdm/DwHf0zLqdrrtDFXODcNaqMw==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>=14.0.0'}
|
|
|
|
|
cpu: [wasm32]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-win32-arm64-msvc@1.1.0':
|
|
|
|
|
resolution: {integrity: sha512-vfpG71OB0ijtjemp3WTdmBKJm9R70KM8vsSExMsIQtV0lVzP07oM1CW6JbNRPXNLhRoue9ofYLiUDk8bE0Hckg==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-win32-ia32-msvc@1.1.0':
|
|
|
|
|
resolution: {integrity: sha512-hGPyPW60YSpOSgzfy68DLBHgi6HxkAM+L59ZZZPMQ0TOXjQg+p2EW87+TjZfJOkSpbYiEkULwa/f4a2hcVjsqQ==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [ia32]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-win32-x64-msvc@1.1.0':
|
|
|
|
|
resolution: {integrity: sha512-L6Ed1DxXK9YSCMyvpR8MiNAyKNkQLjsHsHK9E0qnHa8NzLFqzDKhvs5LfnWxM2kJ+F7m/e5n9zPm24kHb3LsVw==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar@1.1.0':
|
|
|
|
|
resolution: {integrity: sha512-7cmzIu+Vbupriudo7UudoMRH2OA3cTw67vva8MxeoAe5S7vPFI7z0vp0pMXiA25S8IUJefImQ90FeJjl8fjEaQ==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
'@napi-rs/wasm-runtime@1.1.4':
|
|
|
|
|
resolution: {integrity: sha512-3NQNNgA1YSlJb/kMH1ildASP9HW7/7kYnRI2szWJaofaS1hWmbGI4H+d3+22aGzXXN9IJ+n+GiFVcGipJP18ow==}
|
|
|
|
|
peerDependencies:
|
|
|
|
|
'@emnapi/core': ^1.7.1
|
|
|
|
|
'@emnapi/runtime': ^1.7.1
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@napi-rs/wasm-runtime@1.2.2':
|
|
|
|
|
resolution: {integrity: sha512-JfB4kuJQjaoHuCTseIINHtHWeJnvgEcxjwA5t/Y00ZgaOO1Crz3fjT/p8kT28zA/Caz7oiUMn3d6H2yOVCVwuw==}
|
|
|
|
|
engines: {node: ^20.19.0 || ^22.13.0 || >=23.5.0}
|
2026-07-02 11:45:49 +02:00
|
|
|
peerDependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@emnapi/core': ^1.7.1 || ^2.0.0-alpha.3
|
|
|
|
|
'@emnapi/runtime': ^1.7.1 || ^2.0.0-alpha.3
|
2026-07-02 11:45:49 +02:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-android-arm-eabi@1.0.1':
|
|
|
|
|
resolution: {integrity: sha512-lr07E/l571Gft5v4aA1dI8koJEmF1F0UigBbsqg9OWNzg80H3lDPO+auv85y3T/NHE3GirDk7x/D3sLO57vayw==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [arm]
|
|
|
|
|
os: [android]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-android-arm64@1.0.1':
|
|
|
|
|
resolution: {integrity: sha512-WDR7S+aRLV6LtBJAg5fmjKkTZIdrEnnQxgdsb7Cf8pYiMWBHLU+LC49OUVppQ2YSPY0+GeYm9yuZWW3kLjJ7Bg==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [android]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-darwin-arm64@1.0.1':
|
|
|
|
|
resolution: {integrity: sha512-qWTI+EEkiN0oIn/N2gQo7+TVYil+AJ20jjuzD2vATS6uIjVz+Updeqmszi7zq7rdFTLp6Ea3/z4kDKIfZwmR9g==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-darwin-x64@1.0.1':
|
|
|
|
|
resolution: {integrity: sha512-bA6hubqtHROR5UI3tToAF/c6TDmaAgF0SWgo4rADHtQ4wdn0JeogvOk50gs2TYVhKPE2ZD2+qqt7oBKB+sxW3A==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-freebsd-x64@1.0.1':
|
|
|
|
|
resolution: {integrity: sha512-90+KLBkD9hZEjPQW1MDfwSt5J1L46EUKacpCZWyRuL6iIEO5CgWU0V/JnEgFsDOGyyYtiTvHc5bUdUTWd4I9Vg==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [freebsd]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-linux-arm64-gnu@1.0.1':
|
|
|
|
|
resolution: {integrity: sha512-rG0QlS65x9K/u3HrKafDf8cFKj5wV2JHGfl8abWgKew0GVPyp6vfsDweOwHbWAjcHtp2LHi6JHoW80/MTHm52Q==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-linux-arm64-musl@1.0.1':
|
|
|
|
|
resolution: {integrity: sha512-jAasbIvjZXCgX0TCuEFQr+4D6Lla/3AAVx2LmDuMjgG4xoIXzjKWl7c4chuaD+TI+prWT0X6LJcdzFT+ROKGHQ==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [musl]
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-linux-x64-gnu@1.0.1':
|
|
|
|
|
resolution: {integrity: sha512-Plgk5rPqqK2nocBGajkMVbGm010Z7dnUgq0wtnYRZbzWWxwWcXfZMPa8EYxrK4eE8SzpI7VlZP1tdVsdjgGwMw==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-linux-x64-musl@1.0.1':
|
|
|
|
|
resolution: {integrity: sha512-GW7AzGuWxtQkyHknHWYFdR0CHmW6is8rG2Rf4V6GNmMpmwtXt/ItWYWtBe4zqJWycMNazpfZKSw/BpT7/MVCXQ==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [musl]
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-wasm32-wasi@1.0.1':
|
|
|
|
|
resolution: {integrity: sha512-/nQVSTrqSsn7YdAc2R7Ips/tnw5SPUcl3D7QrXCNGPqjbatIspnaexvaOYNyKMU6xPu+pc0BTnKVmqhlJJCPLA==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>=14.0.0'}
|
|
|
|
|
cpu: [wasm32]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-win32-arm64-msvc@1.0.1':
|
|
|
|
|
resolution: {integrity: sha512-PFi7oJIBu5w7Qzh3dwFea3sHRO3pojMsaEnUIy22QvsW+UJfNQwJCryVrpoUt8m4QyZXI+saEq/0r4GwdoHYFQ==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-win32-ia32-msvc@1.0.1':
|
|
|
|
|
resolution: {integrity: sha512-gXkuYzxQsgkj05Zaq+KQTkHIN83dFAwMcTKa2aQcpYPRImFm2AQzEyLtpXmyCWzJ0F9ZYAOmbSyrNew8/us6bw==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [ia32]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-win32-x64-msvc@1.0.1':
|
|
|
|
|
resolution: {integrity: sha512-rEAf05nol3e3eei2sRButmgXP+6ATgm0/38MKhz9Isne82T4rPIMYsCIFj0kOisaGeVwoi2fnm7O9oWp5YVnYQ==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools@1.0.1':
|
|
|
|
|
resolution: {integrity: sha512-enkZYyuCdo+9jneCPE/0fjIta4wWnvVN9hBo2HuiMpRF0q3lzv1J6b/cl7i0mxZUKhBrV3aCKDBQnCOhwKbPmQ==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>= 10'}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-06-09 12:38:33 +02:00
|
|
|
'@next/env@16.2.7':
|
|
|
|
|
resolution: {integrity: sha512-tMJizPlj6ZYpBMMdK8S0LJufrP4QTdR6pcv9KQ/bVETPAmg0j1mlHE9G2c38UyGHxoBapgwuj7XjbGJ2RcDFOg==}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-06-09 12:38:33 +02:00
|
|
|
'@next/swc-darwin-arm64@16.2.7':
|
|
|
|
|
resolution: {integrity: sha512-vm1EDI/pVaBNNiychmxk3fft+OhQPVD9cIM/tReLZIQ3TfQ4kqI9DwKk00dzuS1ulC7icbrzCFrmRRlk9PfNdw==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>= 10'}
|
2024-03-05 14:23:26 +01:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2026-06-09 12:38:33 +02:00
|
|
|
'@next/swc-darwin-x64@16.2.7':
|
|
|
|
|
resolution: {integrity: sha512-O3IRSv1ZBL1zs0WrIgefTEcTKFVn+ryxBNe54erJ6KsD+2f/Mmt7g2jOYh8PSBdUwPtKQJuCsTMlZ7tIu2AcsQ==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>= 10'}
|
2024-03-05 14:23:26 +01:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2026-06-09 12:38:33 +02:00
|
|
|
'@next/swc-linux-arm64-gnu@16.2.7':
|
|
|
|
|
resolution: {integrity: sha512-Re6PZtjBDd0aMU+VcZcC/PrIvj4WhrjDYtMhhCVQamWN4L90EVP0pcEOBQD25prSlw7OzNw5QpHLWMilRLsRNw==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>= 10'}
|
2024-03-05 14:23:26 +01:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-06-09 12:38:33 +02:00
|
|
|
'@next/swc-linux-arm64-musl@16.2.7':
|
|
|
|
|
resolution: {integrity: sha512-qyogG9QtBzWxgJfeGBvOEHI3851gTfCF3wLZ5RDLTBJGAmE9p1qDwKCOdrBrvBzRvYDT+gUDp72pzlSEfAXgNA==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>= 10'}
|
2024-03-05 14:23:26 +01:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [musl]
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-06-09 12:38:33 +02:00
|
|
|
'@next/swc-linux-x64-gnu@16.2.7':
|
|
|
|
|
resolution: {integrity: sha512-Vhe4ZDuBpmMogrGi5D4R2Kq4JAQlj6+wvgaFYy31zfES0zPmt6TLA+cuYpM/OLrPZjo2MYQTHVqNUSCR6+fDZQ==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>= 10'}
|
2024-03-05 14:23:26 +01:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-06-09 12:38:33 +02:00
|
|
|
'@next/swc-linux-x64-musl@16.2.7':
|
|
|
|
|
resolution: {integrity: sha512-srvian89JahFLw1YLBEuhvPJ0DO5lpUeJQMXy4xYo7g628ZlNgXdNkqoxSAv9OYrBfByh6vxISMwW/mRbzCY+g==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>= 10'}
|
2024-03-05 14:23:26 +01:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [musl]
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-06-09 12:38:33 +02:00
|
|
|
'@next/swc-win32-arm64-msvc@16.2.7':
|
|
|
|
|
resolution: {integrity: sha512-GX3wvLpULFuRFJzwHaKfm7QZJ18F4ZSuxlPJ96BoBglCzBmdSjyeBKF+ZhWhvL/ckxNfLnNa7bsObO2ipYpszw==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>= 10'}
|
2024-03-05 14:23:26 +01:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2026-06-09 12:38:33 +02:00
|
|
|
'@next/swc-win32-x64-msvc@16.2.7':
|
|
|
|
|
resolution: {integrity: sha512-J4WlM72NMk076Qsg0jTdK3SNXatlSdnjW7L7oNGLst1tAGjHrJh/FYi+pw9wyIjEtGRKDNzD0zuiY16oWYWVaw==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>= 10'}
|
2024-03-05 14:23:26 +01:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
'@nodelib/fs.scandir@2.1.5':
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-vq24Bq3ym5HEQm2NKCr3yXDwjc7vTsEThRDnkp2DK9p1uqLR+DHurm/NOTo0KG7HYHU7eppKZj3MyqYuMBf62g==}
|
|
|
|
|
engines: {node: '>= 8'}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
'@nodelib/fs.stat@2.0.5':
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-RkhPPp2zrqDAQA/2jNhnztcPAlv64XdhIp7a7454A5ovI7Bukxgt7MX7udwAu3zg1DcpPU0rz3VV1SeaqvY4+A==}
|
|
|
|
|
engines: {node: '>= 8'}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
'@nodelib/fs.walk@1.2.8':
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-oGB+UxlgWcgQkgwo8GcEGwemoTFt3FIO9ababBmaGwXIoBKZ+GTy0pP185beGg7Llih/NSHSV2XAs1lnznocSg==}
|
|
|
|
|
engines: {node: '>= 8'}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@octokit/auth-token@6.0.0':
|
|
|
|
|
resolution: {integrity: sha512-P4YJBPdPSpWTQ1NU4XYdvHvXJJDxM6YwpS0FZHRgP7YFkdVxsWcpWGy/NVqlAA7PcPCnMacXlRm1y2PFZRWL/w==}
|
|
|
|
|
engines: {node: '>= 20'}
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/core@7.0.6':
|
|
|
|
|
resolution: {integrity: sha512-DhGl4xMVFGVIyMwswXeyzdL4uXD5OGILGX5N8Y+f6W7LhC1Ze2poSNrkF/fedpVDHEEZ+PHFW0vL14I+mm8K3Q==}
|
2025-09-19 17:08:41 +02:00
|
|
|
engines: {node: '>= 20'}
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@octokit/endpoint@11.0.3':
|
|
|
|
|
resolution: {integrity: sha512-FWFlNxghg4HrXkD3ifYbS/IdL/mDHjh9QcsNyhQjN8dplUoZbejsdpmuqdA76nxj2xoWPs7p8uX2SNr9rYu0Ag==}
|
2025-09-19 17:08:41 +02:00
|
|
|
engines: {node: '>= 20'}
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/graphql@9.0.3':
|
|
|
|
|
resolution: {integrity: sha512-grAEuupr/C1rALFnXTv6ZQhFuL1D8G5y8CN04RgrO4FIPMrtm+mcZzFG7dcBm+nq+1ppNixu+Jd78aeJOYxlGA==}
|
2025-09-19 17:08:41 +02:00
|
|
|
engines: {node: '>= 20'}
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/openapi-types@27.0.0':
|
|
|
|
|
resolution: {integrity: sha512-whrdktVs1h6gtR+09+QsNk2+FO+49j6ga1c55YZudfEG+oKJVvJLQi3zkOm5JjiUXAagWK2tI2kTGKJ2Ys7MGA==}
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/plugin-paginate-rest@14.0.0':
|
|
|
|
|
resolution: {integrity: sha512-fNVRE7ufJiAA3XUrha2omTA39M6IXIc6GIZLvlbsm8QOQCYvpq/LkMNGyFlB1d8hTDzsAXa3OKtybdMAYsV/fw==}
|
2025-09-19 17:08:41 +02:00
|
|
|
engines: {node: '>= 20'}
|
2025-04-11 17:19:55 +02:00
|
|
|
peerDependencies:
|
|
|
|
|
'@octokit/core': '>=6'
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@octokit/plugin-request-log@6.0.0':
|
|
|
|
|
resolution: {integrity: sha512-UkOzeEN3W91/eBq9sPZNQ7sUBvYCqYbrrD8gTbBuGtHEuycE4/awMXcYvx6sVYo7LypPhmQwwpUe4Yyu4QZN5Q==}
|
|
|
|
|
engines: {node: '>= 20'}
|
2025-04-11 17:19:55 +02:00
|
|
|
peerDependencies:
|
|
|
|
|
'@octokit/core': '>=6'
|
|
|
|
|
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/plugin-rest-endpoint-methods@17.0.0':
|
|
|
|
|
resolution: {integrity: sha512-B5yCyIlOJFPqUUeiD0cnBJwWJO8lkJs5d8+ze9QDP6SvfiXSz1BF+91+0MeI1d2yxgOhU/O+CvtiZ9jSkHhFAw==}
|
2025-09-19 17:08:41 +02:00
|
|
|
engines: {node: '>= 20'}
|
2025-04-11 17:19:55 +02:00
|
|
|
peerDependencies:
|
|
|
|
|
'@octokit/core': '>=6'
|
|
|
|
|
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/request-error@7.1.0':
|
|
|
|
|
resolution: {integrity: sha512-KMQIfq5sOPpkQYajXHwnhjCC0slzCNScLHs9JafXc4RAJI+9f+jNDlBNaIMTvazOPLgb4BnlhGJOTbnN0wIjPw==}
|
2025-09-19 17:08:41 +02:00
|
|
|
engines: {node: '>= 20'}
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@octokit/request@10.0.9':
|
|
|
|
|
resolution: {integrity: sha512-o8Bi3f608eyM+7BmBiUWxFsdjLb3/ym1cQek5LZOv9KkZcxRrHCPhhRzm6xjO6HVZ85ItD6+sTsjxo821SVa/A==}
|
2025-09-19 17:08:41 +02:00
|
|
|
engines: {node: '>= 20'}
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/rest@22.0.1':
|
|
|
|
|
resolution: {integrity: sha512-Jzbhzl3CEexhnivb1iQ0KJ7s5vvjMWcmRtq5aUsKmKDrRW6z3r84ngmiFKFvpZjpiU/9/S6ITPFRpn5s/3uQJw==}
|
2025-09-19 17:08:41 +02:00
|
|
|
engines: {node: '>= 20'}
|
|
|
|
|
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/types@16.0.0':
|
|
|
|
|
resolution: {integrity: sha512-sKq+9r1Mm4efXW1FCk7hFSeJo4QKreL/tTbR0rz/qx/r1Oa2VV83LTA/H/MuCOX7uCIJmQVRKBcbmWoySjAnSg==}
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-darwin-aarch64@1.3.14':
|
|
|
|
|
resolution: {integrity: sha512-Omj20SuiHBOUjUBIyqtkNjSUIjOtEOJwmbix/ZyFH4BaQ6OZTaaRWIR4TjHVz0yadHgli6lLTiAh1uarnvD49A==}
|
2026-04-23 12:51:20 +02:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-darwin-x64-baseline@1.3.14':
|
|
|
|
|
resolution: {integrity: sha512-OSfsTZstc898HHElhU4NccaBGOSSDn5VfahiVTnidZ9B/+wb7WTyfZJaBeJcfjwJ9H2W9uTh2TGtl3UfcXgV9g==}
|
2026-04-23 12:51:20 +02:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-darwin-x64@1.3.14':
|
|
|
|
|
resolution: {integrity: sha512-FFj3QdU/OhlDyZOJ8CWfN5eWLpRlT4qjZg7lMQi7jA6GuoY5ajlO1zWLP/MuHYRSbXQUvV52RejNi8DVnAp13w==}
|
2026-04-23 12:51:20 +02:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-freebsd-aarch64@1.3.14':
|
|
|
|
|
resolution: {integrity: sha512-LIKrXaFxAHybVO5Pf+9XP2FHUj/5APvXTUKk9dqHm5iFz4oH+W24cmhjkJirNujh9hKeTyrpWSe3no9JZKowIw==}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [freebsd]
|
|
|
|
|
|
|
|
|
|
'@oven/bun-freebsd-x64@1.3.14':
|
|
|
|
|
resolution: {integrity: sha512-uwD+fGUH1ADpIF3B1U2jWzzb20QwRLZfj5QZ28GUCGrAJ/nTmWrD6YYGsblCY1wuhldRez3lU40AyuvSCyLYmw==}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [freebsd]
|
|
|
|
|
|
|
|
|
|
'@oven/bun-linux-aarch64-android@1.3.14':
|
|
|
|
|
resolution: {integrity: sha512-y4kq5b85lsrmFb9Xvi4w9mA5IEFJkLMrSmYn06q24KjL9rUWDWO3VFZEtteZxUN5+ec3Zm5S8OnJw1umaCbVjA==}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [android]
|
|
|
|
|
|
|
|
|
|
'@oven/bun-linux-aarch64-musl@1.3.14':
|
|
|
|
|
resolution: {integrity: sha512-jmqOA92Cd1NL/1XBd4bFkJLxQ86K0RW7ohxS2qzzAvuitO4JiIxjjTeCspoU44zCozH72HpfZfUE2On31OjnWA==}
|
2026-04-23 12:51:20 +02:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [linux]
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-linux-aarch64@1.3.14':
|
|
|
|
|
resolution: {integrity: sha512-X5SsPZHs+iYO8R/efIcRtc7gT2Q2DgPfliCxEkx4cXBumwkw0c/EsHMNwH3EgGpCDaZ7IYVPhpCG/xBOQHEwZw==}
|
2026-04-23 12:51:20 +02:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [linux]
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-linux-x64-android@1.3.14':
|
|
|
|
|
resolution: {integrity: sha512-qe9e1d+3VAEU7nAA2ol9Jvmy/o99PVMSgZhHn7Q/9O3YcDrfEqyQ8zm4zoe5qTEo8HZH0dN03Le0Ys2eQPs7eg==}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [android]
|
|
|
|
|
|
|
|
|
|
'@oven/bun-linux-x64-baseline@1.3.14':
|
|
|
|
|
resolution: {integrity: sha512-q/8EdOC0yUE8FPeoOVq8/Pw5I9/tJaYmUfO/uDUAREx8IUnOJH1RJ5A3BjFqre8pvJoiZA9AovPJq5FnNNjSxA==}
|
2026-04-23 12:51:20 +02:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [linux]
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-linux-x64-musl-baseline@1.3.14':
|
|
|
|
|
resolution: {integrity: sha512-n6iE71G4lQE4XkrZhQQcL5YUlxDbnq6nqV7zeQi33PMsLT/0kYE+RvHOtBWZ3w0wMdXZfINmp63hIb9ijUBGtw==}
|
2026-04-23 12:51:20 +02:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [linux]
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-linux-x64-musl@1.3.14':
|
|
|
|
|
resolution: {integrity: sha512-GBCB/k/sIqcr06eTNgg7g46qiUv35Jasx4XiccJ/n7RGqrE4RWUD/XJBbWFprVPjvqd59+QtSnS99XGqvftHfg==}
|
2026-04-23 12:51:20 +02:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [linux]
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-linux-x64@1.3.14':
|
|
|
|
|
resolution: {integrity: sha512-7OVTAKvwfPmSbIV1HpdOoVVx5VRc427GuPPne93N6vk4eQBPId9nXmZDh9/zGaKPdbVjVtQSZafWQoUjx38Utw==}
|
2026-04-23 12:51:20 +02:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [linux]
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-windows-aarch64@1.3.14':
|
|
|
|
|
resolution: {integrity: sha512-T7s3x/BsVKQObGU6QDkZeI6wKynzqGbBH1yI77jrrj5siElclxr3DQrDIk8CV4G5/SJq2HHq4kpLyYY2DKCSmA==}
|
2026-04-23 12:51:20 +02:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-windows-x64-baseline@1.3.14':
|
|
|
|
|
resolution: {integrity: sha512-uIjLUC1S9DWgICzuoMba7vurBJnBruE4S5CxnvmZkdqWVXRzx1Rgu636HoH+k0qeaQCFh3jeG3JQ1y6fRHv0sw==}
|
2026-04-23 12:51:20 +02:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-windows-x64@1.3.14':
|
|
|
|
|
resolution: {integrity: sha512-mUFWL3BoYkNpjd8e9PqROiFF/1Xeotq20mABJsiQH62jM1g5zqWh4khw1RZ6bX8Q8fWvlPaxG1PjofkmjUi3vg==}
|
2026-04-23 12:51:20 +02:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@oxc-project/types@0.142.0':
|
|
|
|
|
resolution: {integrity: sha512-7W+2q5AKQVU36fkaryontrHn3YDt1RyUYXatw9i5H8ocYe2sPKSFB6eS8WNPeRKiN1qAWWZUPm7gwFzJGrccqQ==}
|
2025-02-04 15:14:52 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-android-arm64@2.6.0':
|
|
|
|
|
resolution: {integrity: sha512-trgpLSCKRC/huFjXX/Smh+0sWe4+YtKfktIToiMl59ghz7z+qkH6kMvNnUbLyRs9N11t8l4svSCs1+5B3rOAhA==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>= 10.0.0'}
|
2025-01-20 15:39:26 +01:00
|
|
|
cpu: [arm64]
|
2026-04-24 21:21:12 +02:00
|
|
|
os: [android]
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-darwin-arm64@2.6.0':
|
|
|
|
|
resolution: {integrity: sha512-Y3QV0gl7Q1zbfueunkWIERICbEojQFCgpyG7YqOGNFLsckXyI1xu9mAIUpKY9QBYzBtSkN8dBPwd3yiAO9ovMw==}
|
2025-02-04 15:14:52 +01:00
|
|
|
engines: {node: '>= 10.0.0'}
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-darwin-x64@2.6.0':
|
|
|
|
|
resolution: {integrity: sha512-Ohv6OpzhUfKYD7Beb8kDvG0jbIxORCYY1JRdZnaBtnjjkJxgD7ZVL0nw2sCYd0yTMKTvz3nnTnOF3cDifK+kvw==}
|
2025-02-04 15:14:52 +01:00
|
|
|
engines: {node: '>= 10.0.0'}
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-freebsd-x64@2.6.0':
|
|
|
|
|
resolution: {integrity: sha512-5HmXvDgs8VK+74jF9y9/2FE3/OnlcKmc56tjmSrEuZjpSZOGL+fvAu+HKJBdPs9uwoP2hE6TlSUpXZ/C5jUFmQ==}
|
2025-02-04 15:14:52 +01:00
|
|
|
engines: {node: '>= 10.0.0'}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [freebsd]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-linux-arm-glibc@2.6.0':
|
|
|
|
|
resolution: {integrity: sha512-Ps/hui3A+vMbjdqlqAowK2ZL8+BO8dBjxeWXj6npTBs3jx4wWmbPpaLuqwrQrSqIVMCnpWo238bJ1U37GhQOYg==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>= 10.0.0'}
|
2024-11-13 11:38:43 +01:00
|
|
|
cpu: [arm]
|
2024-09-02 15:23:46 +02:00
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2024-09-02 15:23:46 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-linux-arm-musl@2.6.0':
|
|
|
|
|
resolution: {integrity: sha512-9c6AUHgHoG+IY88MRIHupztQiQnrbqHYQjkM2btA+Bf/wQnQMuiD0Wfk1EVv3TlNT3x41uU71rn6E4xh/+zvkw==}
|
2025-02-04 15:14:52 +01:00
|
|
|
engines: {node: '>= 10.0.0'}
|
|
|
|
|
cpu: [arm]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [musl]
|
2025-02-04 15:14:52 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-linux-arm64-glibc@2.6.0':
|
|
|
|
|
resolution: {integrity: sha512-yHRqS2owEXe6Hic9z6Mh1ECsCd+ODVOGvZDyciqRd21+v+o+DnXMOrw50DSpIG2sb8GPEaPPmfeCAWKPJdq46g==}
|
2025-02-04 15:14:52 +01:00
|
|
|
engines: {node: '>= 10.0.0'}
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [linux]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-linux-arm64-musl@2.6.0':
|
|
|
|
|
resolution: {integrity: sha512-WhB2e/V7rqdHHWZusBSPuy5Ei8S6lSz6FE5TKKQz5h3a0O+C+mhY7vxU9b/stqvMb8beLnPY82ZrFTLKs+SrKA==}
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
engines: {node: '>= 10.0.0'}
|
2026-06-19 13:11:16 +02:00
|
|
|
cpu: [arm64]
|
2025-02-04 15:14:52 +01:00
|
|
|
os: [linux]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-linux-x64-glibc@2.6.0':
|
|
|
|
|
resolution: {integrity: sha512-ulGE6x6Oz6iAwg75T8YQSoguBWasniIbX+QWpaYPcCnDOpdWX3k+4xbEYPZVLxOuoJI+svJJPD3sEj8G7lrQ3A==}
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
engines: {node: '>= 10.0.0'}
|
2026-06-19 13:11:16 +02:00
|
|
|
cpu: [x64]
|
2025-02-04 15:14:52 +01:00
|
|
|
os: [linux]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-linux-x64-musl@2.6.0':
|
|
|
|
|
resolution: {integrity: sha512-tkBYKt7YQrjIJWYDnto2YgO8MRkjlMTSNoRHzsXinBqbLdeOM3L32wPZJvIZxqaLMfSlS/4sUjH/6STVP/XDLw==}
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
engines: {node: '>= 10.0.0'}
|
2026-06-19 13:11:16 +02:00
|
|
|
cpu: [x64]
|
2025-02-04 15:14:52 +01:00
|
|
|
os: [linux]
|
|
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
'@parcel/watcher-wasm@2.5.6':
|
|
|
|
|
resolution: {integrity: sha512-byAiBZ1t3tXQvc8dMD/eoyE7lTXYorhn+6uVW5AC+JGI1KtJC/LvDche5cfUE+qiefH+Ybq0bUCJU0aB1cSHUA==}
|
2025-01-07 09:57:34 -05:00
|
|
|
engines: {node: '>= 10.0.0'}
|
|
|
|
|
bundledDependencies:
|
|
|
|
|
- napi-wasm
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-win32-arm64@2.6.0':
|
|
|
|
|
resolution: {integrity: sha512-gIZAP23jaHjGWasY/TY6yL7NHFClf0Ga7FN+iINvk+KN94rhm94lYZhFsbYFNcA04/onvGD9kKmiJLJB2HbNwQ==}
|
2025-02-04 15:14:52 +01:00
|
|
|
engines: {node: '>= 10.0.0'}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-win32-x64@2.6.0':
|
|
|
|
|
resolution: {integrity: sha512-cA+/pXV2YkfxlIcXOQ5fSWqAzzPyD78/x5qbK/I0vUkrlYHA8TIz+MXjAbGouguKVSI4bOmkTSJ1/poVSsgt+A==}
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
engines: {node: '>= 10.0.0'}
|
2026-06-19 13:11:16 +02:00
|
|
|
cpu: [x64]
|
2025-02-04 15:14:52 +01:00
|
|
|
os: [win32]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher@2.6.0':
|
|
|
|
|
resolution: {integrity: sha512-7FNeNl8NCE7aINx7WXiKQrPYZWC/hvrTsmk6zmxbI7LTXE7hVek/n8AfVgpe2y82zl3w0HvCHN0bVKMBoJcC0w==}
|
2025-02-04 15:14:52 +01:00
|
|
|
engines: {node: '>= 10.0.0'}
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@playwright/test@1.62.1':
|
|
|
|
|
resolution: {integrity: sha512-DTcUc8qii+cpHvtOwggMtBRMjKZHXYWdw8syRYu2vtzuq4Wxphqq4NfCs5Zt44L6mA8rfDfj+PHnxFc/FeK6mQ==}
|
|
|
|
|
engines: {node: '>=20'}
|
2024-03-05 14:23:26 +01:00
|
|
|
hasBin: true
|
2024-03-20 16:40:50 -04:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-android-arm64@1.2.1':
|
|
|
|
|
resolution: {integrity: sha512-02hOeOSryYxVrOIphmLAsqnCJWxwlzFk+pEt/N/i6OgT3lShHO7xGCU5cpgchRDHboAEbSjzgGh+O/u1GswQmA==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: ^20.19.0 || >=22.12.0}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [android]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-darwin-arm64@1.2.1':
|
|
|
|
|
resolution: {integrity: sha512-fMsTOnN0OjFm3CyppWPitKnc8UlliVARUULW6cfU6AIqjdtgmSFWSk9vecHzZduv/yMWIHDlRhM1e8Iff9uAfA==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: ^20.19.0 || >=22.12.0}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-darwin-x64@1.2.1':
|
|
|
|
|
resolution: {integrity: sha512-1wjKdz/XLGKHaTNHjQveQ/B23TKx4ItAqm1JbyVuvNPc4Ze0Fb48s49TAd/2zcplPl8okE/UbTgmlVfwT7eFeQ==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: ^20.19.0 || >=22.12.0}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-freebsd-x64@1.2.1':
|
|
|
|
|
resolution: {integrity: sha512-Fa0jHR07E7YBN4vOEsbVf2briYNsuOowfLJaXULZM0ldMlaCaj2LJgLMbMe4iacRyZmvR8efFhgR9wKuGclQUg==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: ^20.19.0 || >=22.12.0}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [freebsd]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-linux-arm-gnueabihf@1.2.1':
|
|
|
|
|
resolution: {integrity: sha512-pzkgu1SSHGgRRyRZ4fbmSgmajbVt+epaLP99NDjFft69v/ypfTi6swBMiVdh2EkQ0OSnHE1lZDM7DRGkyAzUpA==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: ^20.19.0 || >=22.12.0}
|
|
|
|
|
cpu: [arm]
|
|
|
|
|
os: [linux]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-linux-arm64-gnu@1.2.1':
|
|
|
|
|
resolution: {integrity: sha512-QI5SEDY8cbiYWHx0VO4vIc3UlS6a32vXHjU8Qy/17adEmZIPuByJg13UEvo9c/UCiUkdcVWY83C+b+JrwnNyUg==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: ^20.19.0 || >=22.12.0}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2026-03-12 20:54:34 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-linux-arm64-musl@1.2.1':
|
|
|
|
|
resolution: {integrity: sha512-Sm41FyCeXqmYcERoYOCbGIL5hNfd8w9LQ7Y61Bev48HkcjaJqV/iiVOaiDxjVTRMS+QKrZmD8cfPt4uMVnvM+A==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: ^20.19.0 || >=22.12.0}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [musl]
|
2026-03-12 20:54:34 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-linux-ppc64-gnu@1.2.1':
|
|
|
|
|
resolution: {integrity: sha512-2x+WhXTGl9yJYPbltW/BSEPTVz9OIWQyER4N+gJEDWkkn904eRcBzELqh/Hf7K0w/ubGbKNMv0ZC+94QK/IFEg==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: ^20.19.0 || >=22.12.0}
|
|
|
|
|
cpu: [ppc64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2026-03-12 20:54:34 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-linux-s390x-gnu@1.2.1':
|
|
|
|
|
resolution: {integrity: sha512-eEjmQpuRQayHPWWnywaWHkFT3ToPbP3RYy42VVd/B9aBGDA+Ol25EIWHxKQST3IiWJjikCWUF7KtbfqwZrzVwQ==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: ^20.19.0 || >=22.12.0}
|
|
|
|
|
cpu: [s390x]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2026-03-12 20:54:34 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-linux-x64-gnu@1.2.1':
|
|
|
|
|
resolution: {integrity: sha512-/Orga1fZYkLc/56jBICcHrKchl8Z2UKdDSr3LG9ToWO1lQ6a4Livk9Xz+9WN91zsz5QR3XQz2NNoSDEvP6qadw==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: ^20.19.0 || >=22.12.0}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2026-03-12 20:54:34 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-linux-x64-musl@1.2.1':
|
|
|
|
|
resolution: {integrity: sha512-xxBJRL+0q0Kce7orznGWLuylHDY65vuARXZRpX+hPdv+DqK2c3NlCsVA98tlWzWNEE7yPqA/1NQ5nnCrj49Y5A==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: ^20.19.0 || >=22.12.0}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [musl]
|
2026-03-12 20:54:34 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-openharmony-arm64@1.2.1':
|
|
|
|
|
resolution: {integrity: sha512-M6AdXIXw3s+/8XpKMzdGDEXGS1S7kwUsy+rcTIUIOx5Ge4nXKCtAFHFV9YKkXvGcC5WMoTjAteLzlsQROVI0Yw==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: ^20.19.0 || >=22.12.0}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [openharmony]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-wasm32-wasi@1.2.1':
|
|
|
|
|
resolution: {integrity: sha512-/TX0SoRGojHzSAHpfVBbavRVSazg5U3h3Y3VXfcc0cdugq6kxdqw8LPGFiPr+/7gE/60zRcsOY2Vi9b9eT0jww==}
|
|
|
|
|
engines: {node: ^20.19.0 || ^22.13.0 || >=23.5.0}
|
2026-03-12 20:54:34 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-win32-arm64-msvc@1.2.1':
|
|
|
|
|
resolution: {integrity: sha512-EvRrivJieyHG+AO9lleZWgq+g0+S7oV2C51yuqlcyU/R9net+sI4Pj0F+lUoP2bEr6TWX3SqFaaS0SzfLxSzkw==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: ^20.19.0 || >=22.12.0}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-win32-x64-msvc@1.2.1':
|
|
|
|
|
resolution: {integrity: sha512-Z4eCmn5QJ/5+azF9knpLWKfVd9aidn0mAe9TpJgvBLId9Ax3t0+JVxBmT25Bv7NBbVW1TZyKjQjQReouMeH5UQ==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: ^20.19.0 || >=22.12.0}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@rolldown/pluginutils@1.0.1':
|
|
|
|
|
resolution: {integrity: sha512-2j9bGt5Jh8hj+vPtgzPtl72j0yRxHAyumoo6TNfAjsLB04UtpSvPbPcDcBMxz7n+9CYB0c1GxQFxYRg2jimqGw==}
|
2025-05-30 10:07:30 -04:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-android-arm-eabi@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-F5QXMSiFebS9hKZj02XhWLLnRpJ3B3AROP0tWbFBSj+6kCbg5m9j5JoHKd4mmSVy5mS/IMQloYgYxCuJC0fxEQ==}
|
2025-06-24 18:31:17 +02:00
|
|
|
cpu: [arm]
|
|
|
|
|
os: [android]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-android-arm64@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-GxxTKApUpzRhof7poWvCJHRF51C67u1R7D6DiluBE8wKU1u5GWE8t+v81JvJYtbawoBFX1hLv5Ei4eVjkWokaw==}
|
2025-06-24 18:31:17 +02:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [android]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-darwin-arm64@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-tua0TaJxMOB1R0V0RS1jFZ/RpURFDJIOR2A6jWwQeawuFyS4gBW+rntLRaQd0EQ4bd6Vp44Z2rXW+YYDBsj6IA==}
|
2025-06-24 18:31:17 +02:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-darwin-x64@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-CSKq7MsP+5PFIcydhAiR1K0UhEI1A2jWXVKHPCBZ151yOutENwvnPocgVHkivu2kviURtCEB6zUQw0vs8RrhMg==}
|
2025-06-24 18:31:17 +02:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-freebsd-arm64@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-+O8OkVdyvXMtJEciu2wS/pzm1IxntEEQx3z5TAVy4l32G0etZn+RsA48ARRrFm6Ri8fvqPQfgrvNxSjKAbnd3g==}
|
2025-06-24 18:31:17 +02:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [freebsd]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-freebsd-x64@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-Iw3oMskH3AfNuhU0MSN7vNbdi4me/NiYo2azqPz/Le16zHSa+3RRmliCMWWQmh4lcndccU40xcJuTYJZxNo/lw==}
|
2025-06-24 18:31:17 +02:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [freebsd]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-linux-arm-gnueabihf@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-EIPRXTVQpHyF8WOo219AD2yEltPehLTcTMz2fn6JsatLYSzQf00hj3rulF+yauOlF9/FtM2WpkT/hJh/KJFGhA==}
|
2025-06-24 18:31:17 +02:00
|
|
|
cpu: [arm]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2025-06-24 18:31:17 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-linux-arm-musleabihf@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-J3Yh9PzzF1Ovah2At+lHiGQdsYgArxBbXv/zHfSyaiFQEqvNv7DcW98pCrmdjCZBrqBiKrKKe2V+aaSGWuBe/w==}
|
2025-06-24 18:31:17 +02:00
|
|
|
cpu: [arm]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [musl]
|
2025-06-24 18:31:17 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-linux-arm64-gnu@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-BFDEZMYfUvLn37ONE1yMBojPxnMlTFsdyNoqncT0qFq1mAfllL+ATMMJd8TeuVMiX84s1KbcxcZbXInmcO2mRg==}
|
2025-06-24 18:31:17 +02:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2025-06-24 18:31:17 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-linux-arm64-musl@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-pc9EYOSlOgdQ2uPl1o9PF6/kLSgaUosia7gOuS8mB69IxJvlclko1MECXysjs5ryez1/5zjYqx3+xYU0TU6R1A==}
|
2025-06-24 18:31:17 +02:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [musl]
|
2025-06-24 18:31:17 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-linux-loong64-gnu@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-NxnomyxYerDh5n4iLrNa+sH+Z+U4BMEE46V2PgQ/hoB909i8gV1M5wPojWg9fk1jWpO3IQnOs20K4wyZuFLEFQ==}
|
2025-06-24 18:31:17 +02:00
|
|
|
cpu: [loong64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2025-06-24 18:31:17 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-linux-loong64-musl@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-nbJnQ8a3z1mtmrwImCYhc6BGpThAyYVRQxw9uKSKG4wR6aAYno9sVjJ0zaZcW9BPJX1GbrDPf+SvdWjgTuDmnw==}
|
|
|
|
|
cpu: [loong64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [musl]
|
2026-05-22 16:57:46 +02:00
|
|
|
|
|
|
|
|
'@rollup/rollup-linux-ppc64-gnu@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-2EU6acNrQLd8tYvo/LXW535wupT3m6fo7HKo6lr7ktQoItxTyOL1ZCR/GfGCuXl2vR+zmfI6eRXkSemafv+iVg==}
|
2025-06-24 18:31:17 +02:00
|
|
|
cpu: [ppc64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2025-06-24 18:31:17 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-linux-ppc64-musl@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-WeBtoMuaMxiiIrO2IYP3xs6GMWkJP2C0EoT8beTLkUPmzV1i/UcOSVw1d5r9KBODtHKilG5yFxsGRnBbK3wJ4A==}
|
|
|
|
|
cpu: [ppc64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [musl]
|
2026-05-22 16:57:46 +02:00
|
|
|
|
|
|
|
|
'@rollup/rollup-linux-riscv64-gnu@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-FJHFfqpKUI3A10WrWKiFbBZ7yVbGT4q4B5o1qKFFojqpaYoh9LrQgqWCmmcxQzVSXYtyB5bzkXrYzlHTs21MYA==}
|
2025-06-24 18:31:17 +02:00
|
|
|
cpu: [riscv64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2025-06-24 18:31:17 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-linux-riscv64-musl@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-mcEl6CUT5IAUmQf1m9FYSmVqCJlpQ8r8eyftFUHG8i9OhY7BkBXSUdnLH5DOf0wCOjcP9v/QO93zpmF1SptCCw==}
|
2025-06-24 18:31:17 +02:00
|
|
|
cpu: [riscv64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [musl]
|
2025-06-24 18:31:17 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-linux-s390x-gnu@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-ynt3JxVd2w2buzoKDWIyiV1pJW93xlQic1THVLXilz429oijRpSHivZAgp65KBu+cMcgf1eVVjdnTLvPxgCuoQ==}
|
2025-06-24 18:31:17 +02:00
|
|
|
cpu: [s390x]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2025-06-24 18:31:17 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-linux-x64-gnu@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-Boiz5+MsaROEWDf+GGEwF8VMHGhlUoQMtIPjOgA5fv4osupqTVnJteQNKJwUcnUog2G55jYXH7KZFFiJe0TEzQ==}
|
2025-06-24 18:31:17 +02:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2025-06-24 18:31:17 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-linux-x64-musl@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-+qfSY27qIrFfI/Hom04KYFw3GKZSGU4lXus51wsb5EuySfFlWRwjkKWoE9emgRw/ukoT4Udsj4W/+xxG8VbPKg==}
|
2025-06-24 18:31:17 +02:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [musl]
|
2025-06-24 18:31:17 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-openbsd-x64@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-VpTfOPHgVXEBeeR8hZ2O0F3aSso+JDWqTWmTmzcQKted54IAdUVbxE+j/MVxUsKa8L20HJhv3vUezVPoquqWjA==}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [openbsd]
|
|
|
|
|
|
|
|
|
|
'@rollup/rollup-openharmony-arm64@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-IPOsh5aRYuLv/nkU51X10Bf75Bsf6+gZdx1X+QP5QM6lIJFHHqbHLG0uJn/hWthzo13UAc2umiUorqZy3axoZg==}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [openharmony]
|
|
|
|
|
|
|
|
|
|
'@rollup/rollup-win32-arm64-msvc@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-4QzE9E81OohJ/HKzHhsqU+zcYYojVOXlFMs1DdyMT6qXl/niOH7AVElmmEdUNHHS/oRkc++d5k6Vy85zFs0DEw==}
|
2025-06-24 18:31:17 +02:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-win32-ia32-msvc@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-zTPgT1YuHHcd+Tmx7h8aml0FWFVelV5N54oHow9SLj+GfoDy/huQ+UV396N/C7KpMDMiPspRktzM1/0r1usYEA==}
|
2025-06-24 18:31:17 +02:00
|
|
|
cpu: [ia32]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-win32-x64-gnu@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-DRS4G7mi9lJxqEDezIkKCaUIKCrLUUDCUaCsTPCi/rtqaC6D/jjwslMQyiDU50Ka0JKpeXeRBFBAXwArY52vBw==}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
|
|
|
|
'@rollup/rollup-win32-x64-msvc@4.60.4':
|
|
|
|
|
resolution: {integrity: sha512-QVTUovf40zgTqlFVrKA1uXMVvU2QWEFWfAH8Wdc48IxLvrJMQVMBRjuQyUpzZCDkakImib9eVazbWlC6ksWtJw==}
|
2025-06-24 18:31:17 +02:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2026-05-23 17:14:48 +08:00
|
|
|
'@rspack/binding-darwin-arm64@2.0.2':
|
|
|
|
|
resolution: {integrity: sha512-0o7lbgBBsDlICWdjIH0q3e0BsSco4GRiImHWVfZSVEG+q2+ykZJvSvYCVhPM1Co375Z0S3VMPa/8SjcY1FHwlw==}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
|
|
|
|
'@rspack/binding-darwin-x64@2.0.2':
|
|
|
|
|
resolution: {integrity: sha512-tOwxZpoPlTlRs/w6UyUinXJ4TYRVHMlR7+eQxO1R3muKpixvhXQjtvoaY16HuFyTVky5F0IfOoWr3x9FEsgdLg==}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
|
|
|
|
'@rspack/binding-linux-arm64-gnu@2.0.2':
|
|
|
|
|
resolution: {integrity: sha512-1ZD4YFhG1rmgqj+W8hfwHyKV8xDxGsc/3KgU0FwmiVEX7JfzhCkgBO/xlCG79kRKSrzuVzt4icO/G3cCKn0pag==}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2026-05-23 17:14:48 +08:00
|
|
|
|
|
|
|
|
'@rspack/binding-linux-arm64-musl@2.0.2':
|
|
|
|
|
resolution: {integrity: sha512-/PtTkM/DsDLjeuXTmeJeRfbjCDbcL9jvoVgZrgxYFZ28y2cdLvbChbW9uigOzs5dQEs1CIBQXMTTj7KhdBTuQg==}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [musl]
|
2026-05-23 17:14:48 +08:00
|
|
|
|
|
|
|
|
'@rspack/binding-linux-x64-gnu@2.0.2':
|
|
|
|
|
resolution: {integrity: sha512-bBjsZxMHRaPo6X9SokApm6ucs+UhXtAJFyJJyuk2BH4XJsLeCU9Dz1vMwioeohFbJUUeTASVPm6/BL+RhSaunw==}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [glibc]
|
2026-05-23 17:14:48 +08:00
|
|
|
|
|
|
|
|
'@rspack/binding-linux-x64-musl@2.0.2':
|
|
|
|
|
resolution: {integrity: sha512-HjlpInqzabDNkhVsUJpsHPqa9QYVWBViJoyWNjzXCAW0vKMDvwaphyUvokSinX8FGTlZi/sr5UEaHJo6XtQ35g==}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [linux]
|
2026-06-25 19:14:10 +02:00
|
|
|
libc: [musl]
|
2026-05-23 17:14:48 +08:00
|
|
|
|
|
|
|
|
'@rspack/binding-wasm32-wasi@2.0.2':
|
|
|
|
|
resolution: {integrity: sha512-YaRYNFLJRpkGfYjSWR7n9f+nQKtrlmrrffpAn/blc2geHcRvXoBc5SCs1idPtsLhj7H9qWWhs7ucjyHy4csWFg==}
|
|
|
|
|
cpu: [wasm32]
|
|
|
|
|
|
|
|
|
|
'@rspack/binding-win32-arm64-msvc@2.0.2':
|
|
|
|
|
resolution: {integrity: sha512-d/3kTEKq+asLjRFPO96t+wfWiM7DLN76VQEPDD9bc1kdsZXlVJBuvyXfsgK8bbEvKplWXYcSsokhmEnuXrLOpg==}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
|
|
|
|
'@rspack/binding-win32-ia32-msvc@2.0.2':
|
|
|
|
|
resolution: {integrity: sha512-161cWineq3RW+Jdm1FAfSpXeUtYWvhB3kAbm46vNT9h/YYz+spwsFMvveAZ1nsVSVL0IC5lDBGUte7yUAY8K2g==}
|
|
|
|
|
cpu: [ia32]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
|
|
|
|
'@rspack/binding-win32-x64-msvc@2.0.2':
|
|
|
|
|
resolution: {integrity: sha512-y7Q0S1FE+OlkL5GMqLG0PwxrPw6E1r892KhGrGKE1Vdufe5YTEx6xTPxzZ+b7N2KPD7s9G1/iJmWHQxb1+Bjkg==}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
|
|
|
|
'@rspack/binding@2.0.2':
|
|
|
|
|
resolution: {integrity: sha512-0kZPplW9GWx8mfC6DfsaRY3QBIYPuUs42JfmSM6aSb8tMHZAXQeLeMB8M+h8i4SeI+aFtCgO6UuYGtyWf7+L+A==}
|
|
|
|
|
|
|
|
|
|
'@rspack/core@2.0.2':
|
|
|
|
|
resolution: {integrity: sha512-VM3UHOo26uC+4QSqY5tU1ybI7KuXY5rTof8nhFOaBY9SYau0Smvr+hMSAPmrmHwknB6dXT8yaNVxrj7I+qxE1Q==}
|
|
|
|
|
engines: {node: ^20.19.0 || >=22.12.0}
|
|
|
|
|
peerDependencies:
|
|
|
|
|
'@module-federation/runtime-tools': ^0.24.1 || ^2.0.0
|
|
|
|
|
'@swc/helpers': '>=0.5.1'
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@module-federation/runtime-tools':
|
|
|
|
|
optional: true
|
|
|
|
|
'@swc/helpers':
|
|
|
|
|
optional: true
|
|
|
|
|
|
2025-10-06 11:14:31 +02:00
|
|
|
'@sindresorhus/merge-streams@4.0.0':
|
|
|
|
|
resolution: {integrity: sha512-tlqY9xq5ukxTUZBmoOp+m61cqwQD5pHJtFY3Mn8CA8ps6yghLH/Hw8UPdqg4OLmFW3IFlcXnQNmo/dh8HzXYIQ==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=18'}
|
2024-09-18 16:45:43 +02:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
'@standard-schema/spec@1.1.0':
|
|
|
|
|
resolution: {integrity: sha512-l2aFy5jALhniG5HgqrD6jXLi/rUWrKvqN/qJx6yoJsgKhblVd+iqqU4RCXavm/jPityDo5TCvKMnpjKnOriy0w==}
|
2025-11-21 00:16:20 +01:00
|
|
|
|
2025-01-06 11:18:39 +01:00
|
|
|
'@swc/helpers@0.5.15':
|
|
|
|
|
resolution: {integrity: sha512-JQ5TuMi45Owi4/BIMAJBoSQoOJu12oOk/gADqlcUL9JEdHB8vyjUSsxqeNXnmXHjYKMi2WcYtezGEEhqUI/E2g==}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-11-19 16:19:08 +01:00
|
|
|
'@tailwindcss/aspect-ratio@0.4.2':
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-8QPrypskfBa7QIMuKHg2TA7BqES6vhBrDLOv8Unb6FcFyd3TjKbc6lcmb9UPQHxfl24sXoJ41ux/H7qQQvfaSQ==}
|
2024-11-19 16:19:08 +01:00
|
|
|
peerDependencies:
|
|
|
|
|
tailwindcss: '>=2.0.0 || >=3.0.0 || >=3.0.0-alpha.1'
|
|
|
|
|
|
2025-12-24 17:20:21 -05:00
|
|
|
'@tailwindcss/forms@0.5.11':
|
|
|
|
|
resolution: {integrity: sha512-h9wegbZDPurxG22xZSoWtdzc41/OlNEUQERNqI/0fOwa2aVlWGu7C35E/x6LDyD3lgtztFSSjKZyuVM0hxhbgA==}
|
2024-11-19 16:19:08 +01:00
|
|
|
peerDependencies:
|
2025-01-15 10:50:29 +01:00
|
|
|
tailwindcss: '>=3.0.0 || >= 3.0.0-alpha.1 || >= 4.0.0-alpha.20 || >= 4.0.0-beta.1'
|
2024-11-19 16:19:08 +01:00
|
|
|
|
2026-06-15 13:13:32 +00:00
|
|
|
'@tailwindcss/typography@0.5.20':
|
|
|
|
|
resolution: {integrity: sha512-hwbzQuNUfcPvbegQFatVPl/MY/tcM9KLl963hQ5laJKPh81TEZ1+dNG9PirGvcaDBkp+BCshExAyKVPW91dozw==}
|
2024-11-19 16:19:08 +01:00
|
|
|
peerDependencies:
|
2026-06-15 13:13:32 +00:00
|
|
|
tailwindcss: '>=3.0.0 || >=4.0.0 || insiders'
|
2024-11-19 16:19:08 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@turbo/darwin-64@2.10.8':
|
|
|
|
|
resolution: {integrity: sha512-po+7rfJfUnFXjWlcoN2RwhErgzCdRtBc1T26vYPcywHlggmCQiQe1uWaE4j+BibI2uY9/2pDoFzMN0rmSaPFOw==}
|
2026-04-24 21:21:12 +02:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@turbo/darwin-arm64@2.10.8':
|
|
|
|
|
resolution: {integrity: sha512-+zB2btDJ00lnPRuqOvpVvgl4x34k/djZQGZTTCfjn7JgNCl8QFY5Njo5+dqkY1g/+9gbbsnAvWm9CmJg9ebcXA==}
|
2026-04-24 21:21:12 +02:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [darwin]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@turbo/linux-64@2.10.8':
|
|
|
|
|
resolution: {integrity: sha512-K1dxqiVisyN7cViVsfQLs6xscQbYuI8aO2nbUhFURDACgEDfZRdP/b4CCxeosBJpcMfhYyiibWqJorCnvz9kKg==}
|
2026-04-24 21:21:12 +02:00
|
|
|
cpu: [x64]
|
2026-08-04 13:55:03 +02:00
|
|
|
os: [android, linux]
|
2026-04-24 21:21:12 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@turbo/linux-arm64@2.10.8':
|
|
|
|
|
resolution: {integrity: sha512-Gi77ibVnrE1fEmvr+/wBD/yvRqhwp/RQuCp2+//lv1U1wNFFyVg0V7Wj8FG9FXPFAw5QHReo8rxc9+wBSDZjzA==}
|
2026-04-24 21:21:12 +02:00
|
|
|
cpu: [arm64]
|
2026-08-04 13:55:03 +02:00
|
|
|
os: [android, linux]
|
2026-04-24 21:21:12 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@turbo/windows-64@2.10.8':
|
|
|
|
|
resolution: {integrity: sha512-znnLO1haJPYTHoKMKwlAvlkjRiYbbhBzME6wIGaMd+fwir23U6jVd1ecaTWWi1fbnRVqxMfgDBKseQ/hLKb83g==}
|
2026-04-24 21:21:12 +02:00
|
|
|
cpu: [x64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@turbo/windows-arm64@2.10.8':
|
|
|
|
|
resolution: {integrity: sha512-VN30vh3b3Czh2WzYHNTfF1FE0YMZ5aHsLO8dBMGHJewA6792wX6iJR8ZxlzFW6WdOu0gEAKIvlYhfyT81Wkm4Q==}
|
2026-04-24 21:21:12 +02:00
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2026-07-02 11:45:49 +02:00
|
|
|
'@tybys/wasm-util@0.10.3':
|
|
|
|
|
resolution: {integrity: sha512-F3fo1MYrRJYL3zER0OUOmkutjr1Vp23m7OsSgp7nq4SP6OqX6C/56XFIPAl5bt3zaBRjmW7SGz3u/6LwFpYcOg==}
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@types/bun@1.3.14':
|
|
|
|
|
resolution: {integrity: sha512-h1hFqFVcvAvD9j9K7ZW7vd82aSA+rTdznZa+5bwvCwqSB1jmmfLcbIWhOLx1/+boy/xmjgCs/OMUL8hRJSmnPw==}
|
2024-09-02 15:23:46 +02:00
|
|
|
|
2025-11-21 00:16:20 +01:00
|
|
|
'@types/chai@5.2.3':
|
|
|
|
|
resolution: {integrity: sha512-Mw558oeA9fFbv65/y4mHtXDs9bPnFMZAL/jxdPFUpOHHIXX91mcgEHbS5Lahr+pwZFR8A7GQleRWeI6cGFC2UA==}
|
|
|
|
|
|
|
|
|
|
'@types/deep-eql@4.0.2':
|
|
|
|
|
resolution: {integrity: sha512-c9h9dVVMigMPc4bwTvC5dxqtqJZwQPePsWjPlpSOnojbor6pGqdk541lfA7AqFQr5pB1BRdq0juY9db81BwyFw==}
|
|
|
|
|
|
2025-06-24 18:31:17 +02:00
|
|
|
'@types/estree@1.0.8':
|
|
|
|
|
resolution: {integrity: sha512-dWHzHa2WqEXI/O1E9OjrocMTKJl2mSrEolh1Iomrv6U+JuNwaHXsXx9bLu5gG7BUWFIN0skIQJQ/L1rIex4X6w==}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@types/estree@1.0.9':
|
|
|
|
|
resolution: {integrity: sha512-GhdPgy1el4/ImP05X05Uw4cw2/M93BCUmnEvWZNStlCzEKME4Fkk+YpoA5OiHNQmoS7Cafb8Xa3Pya8m1Qrzeg==}
|
|
|
|
|
|
2024-10-16 14:45:07 +00:00
|
|
|
'@types/json-schema@7.0.15':
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-5+fP8P8MFNC+AyZCDxrB2pkZFPGzqQWUzpSeuuVLvm8VMcorNYavBqoFcxK8bQz4Qsbn4oUEEem4wDLfcysGHA==}
|
2024-10-16 14:45:07 +00:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@types/node@22.20.1':
|
|
|
|
|
resolution: {integrity: sha512-EANqOCF9QFyra+4pfxUcX9STKJpCLjMbObVzljIJomAWSnuSIEAvyzEU53GaajbXJEgdh0iEcPL+DGvpUd4k1Q==}
|
2025-06-24 18:31:17 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@types/node@25.9.1':
|
|
|
|
|
resolution: {integrity: sha512-xfrlY7UD5rMJk3ZVJP8BNzS28J36YJg+xp+LPXV1TdWxr8uMH5A860QNxYDGQe/ylDSgjxE52Q9VnO7p75tJxg==}
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
'@types/postcss-import@14.0.3':
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-raZhRVTf6Vw5+QbmQ7LOHSDML71A5rj4+EqDzAbrZPfxfoGzFxMHRCq16VlddGIZpHELw0BG4G0YE2ANkdZiIQ==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2025-11-19 10:30:36 +00:00
|
|
|
'@types/react-dom@19.2.3':
|
|
|
|
|
resolution: {integrity: sha512-jp2L/eY6fn+KgVVQAOqYItbF0VY/YApe5Mz2F0aykSO8gx31bYCZyvSeYxCHKvzHG5eZjc+zyaS5BrBWya2+kQ==}
|
2025-01-10 14:10:04 +01:00
|
|
|
peerDependencies:
|
2025-10-09 14:58:37 -04:00
|
|
|
'@types/react': ^19.2.0
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@types/react@19.2.15':
|
|
|
|
|
resolution: {integrity: sha512-eRwcGNHve+E8qtEQSSRl6urh+rFop4v8gm6O8rGv25CodbvFdLjA1vVQ1KkiFE0w0UPOnb8tDiFKL5lp0rtY5Q==}
|
2025-11-20 10:54:23 -05:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@types/semver@7.8.0':
|
|
|
|
|
resolution: {integrity: sha512-1mAINjtQCXXeLkJ9ehXkwOcBpqtLxiVtKhpUf83DdRNdQKV0iXZpaHYqRr7nj+wvxuJzoAmAwXI+sCNMv1CzLQ==}
|
Ensure `@tailwindcss/upgrade` runs on Tailwind CSS v4 projects and is idempotent (#17717)
This PR ensures that the `@tailwindcss/upgrade` tool works on existing
Tailwind CSS v4 projects. This PR also ensures that the upgrade tool is
idempotent, meaning that it can be run multiple times and it should
result in the same output.
One awesome feature this unlocks is that you can run the upgrade tool on
your codebase at any time and upgrade classes if you still have some
legacy syntaxes, such as `bg-[var(--my-color)]`, in your muscle memory.
One small note: If something changed in the first run, re-running will
not work immediately because your git repository will not be clean and
the upgrade tool requires your git repo to be clean. But once you
verified and committed your changes, the upgrade tool will be
idempotent.
Idempotency is guaranteed by ensuring that some migrations are skipped
by checking what version of Tailwind CSS you are on _before_ the version
is upgraded.
For the Tailwind CSS version: We will resolve `tailwindcss` itself to
know the _actual_ version that is installed (the one resolved from
`node_modules`). Not the one available in your package.json. Your
`package.json` could be out of sync if you reverted changes but didn't
run `npm install` yet.
Back to Idempotency:
For example, we have migrations where we change the variant order of
stacked variants. If we would run these migrations every time you run
the upgrade tool then we would be flip-flopping the order every run.
See: https://tailwindcss.com/docs/upgrade-guide#variant-stacking-order
Another example is where we rename some utilities. For example, we
rename:
| Before | After |
| ----------- | ----------- |
| `shadow` | `shadow-sm` |
| `shadow-sm` | `shadow-xs` |
Notice how we have `shadow-sm` in both the `before` and `after` column.
If we would run the upgrade tool again, then we would eventually migrate
your original `shadow` to `shadow-sm` (first run) and then to
`shadow-xs` (second run). Which would result in the wrong shadow.
See: https://tailwindcss.com/docs/upgrade-guide#renamed-utilities
---
The order of upgrade steps changed a bit as well to make the internals
are easier to work with and reason about.
1. Find CSS files
2. Link JS config files (if you are in a Tailwind CSS v3 project)
3. Migrate the JS config files (if you are in a Tailwind CSS v3 project)
4. Upgrade Tailwind CSS to v4 (or the latest version at that point)
5. Migrate the stylesheets (we used to migrate the source files first)
6. Migrate the source files
This is done so that step 5 and 6 will always operate on a Tailwind CSS
v4 project and we don't need to check the version number again. This is
also necessary because your CSS file will now very likely contain
`@import "tailwindcss";` which doesn't exist in Tailwind CSS v3.
This also means that we can rely on the same internals that Tailwind CSS
actually uses for locating the source files. We will use
`@tailwindcss/oxide`'s scanner to find the source files (and it also
keeps your custom `@source` directives into account).
This PR also introduces a few actual migrations related to recent
features and changes we shipped.
1. We migrate deprecated classes to their new names:
| Before | After |
| --------------------- | --------------------- |
| `bg-left-top` | `bg-top-left` |
| `bg-left-bottom` | `bg-bottom-left` |
| `bg-right-top` | `bg-top-right` |
| `bg-right-bottom` | `bg-bottom-right` |
| `object-left-top` | `object-top-left` |
| `object-left-bottom` | `object-bottom-left` |
| `object-right-top` | `object-top-right` |
| `object-right-bottom` | `object-bottom-right` |
Introduced in:
- https://github.com/tailwindlabs/tailwindcss/pull/17378
- https://github.com/tailwindlabs/tailwindcss/pull/17437
2. We migrate simple arbitrary variants to their dedicated variant:
| Before | After |
| ----------------------- | ------------------- |
| `[&:user-valid]:flex` | `user-valid:flex` |
| `[&:user-invalid]:flex` | `user-invalid:flex` |
Introduced in:
- https://github.com/tailwindlabs/tailwindcss/pull/12370
3. We migrate `@media` variants to their dedicated variant:
| Before | After |
| ----------------------------------------------------- |
------------------------- |
| `[@media_print]:flex` | `print:flex` |
| `[@media(prefers-reduced-motion:no-preference)]:flex` |
`motion-safe:flex` |
| `[@media(prefers-reduced-motion:reduce)]:flex` | `motion-reduce:flex`
|
| `[@media(prefers-contrast:more)]:flex` | `contrast-more:flex` |
| `[@media(prefers-contrast:less)]:flex` | `contrast-less:flex` |
| `[@media(orientation:portrait)]:flex` | `portrait:flex` |
| `[@media(orientation:landscape)]:flex` | `landscape:flex` |
| `[@media(forced-colors:active)]:flex` | `forced-colors:flex` |
| `[@media(inverted-colors:inverted)]:flex` | `inverted-colors:flex` |
| `[@media(pointer:none)]:flex` | `pointer-none:flex` |
| `[@media(pointer:coarse)]:flex` | `pointer-coarse:flex` |
| `[@media(pointer:fine)]:flex` | `pointer-fine:flex` |
| `[@media(any-pointer:none)]:flex` | `any-pointer-none:flex` |
| `[@media(any-pointer:coarse)]:flex` | `any-pointer-coarse:flex` |
| `[@media(any-pointer:fine)]:flex` | `any-pointer-fine:flex` |
| `[@media(scripting:none)]:flex` | `noscript:flex` |
The new variants related to `inverted-colors`, `pointer`, `any-pointer`
and `scripting` were introduced in:
- https://github.com/tailwindlabs/tailwindcss/pull/11693
- https://github.com/tailwindlabs/tailwindcss/pull/16946
- https://github.com/tailwindlabs/tailwindcss/pull/11929
- https://github.com/tailwindlabs/tailwindcss/pull/17431
This also applies to the `not` case, e.g.:
| Before | After |
| --------------------------------------------------------- |
----------------------------- |
| `[@media_not_print]:flex` | `not-print:flex` |
| `[@media_not(prefers-reduced-motion:no-preference)]:flex` |
`not-motion-safe:flex` |
| `[@media_not(prefers-reduced-motion:reduce)]:flex` |
`not-motion-reduce:flex` |
| `[@media_not(prefers-contrast:more)]:flex` | `not-contrast-more:flex`
|
| `[@media_not(prefers-contrast:less)]:flex` | `not-contrast-less:flex`
|
| `[@media_not(orientation:portrait)]:flex` | `not-portrait:flex` |
| `[@media_not(orientation:landscape)]:flex` | `not-landscape:flex` |
| `[@media_not(forced-colors:active)]:flex` | `not-forced-colors:flex` |
| `[@media_not(inverted-colors:inverted)]:flex` |
`not-inverted-colors:flex` |
| `[@media_not(pointer:none)]:flex` | `not-pointer-none:flex` |
| `[@media_not(pointer:coarse)]:flex` | `not-pointer-coarse:flex` |
| `[@media_not(pointer:fine)]:flex` | `not-pointer-fine:flex` |
| `[@media_not(any-pointer:none)]:flex` | `not-any-pointer-none:flex` |
| `[@media_not(any-pointer:coarse)]:flex` |
`not-any-pointer-coarse:flex` |
| `[@media_not(any-pointer:fine)]:flex` | `not-any-pointer-fine:flex` |
| `[@media_not(scripting:none)]:flex` | `not-noscript:flex` |
For each candidate, we run a set of upgrade migrations. If at the end of
the migrations the original candidate is still the same as the new
candidate, then we will parse & print the candidate one more time to
pretty print into consistent classes. Luckily parsing is cached so there
is no real downside overhead.
Consistency (especially with arbitrary variants and values) will reduce
your CSS file because there will be fewer "versions" of your class.
Concretely, the pretty printing will apply changes such as:
| Before | After |
| ---------------------- | ----------------- |
| `bg-[var(--my-color)]` | `bg-(--my-color)` |
| `bg-[rgb(0,_0,_0)]` | `bg-[rgb(0,0,0)]` |
Another big important reason for this change is that these classes on
their own
would have been migrated _if_ another migration was relevant for this
candidate.
This means that there are were some inconsistencies. E.g.:
| Before | After | Reason |
| ----------------------- | ---------------------- |
------------------------------------ |
| `!bg-[var(--my-color)]` | `bg-(--my-color)!` | Because the `!` is in
the wrong spot |
| `bg-[var(--my-color)]` | `bg-[var(--my-color)]` | Because no
migrations rand |
As you can see, the way the `--my-color` variable is used, is different.
This
changes will make sure it will now always be consistent:
| Before | After |
| ----------------------- | ---------------------- |
| `!bg-[var(--my-color)]` | `bg-(--my-color)!` |
| `bg-[var(--my-color)]` | `bg-(--my-color)` |
Yay!
Of course, if you don't want these more cosmetic changes, you can always
ignore the upgrade and revert these changes and only commit the changes
you want.
# Test plan
- All existing tests still pass.
- But I had to delete 1 test (we tested that Tailwind CSS v3 was
required).
- And had to mock the `version.isMajor` call to ensure we run the
individual migration tests correctly.
- Added new tests to test:
1. Migrating Tailwind CSS v4 projects works
1. Idempotency of the upgrade tool
[ci-all]
2025-04-22 17:10:46 +02:00
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@vitejs/plugin-react@6.0.2':
|
|
|
|
|
resolution: {integrity: sha512-DlSMqo4WhThw4vB8Mpn0Woe9J+Jfq1geJ61AKW0QEgLzGMNwtIMdxbDUzLxcun8W7NbJO0e2Jg/Nxm3cCSVzzg==}
|
2025-08-15 07:37:08 -04:00
|
|
|
engines: {node: ^20.19.0 || >=22.12.0}
|
2024-05-24 15:07:44 +02:00
|
|
|
peerDependencies:
|
2026-04-23 12:51:20 +02:00
|
|
|
'@rolldown/plugin-babel': ^0.1.7 || ^0.2.0
|
|
|
|
|
babel-plugin-react-compiler: ^1.0.0
|
|
|
|
|
vite: ^8.0.0
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@rolldown/plugin-babel':
|
|
|
|
|
optional: true
|
|
|
|
|
babel-plugin-react-compiler:
|
|
|
|
|
optional: true
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@vitest/expect@4.1.10':
|
|
|
|
|
resolution: {integrity: sha512-YsCn+qAk1GWjQOWFEsEcL2gNQ0zmVmQu3T03qP6UyjhtmdtwtbuI+DASn/7iQB3HGTXkdBwGddzxPlmiql5vlA==}
|
2025-11-21 00:16:20 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@vitest/mocker@4.1.10':
|
|
|
|
|
resolution: {integrity: sha512-v0xaezt+DKEmKfaxg133ldzADrwLGd7Ze1MfQQTYfvs8OqZIwbxyxaYURivwV7sWy5fqn3rH5uOrSp07bp44Ow==}
|
2025-11-21 00:16:20 +01:00
|
|
|
peerDependencies:
|
|
|
|
|
msw: ^2.4.9
|
2026-04-24 21:21:12 +02:00
|
|
|
vite: ^6.0.0 || ^7.0.0 || ^8.0.0
|
2025-11-21 00:16:20 +01:00
|
|
|
peerDependenciesMeta:
|
|
|
|
|
msw:
|
|
|
|
|
optional: true
|
|
|
|
|
vite:
|
|
|
|
|
optional: true
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@vitest/pretty-format@4.1.10':
|
|
|
|
|
resolution: {integrity: sha512-W1HsjSH4MXQ9YfmmhLAoIYf1HRfekQCGngeIgcei6MP5QQGWUe0gkopdZQaVCFO+JDJMrAJGwa5pRpNpvy4P8Q==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@vitest/runner@4.1.10':
|
|
|
|
|
resolution: {integrity: sha512-IKI6kpIH+LmpROplyLwBBaCfMgOZOMsygVa6BARD6ahA04VRuJSa6OaVG7kRvSEMD870Vd91rSSw0eegtWyLGg==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@vitest/snapshot@4.1.10':
|
|
|
|
|
resolution: {integrity: sha512-xRkfOT1qpTAi/Ti4Y1LtfRc3kEuqxGw59eN2jN9pRWMtS/XDevekhcFSqvQqjUNGksfjMJu3Y+oJ+4Ypn2OaJw==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@vitest/spy@4.1.10':
|
|
|
|
|
resolution: {integrity: sha512-PLf/Ugvoq5wO/b4rwYCR1h2PSIdXz7wnkQFMiUpLdtM7l6pqVFcQIBEHyT1+l+cj7mNwAfZHzqXqDyjvOuwbDw==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@vitest/utils@4.1.10':
|
|
|
|
|
resolution: {integrity: sha512-fy9am/HWxbaGt/Sawrp90vt6Y6jQwf1RX77cz3uwoJwJVMli/e1IEwRPnMNJ7vKfPTwo0diXifkpPvwH9v7nGA==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
'@webassemblyjs/ast@1.14.1':
|
|
|
|
|
resolution: {integrity: sha512-nuBEDgQfm1ccRp/8bCQrx1frohyufl4JlbMMZ4P1wpeOfDhF6FQkxZJ1b/e+PLwr6X1Nhw6OLme5usuBWYBvuQ==}
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/floating-point-hex-parser@1.13.2':
|
|
|
|
|
resolution: {integrity: sha512-6oXyTOzbKxGH4steLbLNOu71Oj+C8Lg34n6CqRvqfS2O71BxY6ByfMDRhBytzknj9yGUPVJ1qIKhRlAwO1AovA==}
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/helper-api-error@1.13.2':
|
|
|
|
|
resolution: {integrity: sha512-U56GMYxy4ZQCbDZd6JuvvNV/WFildOjsaWD3Tzzvmw/mas3cXzRJPMjP83JqEsgSbyrmaGjBfDtV7KDXV9UzFQ==}
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/helper-buffer@1.14.1':
|
|
|
|
|
resolution: {integrity: sha512-jyH7wtcHiKssDtFPRB+iQdxlDf96m0E39yb0k5uJVhFGleZFoNw1c4aeIcVUPPbXUVJ94wwnMOAqUHyzoEPVMA==}
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/helper-numbers@1.13.2':
|
|
|
|
|
resolution: {integrity: sha512-FE8aCmS5Q6eQYcV3gI35O4J789wlQA+7JrqTTpJqn5emA4U2hvwJmvFRC0HODS+3Ye6WioDklgd6scJ3+PLnEA==}
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/helper-wasm-bytecode@1.13.2':
|
|
|
|
|
resolution: {integrity: sha512-3QbLKy93F0EAIXLh0ogEVR6rOubA9AoZ+WRYhNbFyuB70j3dRdwH9g+qXhLAO0kiYGlg3TxDV+I4rQTr/YNXkA==}
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/helper-wasm-section@1.14.1':
|
|
|
|
|
resolution: {integrity: sha512-ds5mXEqTJ6oxRoqjhWDU83OgzAYjwsCV8Lo/N+oRsNDmx/ZDpqalmrtgOMkHwxsG0iI//3BwWAErYRHtgn0dZw==}
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/ieee754@1.13.2':
|
|
|
|
|
resolution: {integrity: sha512-4LtOzh58S/5lX4ITKxnAK2USuNEvpdVV9AlgGQb8rJDHaLeHciwG4zlGr0j/SNWlr7x3vO1lDEsuePvtcDNCkw==}
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/leb128@1.13.2':
|
|
|
|
|
resolution: {integrity: sha512-Lde1oNoIdzVzdkNEAWZ1dZ5orIbff80YPdHx20mrHwHrVNNTjNr8E3xz9BdpcGqRQbAEa+fkrCb+fRFTl/6sQw==}
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/utf8@1.13.2':
|
|
|
|
|
resolution: {integrity: sha512-3NQWGjKTASY1xV5m7Hr0iPeXD9+RDobLll3T9d2AO+g3my8xy5peVyjSag4I50mR1bBSN/Ct12lo+R9tJk0NZQ==}
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/wasm-edit@1.14.1':
|
|
|
|
|
resolution: {integrity: sha512-RNJUIQH/J8iA/1NzlE4N7KtyZNHi3w7at7hDjvRNm5rcUXa00z1vRz3glZoULfJ5mpvYhLybmVcwcjGrC1pRrQ==}
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/wasm-gen@1.14.1':
|
|
|
|
|
resolution: {integrity: sha512-AmomSIjP8ZbfGQhumkNvgC33AY7qtMCXnN6bL2u2Js4gVCg8fp735aEiMSBbDR7UQIj90n4wKAFUSEd0QN2Ukg==}
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/wasm-opt@1.14.1':
|
|
|
|
|
resolution: {integrity: sha512-PTcKLUNvBqnY2U6E5bdOQcSM+oVP/PmrDY9NzowJjislEjwP/C4an2303MCVS2Mg9d3AJpIGdUFIQQWbPds0Sw==}
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/wasm-parser@1.14.1':
|
|
|
|
|
resolution: {integrity: sha512-JLBl+KZ0R5qB7mCnud/yyX08jWFw5MsoalJ1pQ4EdFlgj9VdXKGuENGsiCIjegI1W7p91rUlcB/LB5yRJKNTcQ==}
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/wast-printer@1.14.1':
|
|
|
|
|
resolution: {integrity: sha512-kPSSXE6De1XOR820C90RIo2ogvZG+c3KiHzqUoO/F34Y2shGzesfqv7o57xrxovZJH/MetF5UjroJ/R/3isoiw==}
|
|
|
|
|
|
|
|
|
|
'@xtuc/ieee754@1.2.0':
|
|
|
|
|
resolution: {integrity: sha512-DX8nKgqcGwsc0eJSqYt5lwP4DH5FlHnmuWWBRy7X0NcaGR0ZtuyeESgMwTYVEtxmsNGY+qit4QYT/MIYTOTPeA==}
|
|
|
|
|
|
|
|
|
|
'@xtuc/long@4.2.2':
|
|
|
|
|
resolution: {integrity: sha512-NuHqBY1PB/D8xU6s/thBgOAiAP7HOYDQ32+BFZILJ8ivkUkAHQnWfn6WhL79Owj1qmUnoN/YPhktdIoucipkAQ==}
|
|
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
acorn@8.16.0:
|
|
|
|
|
resolution: {integrity: sha512-UVJyE9MttOsBQIDKw1skb9nAwQuR5wuGD3+82K6JgJlm/Y+KI92oNsMNGZCYdDsVtRHSak0pcV5Dno5+4jh9sw==}
|
|
|
|
|
engines: {node: '>=0.4.0'}
|
|
|
|
|
hasBin: true
|
|
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
ajv-formats@2.1.1:
|
|
|
|
|
resolution: {integrity: sha512-Wx0Kx52hxE7C18hkMEggYlEifqWZtYaRgouJor+WMdPnQyEK13vgEWyVNup7SoeeoLMsr4kf5h6dOW11I15MUA==}
|
|
|
|
|
peerDependencies:
|
|
|
|
|
ajv: ^8.0.0
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
ajv:
|
|
|
|
|
optional: true
|
|
|
|
|
|
|
|
|
|
ajv-keywords@5.1.0:
|
|
|
|
|
resolution: {integrity: sha512-YCS/JNFAUyr5vAuhk1DWm1CBxRHW9LbJ2ozWeemrIqpbsqKjHVxYPyi5GC0rjZIT5JxJ3virVTS8wk4i/Z+krw==}
|
|
|
|
|
peerDependencies:
|
|
|
|
|
ajv: ^8.8.2
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
ajv@8.20.0:
|
|
|
|
|
resolution: {integrity: sha512-Thbli+OlOj+iMPYFBVBfJ3OmCAnaSyNn4M1vz9T6Gka5Jt9ba/HIR56joy65tY6kx/FCF5VXNB819Y7/GUrBGA==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
|
|
|
|
any-promise@1.3.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-7UvmKalWRt1wgjL1RrGxoSJW/0QZFIegpeGvZG9kjp8vrRu55XTHbwnqq2GpXm9uLbcuhxm3IqX9OB4MZR1b2A==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
|
|
|
|
anymatch@3.1.3:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-KMReFUr0B4t+D+OBkjR3KYqvocp2XaSzO55UcB6mgQMd3KbcE+mWTyvVV7D/zsdEbNnV6acZUutkiHQXvTr1Rw==}
|
|
|
|
|
engines: {node: '>= 8'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2024-10-24 11:00:25 -04:00
|
|
|
arg@5.0.2:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-PYjyFOLKQ9y57JvQ6QLo8dAgNqswh8M1RMJYdQduT6xbWSgK36P/Z/v+p888pM69jMMfS8Xd8F6I1kQ/I9HUGg==}
|
2024-10-24 11:00:25 -04:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
argparse@2.0.1:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2024-08-02 10:33:14 +02:00
|
|
|
assertion-error@2.0.1:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-Izi8RQcffqCeNVgFigKli1ssklIbpHnCYc6AknXGYoB6grJqyeby7jv12JUQgmTAnIDnbck1uxksT4dzN3PWBA==}
|
|
|
|
|
engines: {node: '>=12'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-04-23 12:51:20 +02:00
|
|
|
autoprefixer@10.5.0:
|
|
|
|
|
resolution: {integrity: sha512-FMhOoZV4+qR6aTUALKX2rEqGG+oyATvwBt9IIzVR5rMa2HRWPkxf+P+PAJLD1I/H5/II+HuZcBJYEFBpq39ong==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: ^10 || ^12 || >=14}
|
2024-10-24 11:00:25 -04:00
|
|
|
hasBin: true
|
|
|
|
|
peerDependencies:
|
|
|
|
|
postcss: ^8.1.0
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
baseline-browser-mapping@2.10.31:
|
|
|
|
|
resolution: {integrity: sha512-MujYO3eP72uvmSE0i4wltsodRfIpZATP3jvzRNRGGxgzId7aVocVJJV3nf01qnzzKFGxQVC9bpWxl5cjxTr/7Q==}
|
2026-04-03 21:07:27 +02:00
|
|
|
engines: {node: '>=6.0.0'}
|
2025-11-17 17:22:37 -05:00
|
|
|
hasBin: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
before-after-hook@4.0.0:
|
|
|
|
|
resolution: {integrity: sha512-q6tR3RPqIB1pMiTRMFcZwuG5T8vwp+vUvEG0vuI6B+Rikh5BfPp2fQ82c925FOs+b0lcFQ8CFrL+KbilfZFhOQ==}
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
binary-extensions@2.3.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-Ceh+7ox5qe7LJuLHoY0feh3pHuUDHAcRUeyL2VYghZwfpkNIy/+8Ocg0a3UuSoYzavmylwuLWQOf3hl0jjMMIw==}
|
|
|
|
|
engines: {node: '>=8'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
|
|
|
|
braces@3.0.3:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-yQbXgO/OSZVD2IsiLlro+7Hf6Q18EJrKSEsdoMzKePKXct3gvD8oLcOQdIzGupr5Fj+EDe8gO/lxc1BzfMpxvA==}
|
|
|
|
|
engines: {node: '>=8'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-04-23 12:51:20 +02:00
|
|
|
browserslist@4.28.2:
|
|
|
|
|
resolution: {integrity: sha512-48xSriZYYg+8qXna9kwqjIVzuQxi+KYWp2+5nCYnYKPTr0LvD89Jqk2Or5ogxz0NUMfIjhh2lIUX/LyX9B4oIg==}
|
|
|
|
|
engines: {node: ^6 || ^7 || ^8 || ^9 || ^10 || ^11 || ^12 || >=13.7}
|
|
|
|
|
hasBin: true
|
|
|
|
|
|
2024-09-04 10:09:24 +02:00
|
|
|
buffer-from@1.1.2:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-E+XQCRwSbaaiChtv6k6Dwgc+bx+Bs6vuKJHHl5kox/BaKbhiXzqQOwK4cO22yElGp2OCmjwVhT3HmxgyPGnJfQ==}
|
2024-09-04 10:09:24 +02:00
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
bun-types@1.3.14:
|
|
|
|
|
resolution: {integrity: sha512-4N0ig0fEomHt5R0KCFWjovxow98rIoRwKolrYdCcknNwMekCXRnWEUvgu5soYV8QXtVsrUD8B95MBOZGPvr6KQ==}
|
2024-09-02 15:23:46 +02:00
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
bun@1.3.14:
|
|
|
|
|
resolution: {integrity: sha512-aB6GVd42x1Y5ie1K16SF+oLGtgSkwX9hgoDdIW88pjvfTccU8F1vfpoOt34QLv0dZ1v3XimtaxPlZUG81Gx9Zg==}
|
2026-06-19 13:11:16 +02:00
|
|
|
cpu: [arm64, x64]
|
2026-05-21 17:58:55 +02:00
|
|
|
os: [darwin, linux, android, freebsd, win32]
|
2024-12-18 18:06:26 +00:00
|
|
|
hasBin: true
|
|
|
|
|
|
2025-03-05 10:59:27 +00:00
|
|
|
bundle-require@5.1.0:
|
|
|
|
|
resolution: {integrity: sha512-3WrrOuZiyaaZPWiEt4G3+IffISVC9HYlWueJEBWED4ZH4aIAC2PnkdnuRrR94M+w6yGWn4AglWtJtBI8YqvgoA==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: ^12.20.0 || ^14.13.1 || >=16.0.0}
|
2024-05-24 15:07:44 +02:00
|
|
|
peerDependencies:
|
2024-08-02 10:33:14 +02:00
|
|
|
esbuild: '>=0.18'
|
2024-05-24 15:07:44 +02:00
|
|
|
|
|
|
|
|
cac@6.7.14:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-b6Ilus+c3RrdDk+JhLKUAQfzzgLEPy6wcXqS7f/xe1EETvsDP6GORG7SFuOs6cID5YkqchW/LXZbX5bc8j7ZcQ==}
|
|
|
|
|
engines: {node: '>=8'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2024-10-24 11:00:25 -04:00
|
|
|
camelcase-css@2.0.1:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-QOSvevhslijgYwRx6Rv7zKdMF8lbRmx+uQGx2+vDc+KI/eBnsy9kit5aj23AgGu3pa4t9AgwbnXWqS+iOY+2aA==}
|
|
|
|
|
engines: {node: '>= 6'}
|
2024-10-24 11:00:25 -04:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
caniuse-lite@1.0.30001793:
|
|
|
|
|
resolution: {integrity: sha512-iwSsYWaCOoh26cV8NwNRViHlrfUvYsHDfRVcbtmw0Kg6PJIZZXwMkj1442FYLBGkeUf1juAsU3DTfxW579mrPA==}
|
2026-04-23 12:51:20 +02:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
chai@6.2.2:
|
|
|
|
|
resolution: {integrity: sha512-NUPRluOfOiTKBKvWPtSD4PhFvWCqOi0BGStNWs57X9js7XGTprSmFoz5F0tWhR4WPjNeR9jXqdC7/UpSJTnlRg==}
|
2025-11-21 00:16:20 +01:00
|
|
|
engines: {node: '>=18'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-01-06 12:44:27 +01:00
|
|
|
chardet@2.1.1:
|
|
|
|
|
resolution: {integrity: sha512-PsezH1rqdV9VvyNhxxOW32/d75r01NY7TQCmOqomRo15ZSOKbpTFVsfjghxo6JloQUCGnH4k1LGu0R4yCLlWQQ==}
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
chokidar@3.6.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-7VT13fmjotKpGipCW9JEQAusEPE+Ei8nl6/g4FBAmIm0GOOLMua9NDDo/DWp0ZAxCr3cPq5ZpBqmPAQgDda2Pw==}
|
|
|
|
|
engines: {node: '>= 8.10.0'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2025-02-03 11:20:51 +01:00
|
|
|
chokidar@4.0.3:
|
|
|
|
|
resolution: {integrity: sha512-Qgzu8kfBvo+cA4962jnP1KkS6Dop5NS6g7R5LFYJr4b8Ub94PPQXUksCw9PvXoeXPRRddRNC5C1JQUR2SMGtnA==}
|
|
|
|
|
engines: {node: '>= 14.16.0'}
|
|
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
chrome-trace-event@1.0.4:
|
|
|
|
|
resolution: {integrity: sha512-rNjApaLzuwaOTjCiT8lSDdGN1APCiqkChLMJxJPWLunPAt5fy8xgU9/jNOchV84wfIxrA0lRQB7oCT8jrn/wrQ==}
|
|
|
|
|
engines: {node: '>=6.0'}
|
|
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
citty@0.2.2:
|
|
|
|
|
resolution: {integrity: sha512-+6vJA3L98yv+IdfKGZHBNiGW5KHn22e/JwID0Strsz8h4S/csAu/OuICwxrg44k5MRiZHWIo8XXuJgQTriRP4w==}
|
|
|
|
|
|
2025-04-11 17:19:55 +02:00
|
|
|
cli-width@4.1.0:
|
|
|
|
|
resolution: {integrity: sha512-ouuZd4/dm2Sw5Gmqy6bGyNNNe1qt9RpmxveLSO7KcgsTnU7RXfsw+/bukWGo1abgBiMAic068rclZsO4IWmmxQ==}
|
|
|
|
|
engines: {node: '>= 12'}
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
client-only@0.0.1:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-IV3Ou0jSMzZrd3pZ48nLkT9DA7Ag1pnPzaiQhpW7c3RbcqqzvzzVu+L8gfqMp/8IM2MQtSiqaCxrrcfu8I8rMA==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2025-04-11 17:19:55 +02:00
|
|
|
clipanion@4.0.0-rc.4:
|
|
|
|
|
resolution: {integrity: sha512-CXkMQxU6s9GklO/1f714dkKBMu1lopS1WFF0B8o4AxPykR1hpozxSiUZ5ZUeBjfPgCWqbcNOtZVFhB8Lkfp1+Q==}
|
|
|
|
|
peerDependencies:
|
|
|
|
|
typanion: '*'
|
|
|
|
|
|
|
|
|
|
colorette@2.0.20:
|
|
|
|
|
resolution: {integrity: sha512-IfEDxwoWIjkeXL1eXcDiow4UbKjhLdq6/EuSVR9GMN7KVH3r9gQ83e73hsz1Nd1T3ijd5xv1wcWRYO+D6kCI2w==}
|
|
|
|
|
|
2024-09-04 10:09:24 +02:00
|
|
|
commander@2.20.3:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-GpVkmM8vF2vQUkj2LvZmD35JxeJOLCwJ9cUkugyk2nuhbv3+mJvpLYYt+0+USMxE+oj+ey/lJEnhZw75x/OMcQ==}
|
2024-09-04 10:09:24 +02:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
commander@4.1.1:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-NOKm8xhkzAjzFx8B2v5OAHT+u5pRQc2UCa2Vq9jYL/31o2wi9mxBA7LIFs3sV5VSC49z6pEhfbMULvShKj26WA==}
|
|
|
|
|
engines: {node: '>= 6'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2025-01-07 09:57:34 -05:00
|
|
|
confbox@0.1.8:
|
|
|
|
|
resolution: {integrity: sha512-RMtmw0iFkeR4YV+fUOSucriAQNb9g8zFR52MWCtl+cCZOFRNL6zeB395vPzFhEjjn4fMxXudmELnl/KF/WrK6w==}
|
|
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
consola@3.4.2:
|
|
|
|
|
resolution: {integrity: sha512-5IKcdX0nnYavi6G7TtOhwkYzyjfJlatbjMjuLSfE2kYT5pMDOilZ4OvMhi637CcDICTmz3wARPoyhqyX1Y+XvA==}
|
|
|
|
|
engines: {node: ^14.18.0 || >=16.10.0}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
content-type@2.0.0:
|
|
|
|
|
resolution: {integrity: sha512-j/O/d7GcZCyNl7/hwZAb606rzqkyvaDctLmckbxLzHvFBzTJHuGEdodATcP3yIRoDrLHkIATJuvzbFlp/ki2cQ==}
|
|
|
|
|
engines: {node: '>=18'}
|
|
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
convert-source-map@2.0.0:
|
|
|
|
|
resolution: {integrity: sha512-Kvp459HrV2FEJ1CAsi1Ku+MY3kasH19TFykTz2xWmMeq6bk2NU3XXvfJ+Q61m0xktWwt+1HSYf3JZsTms3aRJg==}
|
|
|
|
|
|
|
|
|
|
cookie-es@1.2.3:
|
|
|
|
|
resolution: {integrity: sha512-lXVyvUvrNXblMqzIRrxHb57UUVmqsSWlxqt3XIjCkUP0wDAf6uicO6KMbEgYrMNtEvWgWHwe42CKxPu9MYAnWw==}
|
2025-01-07 09:57:34 -05:00
|
|
|
|
2025-08-11 10:12:46 -04:00
|
|
|
crossws@0.3.5:
|
|
|
|
|
resolution: {integrity: sha512-ojKiDvcmByhwa8YYqbQI/hg7MEU0NC03+pSdEq4ZUnZR9xXpwk7E43SMNGkn+JxJGPFtNvQ48+vV2p+P1ml5PA==}
|
2025-02-14 11:44:43 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
crossws@0.4.10:
|
|
|
|
|
resolution: {integrity: sha512-pz3oubH/dt12KjqsUB0IuXW4nwRDQ583iDsP4555Cpdqx0NoU7pGlWBcayyFI8f/l/idRpgjMEfwuOxSWJYlIA==}
|
2026-05-22 16:57:46 +02:00
|
|
|
peerDependencies:
|
|
|
|
|
srvx: '>=0.11.5'
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
srvx:
|
|
|
|
|
optional: true
|
|
|
|
|
|
Add CSS codemods for migrating `@layer utilities` (#14455)
This PR adds CSS codemods for migrating existing `@layer utilities` to
`@utility` directives.
This PR has the ability to migrate the following cases:
---
The most basic case is when you want to migrate a simple class to a
utility directive.
Input:
```css
@layer utilities {
.foo {
color: red;
}
.bar {
color: blue;
}
}
```
Output:
```css
@utility foo {
color: red;
}
@utility bar {
color: blue;
}
```
You'll notice that the class `foo` will be used as the utility name, the
declarations (and the rest of the body of the rule) will become the body
of the `@utility` definition.
---
In v3, every class in a selector will become a utility. To correctly
migrate this to `@utility` directives, we have to register each class in
the selector and generate `n` utilities.
We can use nesting syntax, and replace the current class with `&` to
ensure that the final result behaves the same.
Input:
```css
@layer utilities {
.foo .bar .baz {
color: red;
}
}
```
Output:
```css
@utility foo {
& .bar .baz {
color: red;
}
}
@utility bar {
.foo & .baz {
color: red;
}
}
@utility .baz {
.foo .bar & {
color: red;
}
}
```
In this case, it could be that you know that some of them will never be
used as a utility (e.g.: `hover:bar`), but then you can safely remove
them.
---
Even classes inside of `:has(…)` will become a utility. The only
exception to the rule is that we don't do it for `:not(…)`.
Input:
```css
@layer utilities {
.foo .bar:not(.qux):has(.baz) {
display: none;
}
}
```
Output:
```css
@utility foo {
& .bar:not(.qux):has(.baz) {
display: none;
}
}
@utility bar {
.foo &:not(.qux):has(.baz) {
display: none;
}
}
@utility baz {
.foo .bar:not(.qux):has(&) {
display: none;
}
}
```
Notice that there is no `@utility qux` because it was used inside of
`:not(…)`.
---
When classes are nested inside at-rules, then these classes will also
become utilities. However, the `@utility <name>` will be at the top and
the at-rules will live inside of it. If there are multiple classes
inside a shared at-rule, then the at-rule will be duplicated for each
class.
Let's look at an example to make it more clear:
Input:
```css
@layer utilities {
@media (min-width: 640px) {
.foo {
color: red;
}
.bar {
color: blue;
}
@media (min-width: 1024px) {
.baz {
color: green;
}
@media (min-width: 1280px) {
.qux {
color: yellow;
}
}
}
}
}
```
Output:
```css
@utility foo {
@media (min-width: 640px) {
color: red;
}
}
@utility bar {
@media (min-width: 640px) {
color: blue;
}
}
@utility baz {
@media (min-width: 640px) {
@media (min-width: 1024px) {
color: green;
}
}
}
@utility qux {
@media (min-width: 640px) {
@media (min-width: 1024px) {
@media (min-width: 1280px) {
color: yellow;
}
}
}
}
```
---
When classes result in multiple `@utility` directives with the same
name, then the definitions will be merged together.
Input:
```css
@layer utilities {
.no-scrollbar::-webkit-scrollbar {
display: none;
}
.no-scrollbar {
-ms-overflow-style: none;
scrollbar-width: none;
}
}
```
Intermediate representation:
```css
@utility no-scrollbar {
&::-webkit-scrollbar {
display: none;
}
}
@utility no-scrollbar {
-ms-overflow-style: none;
scrollbar-width: none;
}
```
Output:
```css
@utility no-scrollbar {
&::-webkit-scrollbar {
display: none;
}
-ms-overflow-style: none;
scrollbar-width: none
}
```
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-09-24 18:17:09 +02:00
|
|
|
cssesc@3.0.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-/Tb/JcjK111nNScGob5MNtsntNM1aCNUDipB/TkwZFhyDrrE47SOx/18wF2bbjgc3ZzCSKW1T5nt5EbFoAz/Vg==}
|
|
|
|
|
engines: {node: '>=4'}
|
Add CSS codemods for migrating `@layer utilities` (#14455)
This PR adds CSS codemods for migrating existing `@layer utilities` to
`@utility` directives.
This PR has the ability to migrate the following cases:
---
The most basic case is when you want to migrate a simple class to a
utility directive.
Input:
```css
@layer utilities {
.foo {
color: red;
}
.bar {
color: blue;
}
}
```
Output:
```css
@utility foo {
color: red;
}
@utility bar {
color: blue;
}
```
You'll notice that the class `foo` will be used as the utility name, the
declarations (and the rest of the body of the rule) will become the body
of the `@utility` definition.
---
In v3, every class in a selector will become a utility. To correctly
migrate this to `@utility` directives, we have to register each class in
the selector and generate `n` utilities.
We can use nesting syntax, and replace the current class with `&` to
ensure that the final result behaves the same.
Input:
```css
@layer utilities {
.foo .bar .baz {
color: red;
}
}
```
Output:
```css
@utility foo {
& .bar .baz {
color: red;
}
}
@utility bar {
.foo & .baz {
color: red;
}
}
@utility .baz {
.foo .bar & {
color: red;
}
}
```
In this case, it could be that you know that some of them will never be
used as a utility (e.g.: `hover:bar`), but then you can safely remove
them.
---
Even classes inside of `:has(…)` will become a utility. The only
exception to the rule is that we don't do it for `:not(…)`.
Input:
```css
@layer utilities {
.foo .bar:not(.qux):has(.baz) {
display: none;
}
}
```
Output:
```css
@utility foo {
& .bar:not(.qux):has(.baz) {
display: none;
}
}
@utility bar {
.foo &:not(.qux):has(.baz) {
display: none;
}
}
@utility baz {
.foo .bar:not(.qux):has(&) {
display: none;
}
}
```
Notice that there is no `@utility qux` because it was used inside of
`:not(…)`.
---
When classes are nested inside at-rules, then these classes will also
become utilities. However, the `@utility <name>` will be at the top and
the at-rules will live inside of it. If there are multiple classes
inside a shared at-rule, then the at-rule will be duplicated for each
class.
Let's look at an example to make it more clear:
Input:
```css
@layer utilities {
@media (min-width: 640px) {
.foo {
color: red;
}
.bar {
color: blue;
}
@media (min-width: 1024px) {
.baz {
color: green;
}
@media (min-width: 1280px) {
.qux {
color: yellow;
}
}
}
}
}
```
Output:
```css
@utility foo {
@media (min-width: 640px) {
color: red;
}
}
@utility bar {
@media (min-width: 640px) {
color: blue;
}
}
@utility baz {
@media (min-width: 640px) {
@media (min-width: 1024px) {
color: green;
}
}
}
@utility qux {
@media (min-width: 640px) {
@media (min-width: 1024px) {
@media (min-width: 1280px) {
color: yellow;
}
}
}
}
```
---
When classes result in multiple `@utility` directives with the same
name, then the definitions will be merged together.
Input:
```css
@layer utilities {
.no-scrollbar::-webkit-scrollbar {
display: none;
}
.no-scrollbar {
-ms-overflow-style: none;
scrollbar-width: none;
}
}
```
Intermediate representation:
```css
@utility no-scrollbar {
&::-webkit-scrollbar {
display: none;
}
}
@utility no-scrollbar {
-ms-overflow-style: none;
scrollbar-width: none;
}
```
Output:
```css
@utility no-scrollbar {
&::-webkit-scrollbar {
display: none;
}
-ms-overflow-style: none;
scrollbar-width: none
}
```
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-09-24 18:17:09 +02:00
|
|
|
hasBin: true
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
csstype@3.2.3:
|
|
|
|
|
resolution: {integrity: sha512-z1HGKcYy2xA8AGQfwrn0PAy+PB7X/GSj3UVJW9qKyn43xWa+gl5nXmU4qqLMRzWVLFC8KusUX8T/0kCiOYpAIQ==}
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
debug@4.4.3:
|
|
|
|
|
resolution: {integrity: sha512-RGwwWnwQvkVfavKVt22FGLw+xYSdzARwm0ru6DhTVA3umU5hZc28V3kO4stgYryrTlLpuvgI9GiijltAjNbcqA==}
|
|
|
|
|
engines: {node: '>=6.0'}
|
|
|
|
|
peerDependencies:
|
|
|
|
|
supports-color: '*'
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
supports-color:
|
|
|
|
|
optional: true
|
|
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
dedent@1.7.2:
|
|
|
|
|
resolution: {integrity: sha512-WzMx3mW98SN+zn3hgemf4OzdmyNhhhKz5Ay0pUfQiMQ3e1g+xmTJWp/pKdwKVXhdSkAEGIIzqeuWrL3mV/AXbA==}
|
|
|
|
|
peerDependencies:
|
|
|
|
|
babel-plugin-macros: ^3.1.0
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
babel-plugin-macros:
|
|
|
|
|
optional: true
|
|
|
|
|
|
|
|
|
|
defu@6.1.7:
|
|
|
|
|
resolution: {integrity: sha512-7z22QmUWiQ/2d0KkdYmANbRUVABpZ9SNYyH5vx6PZ+nE5bcC0l7uFvEfHlyld/HcGBFTL536ClDt3DEcSlEJAQ==}
|
2025-01-07 09:57:34 -05:00
|
|
|
|
2025-05-05 10:30:10 +00:00
|
|
|
destr@2.0.5:
|
|
|
|
|
resolution: {integrity: sha512-ugFTXCtDZunbzasqBxrK93Ik/DRYsO6S/fedkWEMKqt04xZ4csmnmwGDBAb07QWNaGMAmnTIemsYZCksjATwsA==}
|
2025-01-07 09:57:34 -05:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
detect-libc@1.0.3:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-pGjwhsmsp4kL2RTz08wcOlGN83otlqHeD/Z5T8GXZB+/YcpQ/dgo+lbU8ZsGxV0HIvqqxo9l7mqYwyYMD9bKDg==}
|
|
|
|
|
engines: {node: '>=0.10'}
|
2024-05-24 15:07:44 +02:00
|
|
|
hasBin: true
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
detect-libc@2.1.2:
|
|
|
|
|
resolution: {integrity: sha512-Btj2BOOO83o3WyH59e8MgXsxEQVcarkUOpEYrubB0urwnN10yQ364rsiByU11nZlqWYZm05i/of7io4mzihBtQ==}
|
|
|
|
|
engines: {node: '>=8'}
|
|
|
|
|
|
2024-10-24 11:00:25 -04:00
|
|
|
didyoumean@1.2.2:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-gxtyfqMg7GKyhQmb056K7M3xszy/myH8w+B4RT+QXBQsvAOdc3XymqDDPHx1BgPgsdAA5SIifona89YtRATDzw==}
|
2024-10-24 11:00:25 -04:00
|
|
|
|
|
|
|
|
dlv@1.1.3:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-+HlytyjlPKnIG8XuRG8WvmBP8xs8P71y+SKKS6ZXWoEgLuePxtDoUEiH7WkdePWrQ5JBpE6aoVqfZfJUQkjXwA==}
|
2024-10-24 11:00:25 -04:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
electron-to-chromium@1.5.361:
|
|
|
|
|
resolution: {integrity: sha512-Q6Hts7N9FnJc5LeGRINFvLhCI9xZmNtTDe5ZbcVezQz7cU4a8Aua3GH1b8J2XY8Al9PF+OCwYqhgsOOheMdvkA==}
|
2026-04-23 12:51:20 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
emnapi@1.11.3:
|
|
|
|
|
resolution: {integrity: sha512-+/ZS90YK/rYfVOHtGLHkGffVsnmD/MAKaBHio+Y4XAtg75RLr4cveV/w0jTkUdLM1CcAlaRgG76mpIemWAlk0A==}
|
2025-04-11 17:19:55 +02:00
|
|
|
peerDependencies:
|
|
|
|
|
node-addon-api: '>= 6.1.0'
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
node-addon-api:
|
|
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
enhanced-resolve@5.24.5:
|
|
|
|
|
resolution: {integrity: sha512-L1l8TNvomm6UVW5B253AGxQagSQr+vGwhMlrrfRS2qmhx46AMpMVJKQYLvWYbysTMY8VoicOvzHzoHMbyzB+4A==}
|
2026-05-22 16:57:46 +02:00
|
|
|
engines: {node: '>=10.13.0'}
|
|
|
|
|
|
|
|
|
|
es-errors@1.3.0:
|
|
|
|
|
resolution: {integrity: sha512-Zf5H2Kxt2xjTvbJvP2ZWLEICxA6j+hAmMzIlypy4xcBg1vKVnx89Wy0GbS+kf5cwCVFFzdCFh2XSCFNULS6csw==}
|
|
|
|
|
engines: {node: '>= 0.4'}
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
es-module-lexer@2.1.0:
|
|
|
|
|
resolution: {integrity: sha512-n27zTYMjYu1aj4MjCWzSP7G9r75utsaoc8m61weK+W8JMBGGQybd43GstCXZ3WNmSFtGT9wi59qQTW6mhTR5LQ==}
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
es-toolkit@1.50.0:
|
|
|
|
|
resolution: {integrity: sha512-OyZKhUVvEep9ITEiwHn8GKnMRQIVqoSIX7WnRbkWgJkllCujilqP2rD0u979tkl8wqyc8ICwlc1UBVv/Sl1G6w==}
|
2025-09-19 17:08:41 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
esbuild@0.27.7:
|
|
|
|
|
resolution: {integrity: sha512-IxpibTjyVnmrIQo5aqNpCgoACA/dTKLTlhMHihVHhdkxKyPO1uBBthumT0rdHmcsk9uMonIWS0m4FljWzILh3w==}
|
2025-11-19 18:18:45 -05:00
|
|
|
engines: {node: '>=18'}
|
|
|
|
|
hasBin: true
|
|
|
|
|
|
2024-10-24 11:00:25 -04:00
|
|
|
escalade@3.2.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-WUj2qlxaQtO4g6Pq5c29GTcWGDyd8itL8zTlipgECz3JesAiiOKotd8JU6otB3PACgG6xkJUyVhboMS+bje/jA==}
|
|
|
|
|
engines: {node: '>=6'}
|
2024-10-24 11:00:25 -04:00
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
eslint-scope@5.1.1:
|
|
|
|
|
resolution: {integrity: sha512-2NxwbF/hZ0KpepYN0cNbo+FN6XoK7GaHlQhgx/hIZl6Va0bF45RQOOwhLIy8lQDbuCiadSLCBnH2CFYquit5bw==}
|
|
|
|
|
engines: {node: '>=8.0.0'}
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
esrecurse@4.3.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-KmfKL3b6G+RXvP8N1vr3Tq1kL/oCFgn2NYXEtqP8/L3pKapUA4G8cFVaoF3SU323CD4XypR/ffioHmkti6/Tag==}
|
|
|
|
|
engines: {node: '>=4.0'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
estraverse@4.3.0:
|
|
|
|
|
resolution: {integrity: sha512-39nnKffWz8xN1BU/2c79n9nB9HDzo0niYUqx6xyqUnyoAnQyyWpOTdZEeiCch8BBu515t4wp9ZmgVfVhn9EBpw==}
|
|
|
|
|
engines: {node: '>=4.0'}
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
estraverse@5.3.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-MMdARuVEQziNTeJD8DgMqmhwR11BRQ/cBP+pLtYdSTnf3MIO8fFeiINEbX36ZdNlfU/7A9f3gUw49B3oQsvwBA==}
|
|
|
|
|
engines: {node: '>=4.0'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
|
|
|
|
estree-walker@3.0.3:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-7RUKfXgSMMkzt6ZuXmqapOurLGPPfgj6l9uRZ7lRGolvk0y2yocc35LdcxKC5PQZdn2DMqioAQ2NoWcrTKmm6g==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
events@3.3.0:
|
|
|
|
|
resolution: {integrity: sha512-mQw+2fkQbALzQ7V0MY0IqdnXNOeTtP4r0lN9z7AAawCXgqea7bDii20AYrIBrFd/Hx0M2Ocz6S111CaFkUcb0Q==}
|
|
|
|
|
engines: {node: '>=0.8.x'}
|
|
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
expect-type@1.3.0:
|
|
|
|
|
resolution: {integrity: sha512-knvyeauYhqjOYvQ66MznSMs83wmHrCycNEN6Ao+2AeYEfxUIkuiVxdEa1qlGEPK+We3n0THiDciYSsCcgW/DoA==}
|
2025-11-21 00:16:20 +01:00
|
|
|
engines: {node: '>=12.0.0'}
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
fast-content-type-parse@3.0.0:
|
|
|
|
|
resolution: {integrity: sha512-ZvLdcY8P+N8mGQJahJV5G4U88CSvT1rP8ApL6uETe88MBXrBHAkZlSEySdUlyztF7ccb+Znos3TFqaepHxdhBg==}
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
fast-deep-equal@3.1.3:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-f3qQ9oQy9j2AhBe/H9VC91wLmKBCCU/gDOnKNAYG5hswO7BLKj09Hc5HYNz9cGI++xlpDCIgDaitVs03ATR84Q==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2025-12-26 12:36:51 -05:00
|
|
|
fast-equals@5.4.0:
|
|
|
|
|
resolution: {integrity: sha512-jt2DW/aNFNwke7AUd+Z+e6pz39KO5rzdbbFCg2sGafS4mk13MI7Z8O5z9cADNn5lhGODIgLwug6TZO2ctf7kcw==}
|
|
|
|
|
engines: {node: '>=6.0.0'}
|
|
|
|
|
|
2025-01-13 11:11:35 +01:00
|
|
|
fast-glob@3.3.3:
|
|
|
|
|
resolution: {integrity: sha512-7MptL8U0cqcFdzIzwOTHoilX9x5BrNqye7Z/LuC7kCMRio1EMSyqRK3BEAUD7sXRq4iT4AzTVuZdhgQ2TCvYLg==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=8.6.0'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-04-26 17:49:06 +02:00
|
|
|
fast-string-truncated-width@3.0.3:
|
|
|
|
|
resolution: {integrity: sha512-0jjjIEL6+0jag3l2XWWizO64/aZVtpiGE3t0Zgqxv0DPuxiMjvB3M24fCyhZUO4KomJQPj3LTSUnDP3GpdwC0g==}
|
|
|
|
|
|
|
|
|
|
fast-string-width@3.0.2:
|
|
|
|
|
resolution: {integrity: sha512-gX8LrtNEI5hq8DVUfRQMbr5lpaS4nMIWV+7XEbXk2b8kiQIizgnlr12B4dA3ZEx3308ze0O4Q1R+cHts8kyUJg==}
|
|
|
|
|
|
2025-12-26 12:36:51 -05:00
|
|
|
fast-stringify@4.0.0:
|
|
|
|
|
resolution: {integrity: sha512-lE2DIivBaLysf6hK5WH/VfMgqRbvBVHcpGVVTmA5Zi8oWIjq9YxIt6lYGdUgP1HNSXxTIat7HEIDnrSvXSeKQw==}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
fast-uri@3.1.2:
|
|
|
|
|
resolution: {integrity: sha512-rVjf7ArG3LTk+FS6Yw81V1DLuZl1bRbNrev6Tmd/9RaroeeRRJhAt7jg/6YFxbvAQXUCavSoZhPPj6oOx+5KjQ==}
|
2026-04-26 17:49:06 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
fast-wrap-ansi@0.2.2:
|
|
|
|
|
resolution: {integrity: sha512-7F2Fl+TjRSenLqlU3UjSH0iyqopqoZIu7eZVpEirP2g1GtWa2G/ecEmBdgz31+Mxr+ELclgg6sokpSFIQiZ02Q==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
fastq@1.20.1:
|
|
|
|
|
resolution: {integrity: sha512-GGToxJ/w1x32s/D2EKND7kTil4n8OVk/9mycTc4VDza13lOvpUZTGX3mFSCtV9ksdGBVzvsyAVLM6mHFThxXxw==}
|
2025-06-24 18:31:17 +02:00
|
|
|
|
2025-11-21 00:16:20 +01:00
|
|
|
fdir@6.5.0:
|
|
|
|
|
resolution: {integrity: sha512-tIbYtZbucOs0BRGqPJkshJUYdL+SDH7dVM8gjy+ERp3WAUjLEFJE+02kanyHtwjWOnwrKYBiwAmM0p4kLJAnXg==}
|
|
|
|
|
engines: {node: '>=12.0.0'}
|
|
|
|
|
peerDependencies:
|
|
|
|
|
picomatch: ^3 || ^4
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
picomatch:
|
|
|
|
|
optional: true
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
fill-range@7.1.1:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-YsGpe3WHLK8ZYi4tWDg2Jy3ebRz2rXowDxnld4bkQB00cc/1Zw9AWnC0i9ztDJitivtQvaI9KaLyKrc+hBW0yg==}
|
|
|
|
|
engines: {node: '>=8'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
find-up-simple@1.0.1:
|
|
|
|
|
resolution: {integrity: sha512-afd4O7zpqHeRyg4PfDQsXmlDe2PfdHtJt6Akt8jOWaApLOZk5JXs6VMR29lz03pRe9mpykrRCYIYxaJYcfpncQ==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=18'}
|
Add integration test setup and tests for the Vite integration (#14089)
This PR adds a new root `/integrations` folder that will be the home of
integration tests. The idea of these tests is to use Tailwind in various
setups just like our users would (by only using the publishable npm
builds).
To avoid issues with concurrent tests making changes to the file system,
to make it very easy to test through a range of versions, and to avoid
changing configuration objects over and over in test runs, we decided to
inline the scaffolding completely into the test file and have no
examples checked into the repo.
Here's an example of how this can look like for a simple Vite test:
```ts
test('works with production builds', {
fs: {
'package.json': json`
{
"type": "module",
"dependencies": {
"@tailwindcss/vite": "workspace:^",
"tailwindcss": "workspace:^"
},
"devDependencies": {
"vite": "^5.3.5"
}
}
`,
'vite.config.ts': ts`
import tailwindcss from '@tailwindcss/vite'
import { defineConfig } from 'vite'
export default defineConfig({
build: { cssMinify: false },
plugins: [tailwindcss()],
})
`,
'index.html': html`
<head>
<link rel="stylesheet" href="./src/index.css">
</head>
<body>
<div class="underline m-2">Hello, world!</div>
</body>
`,
'src/index.css': css`
@import 'tailwindcss/theme' reference;
@import 'tailwindcss/utilities';
`,
},
},
async ({ fs, exec }) => {
await exec('pnpm vite build')
expect.assertions(2)
for (let [path, content] of await fs.glob('dist/**/*.css')) {
expect(path).toMatch(/\.css$/)
expect(stripTailwindComment(content)).toMatchInlineSnapshot(
`
".m-2 {
margin: var(--spacing-2, .5rem);
}
.underline {
text-decoration-line: underline;
}"
`,
)
}
},
)
```
By defining all dependencies this way, we never have to worry about
which fixtures are checked in and can more easily describe changes to
the setup.
For ergonomics, we've also added the [`embed` prettier
plugin](https://github.com/Sec-ant/prettier-plugin-embed). This will
mean that files inlined in the `fs` setup are properly indented. No
extra work needed!
If you're using VS Code, I can also recommend the [Language
Literals](https://marketplace.visualstudio.com/items?itemName=sissel.language-literals)
extension so that syntax highlighting also _just works_.
A neat feature of inlining the scaffolding like this is to make it very
simple to test through a variety of versions. For example, here's how we
can set up a test against Vite 5 and Vite 4:
```js
;['^4.5.3', '^5.3.5'].forEach(viteVersion => {
test(`works with production builds for Vite ${viteVersion}`, {
fs: {
'package.json': json`
{
"type": "module",
"devDependencies": {
"vite": "${viteVersion}"
}
}
`,
async () => {
// Do something
},
)
})
```
## Philosophy
Before we dive into the specifics, I want to clearly state the design
considerations we have chosen for this new test suite:
- All file mutations should be done in temp folders, nothing should ever
mess with your working directory
- Windows as a first-class citizen
- Have a clean and simple API that describes the test setup only using
public APIs
- Focus on reliability (make sure cleanup scripts work and are tolerant
to various error scenarios)
- If a user reports an issue with a specific configuration, we want to
be able to reproduce them with integration tests, no matter how obscure
the setup (this means the test need to be in control of most of the
variables)
- Tests should be reasonably fast (obviously this depends on the
integration. If we use a slow build tool, we can't magically speed it
up, but our overhead should be minimal).
## How it works
The current implementation provides a custom `test` helper function
that, when used, sets up the environment according to the configuration.
It'll create a new temporary directory and create all files, ensuring
things like proper `\r\n` line endings on Windows.
We do have to patch the `package.json` specifically, since we can not
use public versions of the tailwindcss packages as we want to be able to
test against a development build. To make this happen, every `pnpm
build` run now creates tarballs of the npm modules (that contain only
the files that would also in the published build). We then patch the
`package.json` to rewrite `workspace:^` versions to link to those
tarballs. We found this to work reliably on Windows and macOS as well as
being fast enough to not cause any issues. Furthermore we also decided
to use `pnpm` as the version manager for integration tests because of
it's global module cache (so installing `vite` is fast as soon as you
installed it once).
The test function will receive a few utilities that it can use to more
easily interact with the temp dir. One example is a `fs.glob` function
that you can use to easily find files in eventual `dist/` directories or
helpers around `spawn` and `exec` that make sure that processes are
cleaned up correctly.
Because we use tarballs from our build dependencies, working on changes
requires a workflow where you run `pnpm build` before running `pnpm
test:integrations`. However it also means we can run clients like our
CLI client with no additional overhead—just install the dependency like
any user would and set up your test cases this way.
## Test plan
This PR also includes two Vite specific integration tests: One testing a
static build (`pnpm vite build`) and one a dev mode build (`pnpm vite
dev`) that also makes changes to the file system and asserts that the
resources properly update.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-08-02 11:50:49 +02:00
|
|
|
|
2025-05-29 13:38:00 -04:00
|
|
|
fix-dts-default-cjs-exports@1.0.1:
|
|
|
|
|
resolution: {integrity: sha512-pVIECanWFC61Hzl2+oOCtoJ3F17kglZC/6N94eRWycFgBH35hHx0Li604ZIzhseh97mf2p0cv7vVrOZGoqhlEg==}
|
|
|
|
|
|
2025-11-17 17:22:37 -05:00
|
|
|
fraction.js@5.3.4:
|
|
|
|
|
resolution: {integrity: sha512-1X1NTtiJphryn/uLQz3whtY6jK3fTqoE3ohKs0tT+Ujr1W59oopxmoEh7Lu5p6vBaPbgoM0bzveAW4Qi5RyWDQ==}
|
2024-10-24 11:00:25 -04:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
fsevents@2.3.2:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-xiqMQR4xAeHTuB9uWm+fFRcIOgKBMiOBP+eXiyT7jsgVCq1bkVygt00oASowB7EdtpOHaaPgKt812P9ab+DDKA==}
|
|
|
|
|
engines: {node: ^8.16.0 || ^10.6.0 || >=11.0.0}
|
2024-05-24 15:07:44 +02:00
|
|
|
os: [darwin]
|
|
|
|
|
|
|
|
|
|
fsevents@2.3.3:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-5xoDfX+fL7faATnagmWPpbFtwh/R77WmMMqqHGS65C3vvB0YHrgF+B1YmZ3441tMj5n63k0212XNoJwzlhffQw==}
|
|
|
|
|
engines: {node: ^8.16.0 || ^10.6.0 || >=11.0.0}
|
2024-05-24 15:07:44 +02:00
|
|
|
os: [darwin]
|
|
|
|
|
|
|
|
|
|
function-bind@1.1.2:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-7XHNxH7qX9xG5mIwxkhumTox/MIRNcOgDrxWsMt2pAr23WHp6MrRlN7FBSFpCpr+oVO0F744iUgR82nJMfG2SA==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
get-port-please@3.2.0:
|
|
|
|
|
resolution: {integrity: sha512-I9QVvBw5U/hw3RmWpYKRumUeaDgxTPd401x364rLmWBJcOQ753eov1eTgzDqRG9bqFIfDc7gfzcQEWrUri3o1A==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
|
|
|
|
glob-parent@5.1.2:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-AOIgSQCepiJYwP3ARnGx+5VnTu2HBYdzbGP45eLw1vr3zB3vZLeyed1sC9hnbcOc9/SrMyM5RPQrkGz4aS9Zow==}
|
|
|
|
|
engines: {node: '>= 6'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
|
|
|
|
glob-parent@6.0.2:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-XxwI8EOhVQgWp6iDL+3b0r86f4d6AX6zSU55HfB4ydCEuXLXc5FcYeOu+nnGftS4TEju/11rt4KJPTMgbfmv4A==}
|
|
|
|
|
engines: {node: '>=10.13.0'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
globby@16.2.2:
|
|
|
|
|
resolution: {integrity: sha512-NLvV9ubZ6NDsJaOpKPy3cQeJpKi9DcWiyCiFUpJPA0YihRqiE6RWaLUmgNNPr8MgPpLZjnBjSmou7uZBRJv9wA==}
|
2025-10-06 11:14:31 +02:00
|
|
|
engines: {node: '>=20'}
|
2024-09-18 16:45:43 +02:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
graceful-fs@4.2.11:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-RbJ5/jmFcNNCcDV5o9eTnBLJ/HszWV0P73bc+Ff4nS/rJj+YaS6IGyiOL0VoBYX+l1Wrl3k63h/KrH+nhJ0XvQ==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
h3@1.15.11:
|
|
|
|
|
resolution: {integrity: sha512-L3THSe2MPeBwgIZVSH5zLdBBU90TOxarvhK9d04IDY2AmVS8j2Jz2LIWtwsGOU3lu2I5jCN7FNvVfY2+XyF+mg==}
|
2025-01-07 09:57:34 -05:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
has-flag@4.0.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-EykJT/Q1KjTWctppgIAgfSO0tKVuZUjhgMr17kqTumMl6Afv3EISleU7qZUzoXDFTAHTDC4NOoG/ZxU3EvlMPQ==}
|
|
|
|
|
engines: {node: '>=8'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
hasown@2.0.3:
|
|
|
|
|
resolution: {integrity: sha512-ej4AhfhfL2Q2zpMmLo7U1Uv9+PyhIZpgQLGT1F9miIGmiCJIoCgSmczFdrc97mWT4kVY72KA+WnnhJ5pghSvSg==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>= 0.4'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2025-01-07 09:57:34 -05:00
|
|
|
http-shutdown@1.2.2:
|
|
|
|
|
resolution: {integrity: sha512-S9wWkJ/VSY9/k4qcjG318bqJNruzE4HySUhFYknwmu6LBP97KLLfwNf+n4V1BHurvFNkSKLFnK/RsuUnRTf9Vw==}
|
|
|
|
|
engines: {iojs: '>= 1.0.0', node: '>= 0.12.0'}
|
|
|
|
|
|
2026-04-26 17:49:06 +02:00
|
|
|
iconv-lite@0.7.2:
|
|
|
|
|
resolution: {integrity: sha512-im9DjEDQ55s9fL4EYzOAv0yMqmMBSZp6G0VvFyTMPKWxiSBHUj9NW/qqLmXUwXrrM7AvqSlTCfvqRb0cM8yYqw==}
|
2025-04-11 17:19:55 +02:00
|
|
|
engines: {node: '>=0.10.0'}
|
|
|
|
|
|
2025-10-06 11:14:31 +02:00
|
|
|
ignore@7.0.5:
|
|
|
|
|
resolution: {integrity: sha512-Hs59xBNfUIunMFgWAbGX5cq6893IbWg4KnrjbYwX3tx0ztorVgTDA6B2sxf8ejHJ4wz8BqGUMYlnzNBer5NvGg==}
|
2025-02-17 12:06:53 +01:00
|
|
|
engines: {node: '>= 4'}
|
|
|
|
|
|
2025-01-07 09:57:34 -05:00
|
|
|
iron-webcrypto@1.2.1:
|
|
|
|
|
resolution: {integrity: sha512-feOM6FaSr6rEABp/eDfVseKyTMDt+KGpeB35SkVn9Tyn0CqvVsY3EwI0v5i8nMHyJnzCIQf7nsy3p41TPkJZhg==}
|
|
|
|
|
|
2026-04-03 21:07:27 +02:00
|
|
|
is-binary-path@2.1.0:
|
|
|
|
|
resolution: {integrity: sha512-ZMERYes6pDydyuGidse7OsHxtbI7WVeUEozgR/g7rd0xUimYNlvZRE/K2MgZTjWy725IfelLeVcEM97mmtRGXw==}
|
|
|
|
|
engines: {node: '>=8'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
is-core-module@2.16.2:
|
|
|
|
|
resolution: {integrity: sha512-evOr8xfXKxE6qSR0hSXL2r3sd7ALj8+7jQEUvPYcm5sgZFdJ+AYzT6yNmJenvIYQBgIGwfwz08sL8zoL7yq2BA==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>= 0.4'}
|
2024-10-24 11:00:25 -04:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
is-extglob@2.1.1:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-SbKbANkN603Vi4jEZv49LeVJMn4yGwsbzZworEoyEiutsN3nJYdbO36zfhGJ6QEDpOZIFkDtnq5JRxmvl3jsoQ==}
|
|
|
|
|
engines: {node: '>=0.10.0'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
|
|
|
|
is-glob@4.0.3:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-xelSayHH36ZgE7ZWhli7pW34hNbNl8Ojv5KVmkJD4hBdD3th8Tfk9vYasLM+mXWOZhFkgZfxhLSnrwRr4elSSg==}
|
|
|
|
|
engines: {node: '>=0.10.0'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
|
|
|
|
is-number@7.0.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-41Cifkg6e8TylSpdtTpeLVMqvSBEVzTttHvERD741+pnZ8ANv0004MRL43QKPDlK9cGvNp6NZWZUBlbGXYxxng==}
|
|
|
|
|
engines: {node: '>=0.12.0'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
is-path-inside@4.0.0:
|
|
|
|
|
resolution: {integrity: sha512-lJJV/5dYS+RcL8uQdBDW9c9uWFLLBNRyFhnAKXw5tVqLlKZ4RMGZKv+YQ/IA3OhD+RpbJa1LLFM1FQPGyIXvOA==}
|
|
|
|
|
engines: {node: '>=12'}
|
2025-01-07 09:57:34 -05:00
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
jest-worker@27.5.1:
|
|
|
|
|
resolution: {integrity: sha512-7vuh85V5cdDofPyxn58nrPjBktZo0u9x1g8WtjQol+jZDaE+fhN+cIvTj11GndBnMnyfrUOG1sZQxCdjKh+DKg==}
|
|
|
|
|
engines: {node: '>= 10.13.0'}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
jiti@1.21.7:
|
|
|
|
|
resolution: {integrity: sha512-/imKNG4EbWNrVjoNC/1H5/9GFy+tqjGBHCaSsN+P2RnPqjsLmv6UD3Ej+Kj8nBWaRAwyk7kK5ZUc+OEatnTR3A==}
|
2024-10-24 11:00:25 -04:00
|
|
|
hasBin: true
|
|
|
|
|
|
2026-05-13 12:02:13 +02:00
|
|
|
jiti@2.7.0:
|
|
|
|
|
resolution: {integrity: sha512-AC/7JofJvZGrrneWNaEnJeOLUx+JlGt7tNa0wZiRPT4MY1wmfKjt2+6O2p2uz2+skll8OZZmJMNqeke7kKbNgQ==}
|
2025-07-31 11:48:58 -04:00
|
|
|
hasBin: true
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
joycon@3.1.1:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-34wB/Y7MW7bzjKRjUKTa46I2Z7eV62Rkhva+KkopW7Qvv/OSWBqvkSY7vusOPrNuZcUG3tApvdVgNB8POj3SPw==}
|
|
|
|
|
engines: {node: '>=10'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
js-yaml@4.3.1:
|
|
|
|
|
resolution: {integrity: sha512-CY6crGq313MX8GkwvB7tzgp99vjQxY1++5y10/BKN/GUfHqWaOGQMNZkBvqSzsZKWk/ijwHlWzzkLulsGHhjWQ==}
|
2024-05-24 15:07:44 +02:00
|
|
|
hasBin: true
|
|
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
json-schema-traverse@1.0.0:
|
|
|
|
|
resolution: {integrity: sha512-NM8/P9n3XjXhIZn1lLhkFaACTOURQXjWhV4BA/RnOv8xvgqtqpAX9IO4mRQxSx1Rlo4tqzeqb0sOlruaOy3dug==}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
json-with-bigint@3.5.8:
|
|
|
|
|
resolution: {integrity: sha512-eq/4KP6K34kwa7TcFdtvnftvHCD9KvHOGGICWwMFc4dOOKF5t4iYqnfLK8otCRCRv06FXOzGGyqE8h8ElMvvdw==}
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss-android-arm64@1.33.0:
|
|
|
|
|
resolution: {integrity: sha512-gEpRTalKdosp4Bb8qWtc2iOgE5SeIHlpS1up9bFq2wAyYhl1UdTObYiHe98zEM9SQvSoqQZ1IQD0JNpg3Ml5pg==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: '>= 12.0.0'}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [android]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss-darwin-arm64@1.33.0:
|
|
|
|
|
resolution: {integrity: sha512-Sciaz8eenNTKn9b3t7+xr0ipTp9YxKQY4npwQ3mrRuL0BAVHBLyZxofhaKBAVtzmtRZ/zTyo0/to4B1uWG/Djg==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: '>= 12.0.0'}
|
2026-06-19 13:11:16 +02:00
|
|
|
cpu: [arm64]
|
2025-01-09 17:14:48 +01:00
|
|
|
os: [darwin]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss-darwin-x64@1.33.0:
|
|
|
|
|
resolution: {integrity: sha512-Z5UPAxzrjlWNNyGy6i65cJzzvgJ5D3T6wMvs+gWpY9d7qRhANrxqAp6LhxIgZhWEw18RfJTGcRxjuLIBr+m8XQ==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: '>= 12.0.0'}
|
2026-06-19 13:11:16 +02:00
|
|
|
cpu: [x64]
|
2026-03-12 20:54:34 +01:00
|
|
|
os: [darwin]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss-freebsd-x64@1.33.0:
|
|
|
|
|
resolution: {integrity: sha512-QQM/Ti/hQajJwCY+RiWuCZ9sdtI/XQk7nDK5vC8kkdwixezOlDgvDx7+RT+QjK6FcFT4MpsuoBnHIo/O3StRRg==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: '>= 12.0.0'}
|
|
|
|
|
cpu: [x64]
|
|
|
|
|
os: [freebsd]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss-linux-arm-gnueabihf@1.33.0:
|
|
|
|
|
resolution: {integrity: sha512-N7FVBe6iS24MlM6R/4RBTxGhQheZGs7tiQ9U32UtF75NzP5Q7xWPRqLBCKxlRQRk3rY1jCIPLzx7WzOhuUIRLQ==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: '>= 12.0.0'}
|
|
|
|
|
cpu: [arm]
|
|
|
|
|
os: [linux]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss-linux-arm64-gnu@1.33.0:
|
|
|
|
|
resolution: {integrity: sha512-j2v/itmy4HlNxlc6voKXYgBqNi0Ng2LShg4z7GufpEgs05P+2suBVyi9I6YHq5uoVFx9ETin3eCEhLVyXGQnKg==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: '>= 12.0.0'}
|
2026-06-19 13:11:16 +02:00
|
|
|
cpu: [arm64]
|
2025-01-09 17:14:48 +01:00
|
|
|
os: [linux]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss-linux-arm64-musl@1.33.0:
|
|
|
|
|
resolution: {integrity: sha512-yiO5ROMuYQgXbC60yjZU5CYSFZGKXL0HFATXt9mHJn1+zW55oCtMI9NfcVhYLMFDL7gV7oBPon/EmMMGg2OvtQ==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: '>= 12.0.0'}
|
2026-06-19 13:11:16 +02:00
|
|
|
cpu: [arm64]
|
2025-01-09 17:14:48 +01:00
|
|
|
os: [linux]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss-linux-x64-gnu@1.33.0:
|
|
|
|
|
resolution: {integrity: sha512-ar+Ju7LmcN0Jo4FpL4hpFybwNG9/3A/Br5KW2n2jyODg3MEZXaDYADdemoNS+BDNfMgKvylJLj4S5tyRActuAg==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: '>= 12.0.0'}
|
2026-06-19 13:11:16 +02:00
|
|
|
cpu: [x64]
|
2025-01-09 17:14:48 +01:00
|
|
|
os: [linux]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss-linux-x64-musl@1.33.0:
|
|
|
|
|
resolution: {integrity: sha512-RYiYbkokw0trfKqqzfF55lginwEPrD3OJDfTuJzFs1MK6iFnDenaz1fqLLtX4ITG3OktJQXOeTaw1awrBAlZPw==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: '>= 12.0.0'}
|
2026-06-19 13:11:16 +02:00
|
|
|
cpu: [x64]
|
2026-03-12 20:54:34 +01:00
|
|
|
os: [linux]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss-win32-arm64-msvc@1.33.0:
|
|
|
|
|
resolution: {integrity: sha512-1K+MPfLSFVpphzpdbfkhlWk6wBrTObBzS2T6db10PNOZgR9GoVsAWzwNyuhUYYbTp23j+4RrncfujZ4uAzXvwA==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: '>= 12.0.0'}
|
|
|
|
|
cpu: [arm64]
|
|
|
|
|
os: [win32]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss-win32-x64-msvc@1.33.0:
|
|
|
|
|
resolution: {integrity: sha512-OlEICDx/Xl0FqSp4bry8zFnCvGpig3Gl4gCquvYwHuqJKEC1+n9NgDniFvqHGmMv1ZkqDJrDqKKSykTDX+ehuA==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: '>= 12.0.0'}
|
2026-06-19 13:11:16 +02:00
|
|
|
cpu: [x64]
|
2026-03-12 20:54:34 +01:00
|
|
|
os: [win32]
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss@1.33.0:
|
|
|
|
|
resolution: {integrity: sha512-WkUDrojuJs0xkgGf2udWxa3yGBRxPtxUkB79i6aCZLRgc7PM8fZe9TosfPDcvEpQZbuFASnHYmRLBLUbmLOIIA==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: '>= 12.0.0'}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
lilconfig@3.1.3:
|
|
|
|
|
resolution: {integrity: sha512-/vlFKAoH5Cgt3Ie+JLhRbwOsCQePABiU3tJ1egGvyQ+33R/vcwM2Zl2QR/LzjsBeItPt3oSVXapn+m4nQDvpzw==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=14'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
|
|
|
|
lines-and-columns@1.2.4:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-7ylylesZQ/PV29jhEDl3Ufjo6ZX7gCqJr5F7PKrqc93v7fzSymt1BpwEU8nAUXs8qzzvqhbjhK5QZg6Mt/HkBg==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
listhen@1.10.1:
|
|
|
|
|
resolution: {integrity: sha512-6nt/86SkqUQSLW1ofz8MxC6RhRMqOl3ONISe6qqvJ3xj09aJWQx6DhgSZpugs3PX4PXdOas/WD6A9jx6J2N19A==}
|
2025-01-07 09:57:34 -05:00
|
|
|
hasBin: true
|
2026-08-04 13:55:03 +02:00
|
|
|
peerDependencies:
|
|
|
|
|
'@parcel/watcher': ^2.5.6
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@parcel/watcher':
|
|
|
|
|
optional: true
|
2025-01-07 09:57:34 -05:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
load-tsconfig@0.2.5:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-IXO6OCs9yg8tMKzfPZ1YmheJbZCiEsnBdcB03l0OcfK9prKnJb96siuHCr5Fl37/yo9DnKU+TLpxzTUspw9shg==}
|
|
|
|
|
engines: {node: ^12.20.0 || ^14.13.1 || >=16.0.0}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2025-10-31 07:34:21 -04:00
|
|
|
magic-string@0.30.21:
|
|
|
|
|
resolution: {integrity: sha512-vd2F4YUyEXKGcLHoq+TEyCjxueSeHnFxyyjNp80yg0XV4vUhnDer/lvvlqM/arB5bXQN5K2/3oinyCRyx8T2CQ==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
magic-string@1.1.0:
|
|
|
|
|
resolution: {integrity: sha512-kS3VHe0nEPST2saQV4Rbkchcd3UBRkVTQHo1D3h/ZTwFDhai/mfKkmtPAtD129EOI7K3HlHIsFOt0WrI2/oU9g==}
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
merge-stream@2.0.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-abv/qOcuPfk3URPfDzmZU1LKmuw8kT+0nIHvKrKgFrwifol/doWcdA4ZqsWQ8ENrFKkd67Mfpo/LovbIUsbt3w==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
|
|
|
|
merge2@1.4.1:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-8q7VEgMJW4J8tcfVPy8g09NcQwZdbwFEqhe/WZkoIzjn/3TGDwtOCYtXGxA3O8tPzpczCCDgv+P2P5y00ZJOOg==}
|
|
|
|
|
engines: {node: '>= 8'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2025-12-26 12:36:51 -05:00
|
|
|
micro-memoize@5.1.1:
|
|
|
|
|
resolution: {integrity: sha512-QDwluos8YeMijiKxZGwaV4f4tzj0soS6+xcsJhJ3+4wdEIHMyKbIKVUziebOgWX3e6yiijdoaHo+9tyhbnaWXA==}
|
Add integration test setup and tests for the Vite integration (#14089)
This PR adds a new root `/integrations` folder that will be the home of
integration tests. The idea of these tests is to use Tailwind in various
setups just like our users would (by only using the publishable npm
builds).
To avoid issues with concurrent tests making changes to the file system,
to make it very easy to test through a range of versions, and to avoid
changing configuration objects over and over in test runs, we decided to
inline the scaffolding completely into the test file and have no
examples checked into the repo.
Here's an example of how this can look like for a simple Vite test:
```ts
test('works with production builds', {
fs: {
'package.json': json`
{
"type": "module",
"dependencies": {
"@tailwindcss/vite": "workspace:^",
"tailwindcss": "workspace:^"
},
"devDependencies": {
"vite": "^5.3.5"
}
}
`,
'vite.config.ts': ts`
import tailwindcss from '@tailwindcss/vite'
import { defineConfig } from 'vite'
export default defineConfig({
build: { cssMinify: false },
plugins: [tailwindcss()],
})
`,
'index.html': html`
<head>
<link rel="stylesheet" href="./src/index.css">
</head>
<body>
<div class="underline m-2">Hello, world!</div>
</body>
`,
'src/index.css': css`
@import 'tailwindcss/theme' reference;
@import 'tailwindcss/utilities';
`,
},
},
async ({ fs, exec }) => {
await exec('pnpm vite build')
expect.assertions(2)
for (let [path, content] of await fs.glob('dist/**/*.css')) {
expect(path).toMatch(/\.css$/)
expect(stripTailwindComment(content)).toMatchInlineSnapshot(
`
".m-2 {
margin: var(--spacing-2, .5rem);
}
.underline {
text-decoration-line: underline;
}"
`,
)
}
},
)
```
By defining all dependencies this way, we never have to worry about
which fixtures are checked in and can more easily describe changes to
the setup.
For ergonomics, we've also added the [`embed` prettier
plugin](https://github.com/Sec-ant/prettier-plugin-embed). This will
mean that files inlined in the `fs` setup are properly indented. No
extra work needed!
If you're using VS Code, I can also recommend the [Language
Literals](https://marketplace.visualstudio.com/items?itemName=sissel.language-literals)
extension so that syntax highlighting also _just works_.
A neat feature of inlining the scaffolding like this is to make it very
simple to test through a variety of versions. For example, here's how we
can set up a test against Vite 5 and Vite 4:
```js
;['^4.5.3', '^5.3.5'].forEach(viteVersion => {
test(`works with production builds for Vite ${viteVersion}`, {
fs: {
'package.json': json`
{
"type": "module",
"devDependencies": {
"vite": "${viteVersion}"
}
}
`,
async () => {
// Do something
},
)
})
```
## Philosophy
Before we dive into the specifics, I want to clearly state the design
considerations we have chosen for this new test suite:
- All file mutations should be done in temp folders, nothing should ever
mess with your working directory
- Windows as a first-class citizen
- Have a clean and simple API that describes the test setup only using
public APIs
- Focus on reliability (make sure cleanup scripts work and are tolerant
to various error scenarios)
- If a user reports an issue with a specific configuration, we want to
be able to reproduce them with integration tests, no matter how obscure
the setup (this means the test need to be in control of most of the
variables)
- Tests should be reasonably fast (obviously this depends on the
integration. If we use a slow build tool, we can't magically speed it
up, but our overhead should be minimal).
## How it works
The current implementation provides a custom `test` helper function
that, when used, sets up the environment according to the configuration.
It'll create a new temporary directory and create all files, ensuring
things like proper `\r\n` line endings on Windows.
We do have to patch the `package.json` specifically, since we can not
use public versions of the tailwindcss packages as we want to be able to
test against a development build. To make this happen, every `pnpm
build` run now creates tarballs of the npm modules (that contain only
the files that would also in the published build). We then patch the
`package.json` to rewrite `workspace:^` versions to link to those
tarballs. We found this to work reliably on Windows and macOS as well as
being fast enough to not cause any issues. Furthermore we also decided
to use `pnpm` as the version manager for integration tests because of
it's global module cache (so installing `vite` is fast as soon as you
installed it once).
The test function will receive a few utilities that it can use to more
easily interact with the temp dir. One example is a `fs.glob` function
that you can use to easily find files in eventual `dist/` directories or
helpers around `spawn` and `exec` that make sure that processes are
cleaned up correctly.
Because we use tarballs from our build dependencies, working on changes
requires a workflow where you run `pnpm build` before running `pnpm
test:integrations`. However it also means we can run clients like our
CLI client with no additional overhead—just install the dependency like
any user would and set up your test cases this way.
## Test plan
This PR also includes two Vite specific integration tests: One testing a
static build (`pnpm vite build`) and one a dev mode build (`pnpm vite
dev`) that also makes changes to the file system and asserts that the
resources properly update.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-08-02 11:50:49 +02:00
|
|
|
|
2025-01-13 11:11:35 +01:00
|
|
|
micromatch@4.0.8:
|
|
|
|
|
resolution: {integrity: sha512-PXwfBhYu0hBCPw8Dn0E+WDYb7af3dSLVWKi3HGv84IdF4TyFoC0ysxFd0Goxw7nSv4T/PzEJQxsYsEiFCKo2BA==}
|
|
|
|
|
engines: {node: '>=8.6'}
|
|
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
mime-db@1.54.0:
|
|
|
|
|
resolution: {integrity: sha512-aU5EJuIN2WDemCcAp2vFBfp/m4EAhWJnUNSSw0ixs7/kXbd6Pg64EmwJkNdFhB8aWt1sH2CTXrLxo/iAGV3oPQ==}
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
engines: {node: '>= 0.6'}
|
|
|
|
|
|
2024-11-19 16:19:08 +01:00
|
|
|
mini-svg-data-uri@1.4.4:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-r9deDe9p5FJUPZAk3A59wGH7Ii9YrjjWw0jmw/liSbHl2CHiyXj6FcDXDu2K3TjVAXqiJdaw3xxwlZZr9E6nHg==}
|
2024-11-19 16:19:08 +01:00
|
|
|
hasBin: true
|
|
|
|
|
|
2026-07-02 11:45:49 +02:00
|
|
|
minimizer-webpack-plugin@5.6.1:
|
|
|
|
|
resolution: {integrity: sha512-DoeAZz8Q1C1znwsUzej1fdoi4jCf7/+Em27ouLqfK/+3m8G+D7yDhUwrc3CNhjSzGUN1kn7Iv4sWmjflQHenpw==}
|
|
|
|
|
engines: {node: '>= 10.13.0'}
|
|
|
|
|
peerDependencies:
|
|
|
|
|
'@minify-html/node': '*'
|
|
|
|
|
'@swc/core': '*'
|
|
|
|
|
'@swc/css': '*'
|
|
|
|
|
'@swc/html': '*'
|
|
|
|
|
clean-css: '*'
|
|
|
|
|
cssnano: '*'
|
|
|
|
|
csso: '*'
|
|
|
|
|
esbuild: '*'
|
|
|
|
|
html-minifier-terser: '*'
|
|
|
|
|
lightningcss: '*'
|
|
|
|
|
postcss: '*'
|
|
|
|
|
uglify-js: '*'
|
|
|
|
|
webpack: ^5.1.0
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@minify-html/node':
|
|
|
|
|
optional: true
|
|
|
|
|
'@swc/core':
|
|
|
|
|
optional: true
|
|
|
|
|
'@swc/css':
|
|
|
|
|
optional: true
|
|
|
|
|
'@swc/html':
|
|
|
|
|
optional: true
|
|
|
|
|
clean-css:
|
|
|
|
|
optional: true
|
|
|
|
|
cssnano:
|
|
|
|
|
optional: true
|
|
|
|
|
csso:
|
|
|
|
|
optional: true
|
|
|
|
|
esbuild:
|
|
|
|
|
optional: true
|
|
|
|
|
html-minifier-terser:
|
|
|
|
|
optional: true
|
|
|
|
|
lightningcss:
|
|
|
|
|
optional: true
|
|
|
|
|
postcss:
|
|
|
|
|
optional: true
|
|
|
|
|
uglify-js:
|
|
|
|
|
optional: true
|
|
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
mlly@1.8.2:
|
|
|
|
|
resolution: {integrity: sha512-d+ObxMQFmbt10sretNDytwt85VrbkhhUA/JBGm1MPaWJ65Cl4wOgLaB1NYvJSZ0Ef03MMEU/0xpPMXUIQ29UfA==}
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
mri@1.2.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-tzzskb3bG8LvYGFF/mDTpq3jpI6Q9wc3LEmBaghu+DdCssd1FakN7Bc0hVNmEyGq1bq3RgfkCb3cmQLpNPOroA==}
|
|
|
|
|
engines: {node: '>=4'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
|
|
|
|
ms@2.1.3:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-6FlzubTLZG3J2a/NVCAleEhjzq5oxgHyaCU9yYXvcLsvoVaHJq/s5xXI6/XXP6tz7R9xAOtHnSO/tXtF3WRTlA==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-04-26 17:49:06 +02:00
|
|
|
mute-stream@3.0.0:
|
|
|
|
|
resolution: {integrity: sha512-dkEJPVvun4FryqBmZ5KhDo0K9iDXAwn08tMLDinNdRBNPcYEDiWYysLcc6k3mjTMlbP9KyylvRpd4wFtwrT9rw==}
|
|
|
|
|
engines: {node: ^20.17.0 || >=22.9.0}
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
mz@2.7.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-z81GNO7nnYMEhrGh9LeymoE4+Yr0Wn5McHIZMK5cfQCl+NDX08sCZgUc9/6MHni9IWuFLm1Z3HTCXu2z9fN62Q==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
nanoid@3.3.12:
|
|
|
|
|
resolution: {integrity: sha512-ZB9RH/39qpq5Vu6Y+NmUaFhQR6pp+M2Xt76XBnEwDaGcVAqhlvxrl3B2bKS5D3NH3QR76v3aSrKaF/Kiy7lEtQ==}
|
|
|
|
|
engines: {node: ^10 || ^12 || ^13.7 || ^14 || >=15.0.1}
|
|
|
|
|
hasBin: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
nanoid@3.3.16:
|
|
|
|
|
resolution: {integrity: sha512-bzlKTyNJ7+LdGIIwy8ijFpIqEQIvafahV7eYykJ8Cvh42EdJeODoJ6gUJXpQJvej1BddH8OqTXZNE/KfbWAu8Q==}
|
|
|
|
|
engines: {node: ^10 || ^12 || ^13.7 || ^14 || >=15.0.1}
|
|
|
|
|
hasBin: true
|
|
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
neo-async@2.6.2:
|
|
|
|
|
resolution: {integrity: sha512-Yd3UES5mWCSqR+qNT93S3UoYUkqAZ9lLg8a7g9rimsWmYGK8cVToA4/sF3RrshdyV3sAGMXVUmpMYOw+dLpOuw==}
|
|
|
|
|
|
2026-06-09 12:38:33 +02:00
|
|
|
next@16.2.7:
|
|
|
|
|
resolution: {integrity: sha512-eMJxgjRzBaj3olkP4cBamHDXL79A8FC6u1GcsO1D1Tsx8bw/LLXUJCaoajVxtnhD3A1IJqIT8IcRJjgBIPJq4w==}
|
2025-11-20 10:54:23 -05:00
|
|
|
engines: {node: '>=20.9.0'}
|
2024-05-24 15:07:44 +02:00
|
|
|
hasBin: true
|
|
|
|
|
peerDependencies:
|
2025-12-10 15:41:00 +00:00
|
|
|
'@opentelemetry/api': ^1.1.0
|
2025-07-30 10:32:16 -04:00
|
|
|
'@playwright/test': ^1.51.1
|
2024-11-26 18:31:12 +01:00
|
|
|
babel-plugin-react-compiler: '*'
|
2025-01-06 11:18:39 +01:00
|
|
|
react: ^18.2.0 || 19.0.0-rc-de68d2f4-20241204 || ^19.0.0
|
|
|
|
|
react-dom: ^18.2.0 || 19.0.0-rc-de68d2f4-20241204 || ^19.0.0
|
2024-05-24 15:07:44 +02:00
|
|
|
sass: ^1.3.0
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@opentelemetry/api':
|
|
|
|
|
optional: true
|
2024-11-26 18:31:12 +01:00
|
|
|
'@playwright/test':
|
|
|
|
|
optional: true
|
|
|
|
|
babel-plugin-react-compiler:
|
|
|
|
|
optional: true
|
2024-05-24 15:07:44 +02:00
|
|
|
sass:
|
|
|
|
|
optional: true
|
|
|
|
|
|
2024-08-02 10:33:14 +02:00
|
|
|
node-addon-api@7.1.1:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-5m3bsyrjFWE1xf7nz7YXdN4udnVtXK6/Yfgn5qnahL6bCkf2yKt4k3nuTKAtT4r3IG8JNR2ncsIMdZuAzJjHQQ==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
node-addon-api@8.7.0:
|
|
|
|
|
resolution: {integrity: sha512-9MdFxmkKaOYVTV+XVRG8ArDwwQ77XIgIPyKASB1k3JPq3M8fGQQQE3YpMOrKm6g//Ktx8ivZr8xo1Qmtqub+GA==}
|
2025-01-10 10:26:48 +01:00
|
|
|
engines: {node: ^18 || ^20 || >= 21}
|
|
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
node-forge@1.4.0:
|
|
|
|
|
resolution: {integrity: sha512-LarFH0+6VfriEhqMMcLX2F7SwSXeWwnEAJEsYm5QKWchiVYVvJyV9v7UDvUv+w5HO23ZpQTXDv/GxdDdMyOuoQ==}
|
2025-01-07 09:57:34 -05:00
|
|
|
engines: {node: '>= 6.13.0'}
|
|
|
|
|
|
2025-01-10 10:26:48 +01:00
|
|
|
node-gyp-build@4.8.4:
|
|
|
|
|
resolution: {integrity: sha512-LA4ZjwlnUblHVgq0oBF3Jl/6h/Nvs5fzBLwdEF4nuxnFdsfajde4WfxtJr3CaiH+F6ewcIB/q4jQ4UzPyid+CQ==}
|
|
|
|
|
hasBin: true
|
|
|
|
|
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
node-mock-http@1.0.4:
|
|
|
|
|
resolution: {integrity: sha512-8DY+kFsDkNXy1sJglUfuODx1/opAGJGyrTuFqEoN90oRc2Vk0ZbD4K2qmKXBBEhZQzdKHIVfEJpDU8Ak2NJEvQ==}
|
2025-02-14 11:44:43 +01:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
node-releases@2.0.46:
|
|
|
|
|
resolution: {integrity: sha512-GYVXHE2KnrzAfsAjl4uP++evGFCrAU1jta4ubEjIG7YWt/64Gqv66a30yKwWczVjA6j3bM4nBwH7Pk1JmDHaxQ==}
|
|
|
|
|
engines: {node: '>=18'}
|
2026-04-23 12:51:20 +02:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
normalize-path@3.0.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA==}
|
|
|
|
|
engines: {node: '>=0.10.0'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
|
|
|
|
object-assign@4.1.1:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-rJgTQnkUnH1sFw8yT6VSU3zD3sWmu6sZhIseY8VX+GRu3P6F7Fu+JNDoXfklElbLJSnc3FUQHVe4cU5hj+BcUg==}
|
|
|
|
|
engines: {node: '>=0.10.0'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2024-10-24 11:00:25 -04:00
|
|
|
object-hash@3.0.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-RSn9F68PjH9HqtltsSnqYC1XXoWe9Bju5+213R98cNGttag9q9yAOTzdbsqvIa7aNm5WffBZFpWYr2aWrklWAw==}
|
|
|
|
|
engines: {node: '>= 6'}
|
2024-10-24 11:00:25 -04:00
|
|
|
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
obug@2.1.1:
|
|
|
|
|
resolution: {integrity: sha512-uTqF9MuPraAQ+IsnPf366RG4cP9RtUi7MLO1N3KEc+wb0a6yKpeL0lmk2IB1jY5KHPAlTc6T/JRdC/YqxHNwkQ==}
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
obug@2.1.4:
|
|
|
|
|
resolution: {integrity: sha512-4a+OsYv9UktOJKE+l1A4OufDgdRF9PifWj+tJnHURo/P+WOxpG4GzUFL9qCalmWauao6ogiG+QvnCovwPoyAWA==}
|
|
|
|
|
engines: {node: '>=12.20.0'}
|
|
|
|
|
|
Add integration test setup and tests for the Vite integration (#14089)
This PR adds a new root `/integrations` folder that will be the home of
integration tests. The idea of these tests is to use Tailwind in various
setups just like our users would (by only using the publishable npm
builds).
To avoid issues with concurrent tests making changes to the file system,
to make it very easy to test through a range of versions, and to avoid
changing configuration objects over and over in test runs, we decided to
inline the scaffolding completely into the test file and have no
examples checked into the repo.
Here's an example of how this can look like for a simple Vite test:
```ts
test('works with production builds', {
fs: {
'package.json': json`
{
"type": "module",
"dependencies": {
"@tailwindcss/vite": "workspace:^",
"tailwindcss": "workspace:^"
},
"devDependencies": {
"vite": "^5.3.5"
}
}
`,
'vite.config.ts': ts`
import tailwindcss from '@tailwindcss/vite'
import { defineConfig } from 'vite'
export default defineConfig({
build: { cssMinify: false },
plugins: [tailwindcss()],
})
`,
'index.html': html`
<head>
<link rel="stylesheet" href="./src/index.css">
</head>
<body>
<div class="underline m-2">Hello, world!</div>
</body>
`,
'src/index.css': css`
@import 'tailwindcss/theme' reference;
@import 'tailwindcss/utilities';
`,
},
},
async ({ fs, exec }) => {
await exec('pnpm vite build')
expect.assertions(2)
for (let [path, content] of await fs.glob('dist/**/*.css')) {
expect(path).toMatch(/\.css$/)
expect(stripTailwindComment(content)).toMatchInlineSnapshot(
`
".m-2 {
margin: var(--spacing-2, .5rem);
}
.underline {
text-decoration-line: underline;
}"
`,
)
}
},
)
```
By defining all dependencies this way, we never have to worry about
which fixtures are checked in and can more easily describe changes to
the setup.
For ergonomics, we've also added the [`embed` prettier
plugin](https://github.com/Sec-ant/prettier-plugin-embed). This will
mean that files inlined in the `fs` setup are properly indented. No
extra work needed!
If you're using VS Code, I can also recommend the [Language
Literals](https://marketplace.visualstudio.com/items?itemName=sissel.language-literals)
extension so that syntax highlighting also _just works_.
A neat feature of inlining the scaffolding like this is to make it very
simple to test through a variety of versions. For example, here's how we
can set up a test against Vite 5 and Vite 4:
```js
;['^4.5.3', '^5.3.5'].forEach(viteVersion => {
test(`works with production builds for Vite ${viteVersion}`, {
fs: {
'package.json': json`
{
"type": "module",
"devDependencies": {
"vite": "${viteVersion}"
}
}
`,
async () => {
// Do something
},
)
})
```
## Philosophy
Before we dive into the specifics, I want to clearly state the design
considerations we have chosen for this new test suite:
- All file mutations should be done in temp folders, nothing should ever
mess with your working directory
- Windows as a first-class citizen
- Have a clean and simple API that describes the test setup only using
public APIs
- Focus on reliability (make sure cleanup scripts work and are tolerant
to various error scenarios)
- If a user reports an issue with a specific configuration, we want to
be able to reproduce them with integration tests, no matter how obscure
the setup (this means the test need to be in control of most of the
variables)
- Tests should be reasonably fast (obviously this depends on the
integration. If we use a slow build tool, we can't magically speed it
up, but our overhead should be minimal).
## How it works
The current implementation provides a custom `test` helper function
that, when used, sets up the environment according to the configuration.
It'll create a new temporary directory and create all files, ensuring
things like proper `\r\n` line endings on Windows.
We do have to patch the `package.json` specifically, since we can not
use public versions of the tailwindcss packages as we want to be able to
test against a development build. To make this happen, every `pnpm
build` run now creates tarballs of the npm modules (that contain only
the files that would also in the published build). We then patch the
`package.json` to rewrite `workspace:^` versions to link to those
tarballs. We found this to work reliably on Windows and macOS as well as
being fast enough to not cause any issues. Furthermore we also decided
to use `pnpm` as the version manager for integration tests because of
it's global module cache (so installing `vite` is fast as soon as you
installed it once).
The test function will receive a few utilities that it can use to more
easily interact with the temp dir. One example is a `fs.glob` function
that you can use to easily find files in eventual `dist/` directories or
helpers around `spawn` and `exec` that make sure that processes are
cleaned up correctly.
Because we use tarballs from our build dependencies, working on changes
requires a workflow where you run `pnpm build` before running `pnpm
test:integrations`. However it also means we can run clients like our
CLI client with no additional overhead—just install the dependency like
any user would and set up your test cases this way.
## Test plan
This PR also includes two Vite specific integration tests: One testing a
static build (`pnpm vite build`) and one a dev mode build (`pnpm vite
dev`) that also makes changes to the file system and asserts that the
resources properly update.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-08-02 11:50:49 +02:00
|
|
|
package-up@5.0.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-MQEgDUvXCa3sGvqHg3pzHO8e9gqTCMPVrWUko3vPQGntwegmFo52mZb2abIVTjFnUcW0BcPz0D93jV5Cas1DWA==}
|
|
|
|
|
engines: {node: '>=18'}
|
Add integration test setup and tests for the Vite integration (#14089)
This PR adds a new root `/integrations` folder that will be the home of
integration tests. The idea of these tests is to use Tailwind in various
setups just like our users would (by only using the publishable npm
builds).
To avoid issues with concurrent tests making changes to the file system,
to make it very easy to test through a range of versions, and to avoid
changing configuration objects over and over in test runs, we decided to
inline the scaffolding completely into the test file and have no
examples checked into the repo.
Here's an example of how this can look like for a simple Vite test:
```ts
test('works with production builds', {
fs: {
'package.json': json`
{
"type": "module",
"dependencies": {
"@tailwindcss/vite": "workspace:^",
"tailwindcss": "workspace:^"
},
"devDependencies": {
"vite": "^5.3.5"
}
}
`,
'vite.config.ts': ts`
import tailwindcss from '@tailwindcss/vite'
import { defineConfig } from 'vite'
export default defineConfig({
build: { cssMinify: false },
plugins: [tailwindcss()],
})
`,
'index.html': html`
<head>
<link rel="stylesheet" href="./src/index.css">
</head>
<body>
<div class="underline m-2">Hello, world!</div>
</body>
`,
'src/index.css': css`
@import 'tailwindcss/theme' reference;
@import 'tailwindcss/utilities';
`,
},
},
async ({ fs, exec }) => {
await exec('pnpm vite build')
expect.assertions(2)
for (let [path, content] of await fs.glob('dist/**/*.css')) {
expect(path).toMatch(/\.css$/)
expect(stripTailwindComment(content)).toMatchInlineSnapshot(
`
".m-2 {
margin: var(--spacing-2, .5rem);
}
.underline {
text-decoration-line: underline;
}"
`,
)
}
},
)
```
By defining all dependencies this way, we never have to worry about
which fixtures are checked in and can more easily describe changes to
the setup.
For ergonomics, we've also added the [`embed` prettier
plugin](https://github.com/Sec-ant/prettier-plugin-embed). This will
mean that files inlined in the `fs` setup are properly indented. No
extra work needed!
If you're using VS Code, I can also recommend the [Language
Literals](https://marketplace.visualstudio.com/items?itemName=sissel.language-literals)
extension so that syntax highlighting also _just works_.
A neat feature of inlining the scaffolding like this is to make it very
simple to test through a variety of versions. For example, here's how we
can set up a test against Vite 5 and Vite 4:
```js
;['^4.5.3', '^5.3.5'].forEach(viteVersion => {
test(`works with production builds for Vite ${viteVersion}`, {
fs: {
'package.json': json`
{
"type": "module",
"devDependencies": {
"vite": "${viteVersion}"
}
}
`,
async () => {
// Do something
},
)
})
```
## Philosophy
Before we dive into the specifics, I want to clearly state the design
considerations we have chosen for this new test suite:
- All file mutations should be done in temp folders, nothing should ever
mess with your working directory
- Windows as a first-class citizen
- Have a clean and simple API that describes the test setup only using
public APIs
- Focus on reliability (make sure cleanup scripts work and are tolerant
to various error scenarios)
- If a user reports an issue with a specific configuration, we want to
be able to reproduce them with integration tests, no matter how obscure
the setup (this means the test need to be in control of most of the
variables)
- Tests should be reasonably fast (obviously this depends on the
integration. If we use a slow build tool, we can't magically speed it
up, but our overhead should be minimal).
## How it works
The current implementation provides a custom `test` helper function
that, when used, sets up the environment according to the configuration.
It'll create a new temporary directory and create all files, ensuring
things like proper `\r\n` line endings on Windows.
We do have to patch the `package.json` specifically, since we can not
use public versions of the tailwindcss packages as we want to be able to
test against a development build. To make this happen, every `pnpm
build` run now creates tarballs of the npm modules (that contain only
the files that would also in the published build). We then patch the
`package.json` to rewrite `workspace:^` versions to link to those
tarballs. We found this to work reliably on Windows and macOS as well as
being fast enough to not cause any issues. Furthermore we also decided
to use `pnpm` as the version manager for integration tests because of
it's global module cache (so installing `vite` is fast as soon as you
installed it once).
The test function will receive a few utilities that it can use to more
easily interact with the temp dir. One example is a `fs.glob` function
that you can use to easily find files in eventual `dist/` directories or
helpers around `spawn` and `exec` that make sure that processes are
cleaned up correctly.
Because we use tarballs from our build dependencies, working on changes
requires a workflow where you run `pnpm build` before running `pnpm
test:integrations`. However it also means we can run clients like our
CLI client with no additional overhead—just install the dependency like
any user would and set up your test cases this way.
## Test plan
This PR also includes two Vite specific integration tests: One testing a
static build (`pnpm vite build`) and one a dev mode build (`pnpm vite
dev`) that also makes changes to the file system and asserts that the
resources properly update.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-08-02 11:50:49 +02:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
path-parse@1.0.7:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-LDJzPVEEEPR+y48z93A0Ed0yXb8pAByGWo/k5YYdYgpY2/2EsOsksJrq7lOHxryrVOn1ejG6oAp8ahvOIQD8sw==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2025-05-29 13:38:00 -04:00
|
|
|
pathe@2.0.3:
|
|
|
|
|
resolution: {integrity: sha512-WUjGcAqP1gQacoQe+OBJsFA7Ld4DyXuUIjZ5cc75cLHvJ7dtNsTugphxIADwspS+AraAUePCKrSVtPLFj/F88w==}
|
|
|
|
|
|
2024-10-24 11:25:50 +02:00
|
|
|
picocolors@1.1.1:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-xceH2snhtb5M9liqDsmEw56le376mTZkEX/jEb/RxNFyegNul7eNslCXP9FDj/Lcu0X8KEyMceP2ntpaHrDEVA==}
|
2024-10-03 11:15:18 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
picomatch@2.3.2:
|
|
|
|
|
resolution: {integrity: sha512-V7+vQEJ06Z+c5tSye8S+nHUfI51xoXIXjHQ99cQtKUkQqqO1kO/KCJUfZXuB47h/YBlDhah2H3hdUGXn8ie0oA==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=8.6'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
picomatch@4.0.4:
|
|
|
|
|
resolution: {integrity: sha512-QP88BAKvMam/3NxH6vj2o21R6MjxZUAd6nlwAS/pnGvN9IVLocLHxGYIzFhg6fUQ+5th6P4dv4eW9jX3DSIj7A==}
|
|
|
|
|
engines: {node: '>=12'}
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
picomatch@4.0.5:
|
|
|
|
|
resolution: {integrity: sha512-RvwwcruNjI1ncT5xRakeyS9Lf8lcItv34KD+aif+VH9kduAyfYBipGh12274xtenIPZ119/R9BdTBa8gAwSh0A==}
|
|
|
|
|
engines: {node: '>=12'}
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
pify@2.3.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-udgsAY+fTnvv7kI7aaxbqwWNb0AHiB0qBO89PZKPkoTmGOgdbrHDKD+0B2X4uTfJ/FT1R09r9gTsjUjNJotuog==}
|
|
|
|
|
engines: {node: '>=0.10.0'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
pirates@4.0.7:
|
|
|
|
|
resolution: {integrity: sha512-TfySrs/5nm8fQJDcBDuUng3VOUKsd7S+zqvbOTiGXHfxX4wK31ard+hoNuvkicM/2YFzlpDgABOevKSsB4G/FA==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>= 6'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
pkg-types@1.3.1:
|
|
|
|
|
resolution: {integrity: sha512-/Jm5M4RvtBFVkKWRu2BLUTNP8/M2a+UwuAX+ae4770q1qVGtfjG+WTCupoZixokjmHiry8uI+dlY8KXYV5HVVQ==}
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
playwright-core@1.62.1:
|
|
|
|
|
resolution: {integrity: sha512-wPYSwEBJY9GHraISXqyqtx0na0LpO3XEX7jNDhntbex7tzUS7kLnZsOlFruFJB4Hi/rhDMjXGqHewDZ68nYZVw==}
|
|
|
|
|
engines: {node: '>=20'}
|
2024-05-24 15:07:44 +02:00
|
|
|
hasBin: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
playwright@1.62.1:
|
|
|
|
|
resolution: {integrity: sha512-0M+L3LAD8/nm554LOla9Ayx0j0tmFZ0FBcoQ7F1VuVHpM/XpiC8RcDzBQB8W5+hA8L22THxELzeF+2WcUzvcLg==}
|
|
|
|
|
engines: {node: '>=20'}
|
2024-05-24 15:07:44 +02:00
|
|
|
hasBin: true
|
|
|
|
|
|
2024-10-24 11:00:25 -04:00
|
|
|
postcss-import@15.1.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-hpr+J05B2FVYUAXHeK1YyI267J/dDDhMU6B6civm8hSY1jYJnBXxzKDKDswzJmtLHryrjhnDjqqp/49t8FALew==}
|
|
|
|
|
engines: {node: '>=14.0.0'}
|
2024-10-24 11:00:25 -04:00
|
|
|
peerDependencies:
|
|
|
|
|
postcss: ^8.0.0
|
|
|
|
|
|
2025-06-24 09:57:35 -04:00
|
|
|
postcss-import@16.1.1:
|
|
|
|
|
resolution: {integrity: sha512-2xVS1NCZAfjtVdvXiyegxzJ447GyqCeEI5V7ApgQVOWnros1p5lGNovJNapwPpMombyFBfqDwt7AD3n2l0KOfQ==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=18.0.0'}
|
2024-05-24 15:07:44 +02:00
|
|
|
peerDependencies:
|
|
|
|
|
postcss: ^8.0.0
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
postcss-js@4.1.0:
|
|
|
|
|
resolution: {integrity: sha512-oIAOTqgIo7q2EOwbhb8UalYePMvYoIeRY2YKntdpFQXNosSu3vLrniGgmH9OKs/qAkfoj5oB3le/7mINW1LCfw==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: ^12 || ^14 || >= 16}
|
2024-10-24 11:00:25 -04:00
|
|
|
peerDependencies:
|
|
|
|
|
postcss: ^8.4.21
|
|
|
|
|
|
2024-08-02 10:33:14 +02:00
|
|
|
postcss-load-config@6.0.1:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-oPtTM4oerL+UXmx+93ytZVN82RrlY/wPUV8IeDxFrzIjXOLF1pN+EmKPLbubvKHT2HC20xXsCAH2Z+CKV6Oz/g==}
|
|
|
|
|
engines: {node: '>= 18'}
|
2024-05-24 15:07:44 +02:00
|
|
|
peerDependencies:
|
2024-08-02 10:33:14 +02:00
|
|
|
jiti: '>=1.21.0'
|
2024-05-24 15:07:44 +02:00
|
|
|
postcss: '>=8.0.9'
|
2024-08-02 10:33:14 +02:00
|
|
|
tsx: ^4.8.1
|
|
|
|
|
yaml: ^2.4.2
|
2024-05-24 15:07:44 +02:00
|
|
|
peerDependenciesMeta:
|
2024-08-02 10:33:14 +02:00
|
|
|
jiti:
|
|
|
|
|
optional: true
|
2024-05-24 15:07:44 +02:00
|
|
|
postcss:
|
|
|
|
|
optional: true
|
2024-08-02 10:33:14 +02:00
|
|
|
tsx:
|
|
|
|
|
optional: true
|
|
|
|
|
yaml:
|
2024-05-24 15:07:44 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2024-10-24 11:00:25 -04:00
|
|
|
postcss-nested@6.2.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-HQbt28KulC5AJzG+cZtj9kvKB93CFCdLvog1WFLf1D+xmMvPGlBstkpTEZfK5+AN9hfJocyBFCNiqyS48bpgzQ==}
|
|
|
|
|
engines: {node: '>=12.0'}
|
2024-10-24 11:00:25 -04:00
|
|
|
peerDependencies:
|
|
|
|
|
postcss: ^8.2.14
|
|
|
|
|
|
2024-11-19 16:19:08 +01:00
|
|
|
postcss-selector-parser@6.0.10:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-IQ7TZdoaqbT+LCpShg46jnZVlhWD2w6iQYAcYXfHARZ7X1t/UGhhceQDs5X0cGqKvYlHNOuv7Oa1xmb0oQuA3w==}
|
|
|
|
|
engines: {node: '>=4'}
|
2024-11-19 16:19:08 +01:00
|
|
|
|
Add CSS codemods for migrating `@layer utilities` (#14455)
This PR adds CSS codemods for migrating existing `@layer utilities` to
`@utility` directives.
This PR has the ability to migrate the following cases:
---
The most basic case is when you want to migrate a simple class to a
utility directive.
Input:
```css
@layer utilities {
.foo {
color: red;
}
.bar {
color: blue;
}
}
```
Output:
```css
@utility foo {
color: red;
}
@utility bar {
color: blue;
}
```
You'll notice that the class `foo` will be used as the utility name, the
declarations (and the rest of the body of the rule) will become the body
of the `@utility` definition.
---
In v3, every class in a selector will become a utility. To correctly
migrate this to `@utility` directives, we have to register each class in
the selector and generate `n` utilities.
We can use nesting syntax, and replace the current class with `&` to
ensure that the final result behaves the same.
Input:
```css
@layer utilities {
.foo .bar .baz {
color: red;
}
}
```
Output:
```css
@utility foo {
& .bar .baz {
color: red;
}
}
@utility bar {
.foo & .baz {
color: red;
}
}
@utility .baz {
.foo .bar & {
color: red;
}
}
```
In this case, it could be that you know that some of them will never be
used as a utility (e.g.: `hover:bar`), but then you can safely remove
them.
---
Even classes inside of `:has(…)` will become a utility. The only
exception to the rule is that we don't do it for `:not(…)`.
Input:
```css
@layer utilities {
.foo .bar:not(.qux):has(.baz) {
display: none;
}
}
```
Output:
```css
@utility foo {
& .bar:not(.qux):has(.baz) {
display: none;
}
}
@utility bar {
.foo &:not(.qux):has(.baz) {
display: none;
}
}
@utility baz {
.foo .bar:not(.qux):has(&) {
display: none;
}
}
```
Notice that there is no `@utility qux` because it was used inside of
`:not(…)`.
---
When classes are nested inside at-rules, then these classes will also
become utilities. However, the `@utility <name>` will be at the top and
the at-rules will live inside of it. If there are multiple classes
inside a shared at-rule, then the at-rule will be duplicated for each
class.
Let's look at an example to make it more clear:
Input:
```css
@layer utilities {
@media (min-width: 640px) {
.foo {
color: red;
}
.bar {
color: blue;
}
@media (min-width: 1024px) {
.baz {
color: green;
}
@media (min-width: 1280px) {
.qux {
color: yellow;
}
}
}
}
}
```
Output:
```css
@utility foo {
@media (min-width: 640px) {
color: red;
}
}
@utility bar {
@media (min-width: 640px) {
color: blue;
}
}
@utility baz {
@media (min-width: 640px) {
@media (min-width: 1024px) {
color: green;
}
}
}
@utility qux {
@media (min-width: 640px) {
@media (min-width: 1024px) {
@media (min-width: 1280px) {
color: yellow;
}
}
}
}
```
---
When classes result in multiple `@utility` directives with the same
name, then the definitions will be merged together.
Input:
```css
@layer utilities {
.no-scrollbar::-webkit-scrollbar {
display: none;
}
.no-scrollbar {
-ms-overflow-style: none;
scrollbar-width: none;
}
}
```
Intermediate representation:
```css
@utility no-scrollbar {
&::-webkit-scrollbar {
display: none;
}
}
@utility no-scrollbar {
-ms-overflow-style: none;
scrollbar-width: none;
}
```
Output:
```css
@utility no-scrollbar {
&::-webkit-scrollbar {
display: none;
}
-ms-overflow-style: none;
scrollbar-width: none
}
```
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-09-24 18:17:09 +02:00
|
|
|
postcss-selector-parser@6.1.2:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-Q8qQfPiZ+THO/3ZrOrO0cJJKfpYCagtMUkXbnEfmgUjwXg6z/WBeOyS9APBBPCTSiDV+s4SwQGu8yFsiMRIudg==}
|
|
|
|
|
engines: {node: '>=4'}
|
Add CSS codemods for migrating `@layer utilities` (#14455)
This PR adds CSS codemods for migrating existing `@layer utilities` to
`@utility` directives.
This PR has the ability to migrate the following cases:
---
The most basic case is when you want to migrate a simple class to a
utility directive.
Input:
```css
@layer utilities {
.foo {
color: red;
}
.bar {
color: blue;
}
}
```
Output:
```css
@utility foo {
color: red;
}
@utility bar {
color: blue;
}
```
You'll notice that the class `foo` will be used as the utility name, the
declarations (and the rest of the body of the rule) will become the body
of the `@utility` definition.
---
In v3, every class in a selector will become a utility. To correctly
migrate this to `@utility` directives, we have to register each class in
the selector and generate `n` utilities.
We can use nesting syntax, and replace the current class with `&` to
ensure that the final result behaves the same.
Input:
```css
@layer utilities {
.foo .bar .baz {
color: red;
}
}
```
Output:
```css
@utility foo {
& .bar .baz {
color: red;
}
}
@utility bar {
.foo & .baz {
color: red;
}
}
@utility .baz {
.foo .bar & {
color: red;
}
}
```
In this case, it could be that you know that some of them will never be
used as a utility (e.g.: `hover:bar`), but then you can safely remove
them.
---
Even classes inside of `:has(…)` will become a utility. The only
exception to the rule is that we don't do it for `:not(…)`.
Input:
```css
@layer utilities {
.foo .bar:not(.qux):has(.baz) {
display: none;
}
}
```
Output:
```css
@utility foo {
& .bar:not(.qux):has(.baz) {
display: none;
}
}
@utility bar {
.foo &:not(.qux):has(.baz) {
display: none;
}
}
@utility baz {
.foo .bar:not(.qux):has(&) {
display: none;
}
}
```
Notice that there is no `@utility qux` because it was used inside of
`:not(…)`.
---
When classes are nested inside at-rules, then these classes will also
become utilities. However, the `@utility <name>` will be at the top and
the at-rules will live inside of it. If there are multiple classes
inside a shared at-rule, then the at-rule will be duplicated for each
class.
Let's look at an example to make it more clear:
Input:
```css
@layer utilities {
@media (min-width: 640px) {
.foo {
color: red;
}
.bar {
color: blue;
}
@media (min-width: 1024px) {
.baz {
color: green;
}
@media (min-width: 1280px) {
.qux {
color: yellow;
}
}
}
}
}
```
Output:
```css
@utility foo {
@media (min-width: 640px) {
color: red;
}
}
@utility bar {
@media (min-width: 640px) {
color: blue;
}
}
@utility baz {
@media (min-width: 640px) {
@media (min-width: 1024px) {
color: green;
}
}
}
@utility qux {
@media (min-width: 640px) {
@media (min-width: 1024px) {
@media (min-width: 1280px) {
color: yellow;
}
}
}
}
```
---
When classes result in multiple `@utility` directives with the same
name, then the definitions will be merged together.
Input:
```css
@layer utilities {
.no-scrollbar::-webkit-scrollbar {
display: none;
}
.no-scrollbar {
-ms-overflow-style: none;
scrollbar-width: none;
}
}
```
Intermediate representation:
```css
@utility no-scrollbar {
&::-webkit-scrollbar {
display: none;
}
}
@utility no-scrollbar {
-ms-overflow-style: none;
scrollbar-width: none;
}
```
Output:
```css
@utility no-scrollbar {
&::-webkit-scrollbar {
display: none;
}
-ms-overflow-style: none;
scrollbar-width: none
}
```
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-09-24 18:17:09 +02:00
|
|
|
|
2026-06-19 13:11:16 +02:00
|
|
|
postcss-selector-parser@7.1.4:
|
|
|
|
|
resolution: {integrity: sha512-HeP7D2wyhkR+XaK6v4W8oRF62Dsz4flyuczALJp61GckGm42u1saSSJ/0auvcBqxs3jMRFEcPK34At/0JBKdOg==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=4'}
|
2024-10-30 15:27:53 -04:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
postcss-value-parser@4.2.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-1NNCs6uurfkVbeXG4S8JFT9t19m45ICnif8zWLd5oPSZ50QnwMfK+H3jv408d4jw/7Bttv5axS5IiHoLaVNHeQ==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
|
|
|
|
postcss@8.4.31:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-PS08Iboia9mts/2ygV3eLpY5ghnUcfLV/EXTOW1E2qYxJKGGBUtNjN76FYHnMs36RmARn41bC0AZmn+rR0OVpQ==}
|
|
|
|
|
engines: {node: ^10 || ^12 || >=14}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-07-02 11:45:49 +02:00
|
|
|
postcss@8.5.16:
|
|
|
|
|
resolution: {integrity: sha512-vuwillviilfKZsg0VGj5R/YwwcHx4SLsIOI/7K6mQkWx+l5cUHTjj5g0AasTBcyXsbfTgrwsUNmVUb5xVwyPwg==}
|
|
|
|
|
engines: {node: ^10 || ^12 || >=14}
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
postcss@8.5.25:
|
|
|
|
|
resolution: {integrity: sha512-DTPx3RWSSnWyzLxQnlH0rJP+EW5ekl16ZU4/psbIhA0e53kJfdgaN5vKM+xP7yJtXVu+nfdVFmlgFDEKAe4Pyw==}
|
|
|
|
|
engines: {node: ^10 || ^12 || >=14}
|
|
|
|
|
|
2025-12-26 12:36:51 -05:00
|
|
|
prettier-plugin-embed@0.5.1:
|
|
|
|
|
resolution: {integrity: sha512-2Ege8gIlLNTvHElUeU5XcFsD7/dbDXkQA6H9TczHSJAGxB58nNjjifk/dlRMS5E29eqQx/z+ToA4ZVMWzjME/A==}
|
Add integration test setup and tests for the Vite integration (#14089)
This PR adds a new root `/integrations` folder that will be the home of
integration tests. The idea of these tests is to use Tailwind in various
setups just like our users would (by only using the publishable npm
builds).
To avoid issues with concurrent tests making changes to the file system,
to make it very easy to test through a range of versions, and to avoid
changing configuration objects over and over in test runs, we decided to
inline the scaffolding completely into the test file and have no
examples checked into the repo.
Here's an example of how this can look like for a simple Vite test:
```ts
test('works with production builds', {
fs: {
'package.json': json`
{
"type": "module",
"dependencies": {
"@tailwindcss/vite": "workspace:^",
"tailwindcss": "workspace:^"
},
"devDependencies": {
"vite": "^5.3.5"
}
}
`,
'vite.config.ts': ts`
import tailwindcss from '@tailwindcss/vite'
import { defineConfig } from 'vite'
export default defineConfig({
build: { cssMinify: false },
plugins: [tailwindcss()],
})
`,
'index.html': html`
<head>
<link rel="stylesheet" href="./src/index.css">
</head>
<body>
<div class="underline m-2">Hello, world!</div>
</body>
`,
'src/index.css': css`
@import 'tailwindcss/theme' reference;
@import 'tailwindcss/utilities';
`,
},
},
async ({ fs, exec }) => {
await exec('pnpm vite build')
expect.assertions(2)
for (let [path, content] of await fs.glob('dist/**/*.css')) {
expect(path).toMatch(/\.css$/)
expect(stripTailwindComment(content)).toMatchInlineSnapshot(
`
".m-2 {
margin: var(--spacing-2, .5rem);
}
.underline {
text-decoration-line: underline;
}"
`,
)
}
},
)
```
By defining all dependencies this way, we never have to worry about
which fixtures are checked in and can more easily describe changes to
the setup.
For ergonomics, we've also added the [`embed` prettier
plugin](https://github.com/Sec-ant/prettier-plugin-embed). This will
mean that files inlined in the `fs` setup are properly indented. No
extra work needed!
If you're using VS Code, I can also recommend the [Language
Literals](https://marketplace.visualstudio.com/items?itemName=sissel.language-literals)
extension so that syntax highlighting also _just works_.
A neat feature of inlining the scaffolding like this is to make it very
simple to test through a variety of versions. For example, here's how we
can set up a test against Vite 5 and Vite 4:
```js
;['^4.5.3', '^5.3.5'].forEach(viteVersion => {
test(`works with production builds for Vite ${viteVersion}`, {
fs: {
'package.json': json`
{
"type": "module",
"devDependencies": {
"vite": "${viteVersion}"
}
}
`,
async () => {
// Do something
},
)
})
```
## Philosophy
Before we dive into the specifics, I want to clearly state the design
considerations we have chosen for this new test suite:
- All file mutations should be done in temp folders, nothing should ever
mess with your working directory
- Windows as a first-class citizen
- Have a clean and simple API that describes the test setup only using
public APIs
- Focus on reliability (make sure cleanup scripts work and are tolerant
to various error scenarios)
- If a user reports an issue with a specific configuration, we want to
be able to reproduce them with integration tests, no matter how obscure
the setup (this means the test need to be in control of most of the
variables)
- Tests should be reasonably fast (obviously this depends on the
integration. If we use a slow build tool, we can't magically speed it
up, but our overhead should be minimal).
## How it works
The current implementation provides a custom `test` helper function
that, when used, sets up the environment according to the configuration.
It'll create a new temporary directory and create all files, ensuring
things like proper `\r\n` line endings on Windows.
We do have to patch the `package.json` specifically, since we can not
use public versions of the tailwindcss packages as we want to be able to
test against a development build. To make this happen, every `pnpm
build` run now creates tarballs of the npm modules (that contain only
the files that would also in the published build). We then patch the
`package.json` to rewrite `workspace:^` versions to link to those
tarballs. We found this to work reliably on Windows and macOS as well as
being fast enough to not cause any issues. Furthermore we also decided
to use `pnpm` as the version manager for integration tests because of
it's global module cache (so installing `vite` is fast as soon as you
installed it once).
The test function will receive a few utilities that it can use to more
easily interact with the temp dir. One example is a `fs.glob` function
that you can use to easily find files in eventual `dist/` directories or
helpers around `spawn` and `exec` that make sure that processes are
cleaned up correctly.
Because we use tarballs from our build dependencies, working on changes
requires a workflow where you run `pnpm build` before running `pnpm
test:integrations`. However it also means we can run clients like our
CLI client with no additional overhead—just install the dependency like
any user would and set up your test cases this way.
## Test plan
This PR also includes two Vite specific integration tests: One testing a
static build (`pnpm vite build`) and one a dev mode build (`pnpm vite
dev`) that also makes changes to the file system and asserts that the
resources properly update.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-08-02 11:50:49 +02:00
|
|
|
|
2025-09-26 16:10:41 -04:00
|
|
|
prettier-plugin-organize-imports@4.3.0:
|
|
|
|
|
resolution: {integrity: sha512-FxFz0qFhyBsGdIsb697f/EkvHzi5SZOhWAjxcx2dLt+Q532bAlhswcXGYB1yzjZ69kW8UoadFBw7TyNwlq96Iw==}
|
2024-05-24 15:07:44 +02:00
|
|
|
peerDependencies:
|
|
|
|
|
prettier: '>=2.0'
|
|
|
|
|
typescript: '>=2.9'
|
2025-07-29 14:01:37 -04:00
|
|
|
vue-tsc: ^2.1.0 || 3
|
2024-05-24 15:07:44 +02:00
|
|
|
peerDependenciesMeta:
|
2024-08-09 16:12:24 +02:00
|
|
|
vue-tsc:
|
2024-05-24 15:07:44 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
prettier@3.9.6:
|
|
|
|
|
resolution: {integrity: sha512-OpN0zzVdiaiAhxpuuj5efpIS4sY9j7bY6uR5mnj5yPzGkdkjNKSJeUThPb60Jw29QuAZgA4o+/iB49kFiaBX6g==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=14'}
|
2024-05-24 15:07:44 +02:00
|
|
|
hasBin: true
|
|
|
|
|
|
|
|
|
|
queue-microtask@1.2.3:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-NuaNSa6flKT5JaSYQzJok04JzTL1CA6aGhv5rfLW3PgqA+M2ChpZQnAC8h8i4ZFkBS8X5RqkDBHA7r4hej3K9A==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2025-01-07 09:57:34 -05:00
|
|
|
radix3@1.1.2:
|
|
|
|
|
resolution: {integrity: sha512-b484I/7b8rDEdSDKckSSBA8knMpcdsXudlE/LNL639wFoHKwLbEkQFZHWEYwDC0wa0FKUcCY+GAF73Z7wxNVFA==}
|
|
|
|
|
|
2026-05-14 12:41:48 +02:00
|
|
|
react-dom@19.2.6:
|
|
|
|
|
resolution: {integrity: sha512-0prMI+hvBbPjsWnxDLxlCGyM8PN6UuWjEUCYmZhO67xIV9Xasa/r/vDnq+Xyq4Lo27g8QSbO5YzARu0D1Sps3g==}
|
|
|
|
|
peerDependencies:
|
|
|
|
|
react: ^19.2.6
|
|
|
|
|
|
2026-06-09 10:44:01 +00:00
|
|
|
react-dom@19.2.7:
|
|
|
|
|
resolution: {integrity: sha512-t0BRVXvbiE/o20Hfw669rLbMCDWtYZLvmJigy2f0MxsXF+71pxhR3xOkspmsO8h3ZlNzyibAmtCa3l4lYKk6gQ==}
|
|
|
|
|
peerDependencies:
|
|
|
|
|
react: ^19.2.7
|
|
|
|
|
|
2026-05-14 12:41:48 +02:00
|
|
|
react@19.2.6:
|
|
|
|
|
resolution: {integrity: sha512-sfWGGfavi0xr8Pg0sVsyHMAOziVYKgPLNrS7ig+ivMNb3wbCBw3KxtflsGBAwD3gYQlE/AEZsTLgToRrSCjb0Q==}
|
|
|
|
|
engines: {node: '>=0.10.0'}
|
|
|
|
|
|
2026-06-09 10:44:01 +00:00
|
|
|
react@19.2.7:
|
|
|
|
|
resolution: {integrity: sha512-HNe9WslTbXmFK8o8cmwgAeJFSBvt1bPdHCVKtaaV+WlAN36mpT4hcRpwbf3fY56ar2oIXzsBpOAiIRHAdY0OlQ==}
|
|
|
|
|
engines: {node: '>=0.10.0'}
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
read-cache@1.0.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-Owdv/Ft7IjOgm/i0xvNDZ1LrRANRfew4b2prF3OWMQLxLfu3bS8FVhCsrSCMK4lR56Y9ya+AThoTpDCTxCmpRA==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
|
|
|
|
readdirp@3.6.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-hOS089on8RduqdbhvQ5Z37A0ESjsqz6qnRcffsMU3495FuTdqSm+7bhJ29JvIOsBDEEnan5DPu9t3To9VRlMzA==}
|
|
|
|
|
engines: {node: '>=8.10.0'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
readdirp@4.1.2:
|
|
|
|
|
resolution: {integrity: sha512-GDhwkLfywWL2s6vEjyhri+eXmfH6j1L7JE27WhqLeYzoh/A3DBaYGEj2H/HFZCn/kMfim73FXxEJTw06WtxQwg==}
|
2025-02-03 11:20:51 +01:00
|
|
|
engines: {node: '>= 14.18.0'}
|
|
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
require-from-string@2.0.2:
|
|
|
|
|
resolution: {integrity: sha512-Xf0nWe6RseziFMu+Ap9biiUbmplq6S9/p+7w7YXP/JBHhrUDDUhwa+vANyubuqfZWTveU//DYVGsDG7RKL/vEw==}
|
|
|
|
|
engines: {node: '>=0.10.0'}
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
resolve-from@5.0.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-qYg9KP24dD5qka9J47d0aVky0N+b4fTU89LN9iDnjB5waksiC49rvMB0PrUJQGoTmH50XPiqOvAjDfaijGxYZw==}
|
|
|
|
|
engines: {node: '>=8'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
resolve@1.22.12:
|
|
|
|
|
resolution: {integrity: sha512-TyeJ1zif53BPfHootBGwPRYT1RUt6oGWsaQr8UyZW/eAm9bKoijtvruSDEmZHm92CwS9nj7/fWttqPCgzep8CA==}
|
|
|
|
|
engines: {node: '>= 0.4'}
|
2024-05-24 15:07:44 +02:00
|
|
|
hasBin: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
reusify@1.1.0:
|
|
|
|
|
resolution: {integrity: sha512-g6QUff04oZpHs0eG5p83rFLhHeV00ug/Yf9nZM6fLeUrPguBTkTQOdpAWWspMh55TZfVQDPaN3NQJfbVRAxdIw==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {iojs: '>=1.0.0', node: '>=0.10.0'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
rolldown@1.2.1:
|
|
|
|
|
resolution: {integrity: sha512-4FKJhg8d3OiyQOA6Q1Q0hoFFpW9/OoX+VsHzpECsdsIZoOArrAK90gl59YK/Z+gnDel45bgJZK03ozH/9bCqEw==}
|
2026-03-12 20:54:34 +01:00
|
|
|
engines: {node: ^20.19.0 || >=22.12.0}
|
|
|
|
|
hasBin: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
rollup@4.60.4:
|
|
|
|
|
resolution: {integrity: sha512-WHeFSbZYsPu3+bLoNRUuAO+wavNlocOPf3wSHTP7hcFKVnJeWsYlCDbr3mTS14FCizf9ccIxXA8sGL8zKeQN3g==}
|
2025-06-24 18:31:17 +02:00
|
|
|
engines: {node: '>=18.0.0', npm: '>=8.0.0'}
|
|
|
|
|
hasBin: true
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
run-parallel@1.2.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-5l4VyZR86LZ/lDxZTR6jqL8AFE2S0IFLMP26AbjsLVADxHdhB/c0GUsH+y39UfCi3dzz8OlQuPmnaJOMoDHQBA==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2025-04-11 17:19:55 +02:00
|
|
|
safer-buffer@2.1.2:
|
|
|
|
|
resolution: {integrity: sha512-YZo3K82SD7Riyi0E1EQPojLz7kpepnSQI9IyPbHHg1XXXevb5dJI7tpyN2ADxGcQbHG7vcyRHk0cbwqcQriUtg==}
|
|
|
|
|
|
Update all of react 19.1.1 → 19.2.0 (minor) (#19087)
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?
#### ✳️ react (19.1.1 → 19.2.0) ·
[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.0">19.2.0</a></h4>
<blockquote><p dir="auto">Below is a list of all new features, APIs, and
bug fixes.</p>
<p dir="auto">Read the <a
href="https://react.dev/blog/2025/10/01/react-19-2">React 19.2 release
post</a> for more information.</p>
<h2 dir="auto">New React Features</h2>
<ul dir="auto">
<li>
<a href="https://react.dev/reference/react/Activity"><code
class="notranslate"><Activity></code></a>: A new API to hide and
restore the UI and internal state of its children.</li>
<li>
<a href="https://react.dev/reference/react/useEffectEvent"><code
class="notranslate">useEffectEvent</code></a> is a React Hook that lets
you extract non-reactive logic into an <a
href="https://react.dev/learn/separating-events-from-effects#declaring-an-effect-event">Effect
Event</a>.</li>
<li>
<a href="https://react.dev/reference/react/cacheSignal"><code
class="notranslate">cacheSignal</code></a> (for RSCs) lets your know
when the <code class="notranslate">cache()</code> lifetime is over.</li>
<li>
<a
href="https://react.dev/reference/developer-tooling/react-performance-tracks">React
Performance tracks</a> appear on the Performance panel’s timeline in
your browser developer tools</li>
</ul>
<h2 dir="auto">New React DOM Features</h2>
<ul dir="auto">
<li>Added resume APIs for partial pre-rendering with Web Streams:
<ul dir="auto">
<li>
<a href="https://react.dev/reference/react-dom/server/resume"><code
class="notranslate">resume</code></a>: to resume a prerender to a
stream.</li>
<li>
<a
href="https://react.dev/reference/react-dom/static/resumeAndPrerender"><code
class="notranslate">resumeAndPrerender</code></a>: to resume a prerender
to HTML.</li>
</ul>
</li>
<li>Added resume APIs for partial pre-rendering with Node Streams:
<ul dir="auto">
<li>
<a
href="https://react.dev/reference/react-dom/server/resumeToPipeableStream"><code
class="notranslate">resumeToPipeableStream</code></a>: to resume a
prerender to a stream.</li>
<li>
<a
href="https://react.dev/reference/react-dom/static/resumeAndPrerenderToNodeStream"><code
class="notranslate">resumeAndPrerenderToNodeStream</code></a>: to resume
a prerender to HTML.</li>
</ul>
</li>
<li>Updated <a
href="https://react.dev/reference/react-dom/static/prerender"><code
class="notranslate">prerender</code></a> APIs to return a <code
class="notranslate">postponed</code> state that can be passed to the
<code class="notranslate">resume</code> APIs.</li>
</ul>
<h2 dir="auto">Notable changes</h2>
<ul dir="auto">
<li>React DOM now batches suspense boundary reveals, matching the
behavior of client side rendering. This change is especially noticeable
when animating the reveal of Suspense boundaries e.g. with the upcoming
<code class="notranslate"><ViewTransition></code> Component. React
will batch as much reveals as possible before the first paint while
trying to hit popular first-contentful paint metrics.</li>
<li>Add Node Web Streams (<code class="notranslate">prerender</code>,
<code class="notranslate">renderToReadableStream</code>) to
server-side-rendering APIs for Node.js</li>
<li>Use underscore instead of <code class="notranslate">:</code> IDs
generated by useId</li>
</ul>
<h2 dir="auto">All Changes</h2>
<h3 dir="auto">React</h3>
<ul dir="auto">
<li>
<code class="notranslate"><Activity /></code> was developed over
many years, starting before <code
class="notranslate">ClassComponent.setState</code> (<a
href="https://bounce.depfu.com/github.com/acdlite">@acdlite</a> <a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
and many others)</li>
<li>Stringify context as "SomeContext" instead of "SomeContext.Provider"
(<a href="https://bounce.depfu.com/github.com/kassens">@kassens</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33507">#33507</a>)</li>
<li>Include stack of cause of React instrumentation errors with <code
class="notranslate">%o</code> placeholder (<a
href="https://bounce.depfu.com/github.com/eps1lon">@eps1lon</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34198">#34198</a>)</li>
<li>Fix infinite <code class="notranslate">useDeferredValue</code> loop
in popstate event (<a
href="https://bounce.depfu.com/github.com/acdlite">@acdlite</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32821">#32821</a>)</li>
<li>Fix a bug when an initial value was passed to <code
class="notranslate">useDeferredValue</code> (<a
href="https://bounce.depfu.com/github.com/acdlite">@acdlite</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34376">#34376</a>)</li>
<li>Fix a crash when submitting forms with Client Actions (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33055">#33055</a>)</li>
<li>Hide/unhide the content of dehydrated suspense boundaries if they
resuspend (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32900">#32900</a>)</li>
<li>Avoid stack overflow on wide trees during Hot Reload (<a
href="https://bounce.depfu.com/github.com/sophiebits">@sophiebits</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34145">#34145</a>)</li>
<li>Improve Owner and Component stacks in various places (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>,
<a href="https://bounce.depfu.com/github.com/eps1lon">@eps1lon</a>: <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33629">#33629</a>,
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33724">#33724</a>,
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32735">#32735</a>,
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33723">#33723</a>)</li>
<li>Add <code class="notranslate">cacheSignal</code> (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33557">#33557</a>)</li>
</ul>
<h3 dir="auto">React DOM</h3>
<ul dir="auto">
<li>Block on Suspensey Fonts during reveal of server-side-rendered
content (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33342">#33342</a>)</li>
<li>Use underscore instead of <code class="notranslate">:</code> for IDs
generated by <code class="notranslate">useId</code> (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>,
<a href="https://bounce.depfu.com/github.com/eps1lon">@eps1lon</a>: <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32001">#32001</a>,
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33342">#33342</a><a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33099">#33099</a>,
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33422">#33422</a>)</li>
<li>Stop warning when ARIA 1.3 attributes are used (<a
href="https://bounce.depfu.com/github.com/Abdul-Omira">@Abdul-Omira</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34264">#34264</a>)</li>
<li>Allow <code class="notranslate">nonce</code> to be used on hoistable
styles (<a
href="https://bounce.depfu.com/github.com/Andarist">@Andarist</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32461">#32461</a>)</li>
<li>Warn for using a React owned node as a Container if it also has text
content (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32774">#32774</a>)</li>
<li>s/HTML/text for for error messages if text hydration mismatches (<a
href="https://bounce.depfu.com/github.com/rickhanlonii">@rickhanlonii</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32763">#32763</a>)</li>
<li>Fix a bug with <code class="notranslate">React.use</code> inside
<code class="notranslate">React.lazy</code>-ed Component (<a
href="https://bounce.depfu.com/github.com/hi-ogawa">@hi-ogawa</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33941">#33941</a>)</li>
<li>Enable the <code class="notranslate">progressiveChunkSize</code>
option for server-side-rendering APIs (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33027">#33027</a>)</li>
<li>Fix a bug with deeply nested Suspense inside Suspense fallback when
server-side-rendering (<a
href="https://bounce.depfu.com/github.com/gnoff">@gnoff</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33467">#33467</a>)</li>
<li>Avoid hanging when suspending after aborting while rendering (<a
href="https://bounce.depfu.com/github.com/gnoff">@gnoff</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34192">#34192</a>)</li>
<li>Add Node Web Streams to server-side-rendering APIs for Node.js (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33475">#33475</a>)</li>
</ul>
<h3 dir="auto">React Server Components</h3>
<ul dir="auto">
<li>Preload <code class="notranslate"><img></code> and <code
class="notranslate"><link></code> using hints before they're
rendered (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34604">#34604</a>)</li>
<li>Log error if production elements are rendered during development (<a
href="https://bounce.depfu.com/github.com/eps1lon">@eps1lon</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34189">#34189</a>)</li>
<li>Fix a bug when returning a Temporary reference (e.g. a Client
Reference) from Server Functions (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34084">#34084</a>,
<a href="https://bounce.depfu.com/github.com/denk0403">@denk0403</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33761">#33761</a>)</li>
<li>Pass line/column to <code
class="notranslate">filterStackFrame</code> (<a
href="https://bounce.depfu.com/github.com/eps1lon">@eps1lon</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33707">#33707</a>)</li>
<li>Support Async Modules in Turbopack Server References (<a
href="https://bounce.depfu.com/github.com/lubieowoce">@lubieowoce</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34531">#34531</a>)</li>
<li>Add support for .mjs file extension in Webpack (<a
href="https://bounce.depfu.com/github.com/jennyscript">@jennyscript</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33028">#33028</a>)</li>
<li>Fix a wrong missing key warning (<a
href="https://bounce.depfu.com/github.com/unstubbable">@unstubbable</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34350">#34350</a>)</li>
<li>Make console log resolve in predictable order (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33665">#33665</a>)</li>
</ul>
<h3 dir="auto">React Reconciler</h3>
<ul dir="auto">
<li>
<a
href="https://bounce.depfu.com/github.com/facebook/react/blob/v19.2.0/packages/react-reconciler/src/ReactFiberReconciler.js#L255-L261">createContainer</a>
and <a
href="https://bounce.depfu.com/github.com/facebook/react/blob/v19.2.0/packages/react-reconciler/src/ReactFiberReconciler.js#L305-L312">createHydrationContainer</a>
had their parameter order adjusted after <code
class="notranslate">on*</code> handlers to account for upcoming
experimental APIs</li>
</ul>
<h2 dir="auto">eslint-plugin-react-hooks@6.1.0</h2>
<p dir="auto"><strong>Note:</strong> Version 6.0.0 was mistakenly
released and immediately deprecated and untagged on npm. This is the
first official 6.x major release and includes breaking changes.</p>
<ul dir="auto">
<li>
<strong>Breaking:</strong> Require Node.js 18 or newer. (<a
href="https://bounce.depfu.com/github.com/michaelfaith">@michaelfaith</a>
in <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32458">#32458</a>)</li>
<li>
<strong>Breaking:</strong> Flat config is now the default <code
class="notranslate">recommended</code> preset. Legacy config moved to
<code class="notranslate">recommended-legacy</code>. (<a
href="https://bounce.depfu.com/github.com/michaelfaith">@michaelfaith</a>
in <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32457">#32457</a>)</li>
<li>
<strong>New Violations:</strong> Disallow calling <code
class="notranslate">use</code> within try/catch blocks. (<a
href="https://bounce.depfu.com/github.com/poteto">@poteto</a> in <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34040">#34040</a>)</li>
<li>
<strong>New Violations:</strong> Disallow calling <code
class="notranslate">useEffectEvent</code> functions in arbitrary
closures. (<a
href="https://bounce.depfu.com/github.com/jbrown215">@jbrown215</a> in
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33544">#33544</a>)</li>
<li>Handle <code class="notranslate">React.useEffect</code> in addition
to <code class="notranslate">useEffect</code> in rules-of-hooks. (<a
href="https://bounce.depfu.com/github.com/Ayc0">@Ayc0</a> in <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34076">#34076</a>)</li>
<li>Added <code class="notranslate">react-hooks</code> settings config
option that to accept <code
class="notranslate">additionalEffectHooks</code> that are used across
exhaustive-deps and rules-of-hooks rules. (<a
href="https://bounce.depfu.com/github.com/jbrown215">@jbrown215</a>) in
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34497">#34497</a>
</li>
</ul></blockquote>
<p><em>Does any of this look wrong? <a
href="https://depfu.com/packages/npm/react/feedback">Please let us
know.</a></em></p>
</details>
<details>
<summary>Commits</summary>
<p><a
href="https://github.com/facebook/react/compare/02ef49580922f87180f32618b9d1c70b75b968b7...ae74234eae6ebd62f19190731278e20bc1c37d51">See
the full diff on Github</a>. The new version differs by more commits
than we can show here.</p>
</details>
#### ✳️ react-dom (19.1.1 → 19.2.0) ·
[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.0">19.2.0</a></h4>
<blockquote><p dir="auto">Below is a list of all new features, APIs, and
bug fixes.</p>
<p dir="auto">Read the <a
href="https://react.dev/blog/2025/10/01/react-19-2">React 19.2 release
post</a> for more information.</p>
<h2 dir="auto">New React Features</h2>
<ul dir="auto">
<li>
<a href="https://react.dev/reference/react/Activity"><code
class="notranslate"><Activity></code></a>: A new API to hide and
restore the UI and internal state of its children.</li>
<li>
<a href="https://react.dev/reference/react/useEffectEvent"><code
class="notranslate">useEffectEvent</code></a> is a React Hook that lets
you extract non-reactive logic into an <a
href="https://react.dev/learn/separating-events-from-effects#declaring-an-effect-event">Effect
Event</a>.</li>
<li>
<a href="https://react.dev/reference/react/cacheSignal"><code
class="notranslate">cacheSignal</code></a> (for RSCs) lets your know
when the <code class="notranslate">cache()</code> lifetime is over.</li>
<li>
<a
href="https://react.dev/reference/developer-tooling/react-performance-tracks">React
Performance tracks</a> appear on the Performance panel’s timeline in
your browser developer tools</li>
</ul>
<h2 dir="auto">New React DOM Features</h2>
<ul dir="auto">
<li>Added resume APIs for partial pre-rendering with Web Streams:
<ul dir="auto">
<li>
<a href="https://react.dev/reference/react-dom/server/resume"><code
class="notranslate">resume</code></a>: to resume a prerender to a
stream.</li>
<li>
<a
href="https://react.dev/reference/react-dom/static/resumeAndPrerender"><code
class="notranslate">resumeAndPrerender</code></a>: to resume a prerender
to HTML.</li>
</ul>
</li>
<li>Added resume APIs for partial pre-rendering with Node Streams:
<ul dir="auto">
<li>
<a
href="https://react.dev/reference/react-dom/server/resumeToPipeableStream"><code
class="notranslate">resumeToPipeableStream</code></a>: to resume a
prerender to a stream.</li>
<li>
<a
href="https://react.dev/reference/react-dom/static/resumeAndPrerenderToNodeStream"><code
class="notranslate">resumeAndPrerenderToNodeStream</code></a>: to resume
a prerender to HTML.</li>
</ul>
</li>
<li>Updated <a
href="https://react.dev/reference/react-dom/static/prerender"><code
class="notranslate">prerender</code></a> APIs to return a <code
class="notranslate">postponed</code> state that can be passed to the
<code class="notranslate">resume</code> APIs.</li>
</ul>
<h2 dir="auto">Notable changes</h2>
<ul dir="auto">
<li>React DOM now batches suspense boundary reveals, matching the
behavior of client side rendering. This change is especially noticeable
when animating the reveal of Suspense boundaries e.g. with the upcoming
<code class="notranslate"><ViewTransition></code> Component. React
will batch as much reveals as possible before the first paint while
trying to hit popular first-contentful paint metrics.</li>
<li>Add Node Web Streams (<code class="notranslate">prerender</code>,
<code class="notranslate">renderToReadableStream</code>) to
server-side-rendering APIs for Node.js</li>
<li>Use underscore instead of <code class="notranslate">:</code> IDs
generated by useId</li>
</ul>
<h2 dir="auto">All Changes</h2>
<h3 dir="auto">React</h3>
<ul dir="auto">
<li>
<code class="notranslate"><Activity /></code> was developed over
many years, starting before <code
class="notranslate">ClassComponent.setState</code> (<a
href="https://bounce.depfu.com/github.com/acdlite">@acdlite</a> <a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
and many others)</li>
<li>Stringify context as "SomeContext" instead of "SomeContext.Provider"
(<a href="https://bounce.depfu.com/github.com/kassens">@kassens</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33507">#33507</a>)</li>
<li>Include stack of cause of React instrumentation errors with <code
class="notranslate">%o</code> placeholder (<a
href="https://bounce.depfu.com/github.com/eps1lon">@eps1lon</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34198">#34198</a>)</li>
<li>Fix infinite <code class="notranslate">useDeferredValue</code> loop
in popstate event (<a
href="https://bounce.depfu.com/github.com/acdlite">@acdlite</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32821">#32821</a>)</li>
<li>Fix a bug when an initial value was passed to <code
class="notranslate">useDeferredValue</code> (<a
href="https://bounce.depfu.com/github.com/acdlite">@acdlite</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34376">#34376</a>)</li>
<li>Fix a crash when submitting forms with Client Actions (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33055">#33055</a>)</li>
<li>Hide/unhide the content of dehydrated suspense boundaries if they
resuspend (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32900">#32900</a>)</li>
<li>Avoid stack overflow on wide trees during Hot Reload (<a
href="https://bounce.depfu.com/github.com/sophiebits">@sophiebits</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34145">#34145</a>)</li>
<li>Improve Owner and Component stacks in various places (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>,
<a href="https://bounce.depfu.com/github.com/eps1lon">@eps1lon</a>: <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33629">#33629</a>,
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33724">#33724</a>,
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32735">#32735</a>,
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33723">#33723</a>)</li>
<li>Add <code class="notranslate">cacheSignal</code> (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33557">#33557</a>)</li>
</ul>
<h3 dir="auto">React DOM</h3>
<ul dir="auto">
<li>Block on Suspensey Fonts during reveal of server-side-rendered
content (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33342">#33342</a>)</li>
<li>Use underscore instead of <code class="notranslate">:</code> for IDs
generated by <code class="notranslate">useId</code> (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>,
<a href="https://bounce.depfu.com/github.com/eps1lon">@eps1lon</a>: <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32001">#32001</a>,
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33342">#33342</a><a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33099">#33099</a>,
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33422">#33422</a>)</li>
<li>Stop warning when ARIA 1.3 attributes are used (<a
href="https://bounce.depfu.com/github.com/Abdul-Omira">@Abdul-Omira</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34264">#34264</a>)</li>
<li>Allow <code class="notranslate">nonce</code> to be used on hoistable
styles (<a
href="https://bounce.depfu.com/github.com/Andarist">@Andarist</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32461">#32461</a>)</li>
<li>Warn for using a React owned node as a Container if it also has text
content (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32774">#32774</a>)</li>
<li>s/HTML/text for for error messages if text hydration mismatches (<a
href="https://bounce.depfu.com/github.com/rickhanlonii">@rickhanlonii</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32763">#32763</a>)</li>
<li>Fix a bug with <code class="notranslate">React.use</code> inside
<code class="notranslate">React.lazy</code>-ed Component (<a
href="https://bounce.depfu.com/github.com/hi-ogawa">@hi-ogawa</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33941">#33941</a>)</li>
<li>Enable the <code class="notranslate">progressiveChunkSize</code>
option for server-side-rendering APIs (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33027">#33027</a>)</li>
<li>Fix a bug with deeply nested Suspense inside Suspense fallback when
server-side-rendering (<a
href="https://bounce.depfu.com/github.com/gnoff">@gnoff</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33467">#33467</a>)</li>
<li>Avoid hanging when suspending after aborting while rendering (<a
href="https://bounce.depfu.com/github.com/gnoff">@gnoff</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34192">#34192</a>)</li>
<li>Add Node Web Streams to server-side-rendering APIs for Node.js (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33475">#33475</a>)</li>
</ul>
<h3 dir="auto">React Server Components</h3>
<ul dir="auto">
<li>Preload <code class="notranslate"><img></code> and <code
class="notranslate"><link></code> using hints before they're
rendered (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34604">#34604</a>)</li>
<li>Log error if production elements are rendered during development (<a
href="https://bounce.depfu.com/github.com/eps1lon">@eps1lon</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34189">#34189</a>)</li>
<li>Fix a bug when returning a Temporary reference (e.g. a Client
Reference) from Server Functions (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34084">#34084</a>,
<a href="https://bounce.depfu.com/github.com/denk0403">@denk0403</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33761">#33761</a>)</li>
<li>Pass line/column to <code
class="notranslate">filterStackFrame</code> (<a
href="https://bounce.depfu.com/github.com/eps1lon">@eps1lon</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33707">#33707</a>)</li>
<li>Support Async Modules in Turbopack Server References (<a
href="https://bounce.depfu.com/github.com/lubieowoce">@lubieowoce</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34531">#34531</a>)</li>
<li>Add support for .mjs file extension in Webpack (<a
href="https://bounce.depfu.com/github.com/jennyscript">@jennyscript</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33028">#33028</a>)</li>
<li>Fix a wrong missing key warning (<a
href="https://bounce.depfu.com/github.com/unstubbable">@unstubbable</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34350">#34350</a>)</li>
<li>Make console log resolve in predictable order (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33665">#33665</a>)</li>
</ul>
<h3 dir="auto">React Reconciler</h3>
<ul dir="auto">
<li>
<a
href="https://bounce.depfu.com/github.com/facebook/react/blob/v19.2.0/packages/react-reconciler/src/ReactFiberReconciler.js#L255-L261">createContainer</a>
and <a
href="https://bounce.depfu.com/github.com/facebook/react/blob/v19.2.0/packages/react-reconciler/src/ReactFiberReconciler.js#L305-L312">createHydrationContainer</a>
had their parameter order adjusted after <code
class="notranslate">on*</code> handlers to account for upcoming
experimental APIs</li>
</ul>
<h2 dir="auto">eslint-plugin-react-hooks@6.1.0</h2>
<p dir="auto"><strong>Note:</strong> Version 6.0.0 was mistakenly
released and immediately deprecated and untagged on npm. This is the
first official 6.x major release and includes breaking changes.</p>
<ul dir="auto">
<li>
<strong>Breaking:</strong> Require Node.js 18 or newer. (<a
href="https://bounce.depfu.com/github.com/michaelfaith">@michaelfaith</a>
in <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32458">#32458</a>)</li>
<li>
<strong>Breaking:</strong> Flat config is now the default <code
class="notranslate">recommended</code> preset. Legacy config moved to
<code class="notranslate">recommended-legacy</code>. (<a
href="https://bounce.depfu.com/github.com/michaelfaith">@michaelfaith</a>
in <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32457">#32457</a>)</li>
<li>
<strong>New Violations:</strong> Disallow calling <code
class="notranslate">use</code> within try/catch blocks. (<a
href="https://bounce.depfu.com/github.com/poteto">@poteto</a> in <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34040">#34040</a>)</li>
<li>
<strong>New Violations:</strong> Disallow calling <code
class="notranslate">useEffectEvent</code> functions in arbitrary
closures. (<a
href="https://bounce.depfu.com/github.com/jbrown215">@jbrown215</a> in
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33544">#33544</a>)</li>
<li>Handle <code class="notranslate">React.useEffect</code> in addition
to <code class="notranslate">useEffect</code> in rules-of-hooks. (<a
href="https://bounce.depfu.com/github.com/Ayc0">@Ayc0</a> in <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34076">#34076</a>)</li>
<li>Added <code class="notranslate">react-hooks</code> settings config
option that to accept <code
class="notranslate">additionalEffectHooks</code> that are used across
exhaustive-deps and rules-of-hooks rules. (<a
href="https://bounce.depfu.com/github.com/jbrown215">@jbrown215</a>) in
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34497">#34497</a>
</li>
</ul></blockquote>
<p><em>Does any of this look wrong? <a
href="https://depfu.com/packages/npm/react-dom/feedback">Please let us
know.</a></em></p>
</details>
<details>
<summary>Commits</summary>
<p><a
href="https://github.com/facebook/react/compare/02ef49580922f87180f32618b9d1c70b75b968b7...ae74234eae6ebd62f19190731278e20bc1c37d51">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>
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2025-10-09 14:33:23 -04:00
|
|
|
scheduler@0.27.0:
|
|
|
|
|
resolution: {integrity: sha512-eNv+WrVbKu1f3vbYJT/xtiF5syA5HPIMtf9IgY/nKg0sWqzAUEvqY/xm7OcZc/qafLx/iO9FgOmeSAp4v5ti/Q==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
schema-utils@4.3.3:
|
|
|
|
|
resolution: {integrity: sha512-eflK8wEtyOE6+hsaRVPxvUKYCpRgzLqDTb8krvAsRIwOGlHoSgYLgBXoubGgLd2fT41/OUYdb48v4k4WWHQurA==}
|
|
|
|
|
engines: {node: '>= 10.13.0'}
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
semver@7.8.5:
|
|
|
|
|
resolution: {integrity: sha512-Y7/KDsb8LjooZpwaqGyulO6DQlksgCncchHGk+sZIY4SBvUocMBEFH5Ur1fI4dV+Jvl0w6cjvucaIi40puRioA==}
|
2026-06-19 13:11:16 +02:00
|
|
|
engines: {node: '>=10'}
|
|
|
|
|
hasBin: true
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
sharp@0.34.5:
|
|
|
|
|
resolution: {integrity: sha512-Ou9I5Ft9WNcCbXrU9cMgPBcCK8LiwLqcbywW3t4oDV37n1pzpuNLsYiAV8eODnjbtQlSDwZ2cUEeQz4E54Hltg==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
|
2024-11-26 18:31:12 +01:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
siginfo@2.0.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-ybx0WO1/8bSBLEWXZvEd7gMW3Sn3JFlW3TvX1nREbDLRNQNaeNN8WK0meBwPdAaOI7TtRRRJn/Es1zhrrCHu7g==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
|
|
|
|
signal-exit@4.1.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-bzyZ1e88w9O1iNJbKnOlvYTrWPDl46O1bG0D3XInv+9tkPrxrN8jUUTiFlDkkmKWgn1M6CfIA13SuGqOa9Korw==}
|
|
|
|
|
engines: {node: '>=14'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2024-09-18 16:45:43 +02:00
|
|
|
slash@5.1.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-ZA6oR3T/pEyuqwMgAKT0/hAv8oAXckzbkmR0UkUosQ+Mc4RxGoJkRmwHgHufaenlyAgE1Mxgpdcrf75y6XcnDg==}
|
|
|
|
|
engines: {node: '>=14.16'}
|
2024-09-18 16:45:43 +02:00
|
|
|
|
2024-10-03 11:15:18 +02:00
|
|
|
source-map-js@1.2.1:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-UXWMKhLOwVKb728IUtQPXxfYU+usdybtUrK/8uGE8CQMvrhOpwvzDBwj0QhSL7MQc7vIsISBG8VQ8+IDQxpfQA==}
|
|
|
|
|
engines: {node: '>=0.10.0'}
|
2024-10-03 11:15:18 +02:00
|
|
|
|
2024-09-04 10:09:24 +02:00
|
|
|
source-map-support@0.5.21:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-uBHU3L3czsIyYXKX88fdrGovxdSCoTGDRZ6SYXtSRxLZUzHg5P/66Ht6uoUlHu9EZod+inXhKo3qQgwXUT/y1w==}
|
2024-09-04 10:09:24 +02:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
source-map@0.6.1:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-UjgapumWlbMhkBgzT7Ykc5YXUT46F0iKu8SGXq0bcwP5dz/h0Plj6enJqjz1Zbq2l5WaqYnrVbwWOWMyF3F47g==}
|
|
|
|
|
engines: {node: '>=0.10.0'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2025-11-19 18:18:45 -05:00
|
|
|
source-map@0.7.6:
|
|
|
|
|
resolution: {integrity: sha512-i5uvt8C3ikiWeNZSVZNWcfZPItFQOsYTUAOkcUPGd8DqDy1uOUikjt5dG+uRlwyvR108Fb9DOd4GvXfT0N2/uQ==}
|
|
|
|
|
engines: {node: '>= 12'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
|
|
|
|
stackback@0.0.2:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-1XMJE5fQo1jGH6Y/7ebnwPOBEkIEnT4QF32d5R1+VXdXveM0IBMJt8zfaxX1P3QhVwrYe+576+jkANtSS2mBbw==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
std-env@4.1.0:
|
|
|
|
|
resolution: {integrity: sha512-Rq7ybcX2RuC55r9oaPVEW7/xu3tj8u4GeBYHBWCychFtzMIr86A7e3PPEBPT37sHStKX3+TiX/Fr/ACmJLVlLQ==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
std-env@4.2.0:
|
|
|
|
|
resolution: {integrity: sha512-oCUKSupKTHX53EyjDtuZQ64pjLJ6yYCtpmEw0goYxtjG9KpbRe8KAsl2tBUGU9DyMcJ0RwJ8GqJAFzMXcXW1Rw==}
|
|
|
|
|
|
2024-11-26 18:31:12 +01:00
|
|
|
styled-jsx@5.1.6:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-qSVyDTeMotdvQYoHWLNGwRFJHC+i+ZvdBRYosOFgC+Wg1vx4frN2/RG/NA7SYqqvKNLf39P2LSRA2pu6n0XYZA==}
|
|
|
|
|
engines: {node: '>= 12.0.0'}
|
2024-05-24 15:07:44 +02:00
|
|
|
peerDependencies:
|
|
|
|
|
'@babel/core': '*'
|
|
|
|
|
babel-plugin-macros: '*'
|
2024-11-26 18:31:12 +01:00
|
|
|
react: '>= 16.8.0 || 17.x.x || ^18.0.0-0 || ^19.0.0-0'
|
2024-05-24 15:07:44 +02:00
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@babel/core':
|
|
|
|
|
optional: true
|
|
|
|
|
babel-plugin-macros:
|
|
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
sucrase@3.35.1:
|
|
|
|
|
resolution: {integrity: sha512-DhuTmvZWux4H1UOnWMB3sk0sbaCVOoQZjv8u1rDoTV0HTdGem9hkAZtl4JZy8P2z4Bg0nT+YMeOFyVr4zcG5Tw==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=16 || 14 >=14.17'}
|
2024-05-24 15:07:44 +02:00
|
|
|
hasBin: true
|
|
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
supports-color@8.1.1:
|
|
|
|
|
resolution: {integrity: sha512-MpUEN2OodtUzxvKQl72cUF7RQ5EiHsGvSsVG0ia9c5RbWGL2CI4C7EpPS8UTBIplnlzZiNuV56w+FuNxy3ty2Q==}
|
|
|
|
|
engines: {node: '>=10'}
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
supports-preserve-symlinks-flag@1.0.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-ot0WnXS9fgdkgIcePe6RHNk1WA8+muPa6cSjeR3V8K27q9BB1rTE3R1p7Hv0z1ZyAc8s6Vvv8DIyWf681MAt0w==}
|
|
|
|
|
engines: {node: '>= 0.4'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2025-12-26 12:36:51 -05:00
|
|
|
tagged-tag@1.0.0:
|
|
|
|
|
resolution: {integrity: sha512-yEFYrVhod+hdNyx7g5Bnkkb0G6si8HJurOoOEgC8B/O0uXLHlaey/65KRv6cuWBNhBgHKAROVpc7QyYqE5gFng==}
|
|
|
|
|
engines: {node: '>=20'}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
tailwindcss@3.4.19:
|
|
|
|
|
resolution: {integrity: sha512-3ofp+LL8E+pK/JuPLPggVAIaEuhvIz4qNcf3nA1Xn2o/7fb7s/TYpHhwGDv1ZU3PkBluUVaF8PyCHcm48cKLWQ==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=14.0.0'}
|
2024-10-24 11:00:25 -04:00
|
|
|
hasBin: true
|
|
|
|
|
|
Update enhanced-resolve 5.20.1 → 5.21.0 (minor) (#19998)
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="https://depfu.com/packages/npm/enhanced-resolve/feedback">Please
let us know.</a></em></p>
</details>
<details>
<summary>Commits</summary>
<p><a
href="https://github.com/webpack/enhanced-resolve/compare/ebc67d38969e8abe6789a51968380fa721fea778...35035ca158f1c8ada86fcf1653f319cbce669200">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>
2026-05-01 11:29:19 +00:00
|
|
|
tapable@2.3.3:
|
|
|
|
|
resolution: {integrity: sha512-uxc/zpqFg6x7C8vOE7lh6Lbda8eEL9zmVm/PLeTPBRhh1xCgdWaQ+J1CUieGpIfm2HdtsUpRv+HshiasBMcc6A==}
|
|
|
|
|
engines: {node: '>=6'}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
terser@5.48.0:
|
|
|
|
|
resolution: {integrity: sha512-J/9An6vs9Us6wKRriSFXBWdRZapREHqFzdNUKk0pmu804EMR6dr6winwo7e5JDxN4xahxQsuysyYFwlwj4XN/Q==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=10'}
|
2024-09-04 10:09:24 +02:00
|
|
|
hasBin: true
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
thenify-all@1.6.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-RNxQH/qI8/t3thXJDwcstUO4zeqo64+Uy/+sNVRBx4Xn2OX+OZ9oP+iJnNFqplFra2ZUVeKCSa2oVWi3T4uVmA==}
|
|
|
|
|
engines: {node: '>=0.8'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
|
|
|
|
thenify@3.3.1:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-RVZSIV5IG10Hk3enotrhvz0T9em6cyHBLkH/YAZuKqd8hRkKhSfCGIcP2KUY0EPxndzANBmNllzWPwak+bheSw==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2025-03-03 13:22:51 +01:00
|
|
|
tiny-jsonc@1.0.2:
|
|
|
|
|
resolution: {integrity: sha512-f5QDAfLq6zIVSyCZQZhhyl0QS6MvAyTxgz4X4x3+EoCktNWEYJ6PeoEA97fyb98njpBNNi88ybpD7m+BDFXaCw==}
|
Add integration test setup and tests for the Vite integration (#14089)
This PR adds a new root `/integrations` folder that will be the home of
integration tests. The idea of these tests is to use Tailwind in various
setups just like our users would (by only using the publishable npm
builds).
To avoid issues with concurrent tests making changes to the file system,
to make it very easy to test through a range of versions, and to avoid
changing configuration objects over and over in test runs, we decided to
inline the scaffolding completely into the test file and have no
examples checked into the repo.
Here's an example of how this can look like for a simple Vite test:
```ts
test('works with production builds', {
fs: {
'package.json': json`
{
"type": "module",
"dependencies": {
"@tailwindcss/vite": "workspace:^",
"tailwindcss": "workspace:^"
},
"devDependencies": {
"vite": "^5.3.5"
}
}
`,
'vite.config.ts': ts`
import tailwindcss from '@tailwindcss/vite'
import { defineConfig } from 'vite'
export default defineConfig({
build: { cssMinify: false },
plugins: [tailwindcss()],
})
`,
'index.html': html`
<head>
<link rel="stylesheet" href="./src/index.css">
</head>
<body>
<div class="underline m-2">Hello, world!</div>
</body>
`,
'src/index.css': css`
@import 'tailwindcss/theme' reference;
@import 'tailwindcss/utilities';
`,
},
},
async ({ fs, exec }) => {
await exec('pnpm vite build')
expect.assertions(2)
for (let [path, content] of await fs.glob('dist/**/*.css')) {
expect(path).toMatch(/\.css$/)
expect(stripTailwindComment(content)).toMatchInlineSnapshot(
`
".m-2 {
margin: var(--spacing-2, .5rem);
}
.underline {
text-decoration-line: underline;
}"
`,
)
}
},
)
```
By defining all dependencies this way, we never have to worry about
which fixtures are checked in and can more easily describe changes to
the setup.
For ergonomics, we've also added the [`embed` prettier
plugin](https://github.com/Sec-ant/prettier-plugin-embed). This will
mean that files inlined in the `fs` setup are properly indented. No
extra work needed!
If you're using VS Code, I can also recommend the [Language
Literals](https://marketplace.visualstudio.com/items?itemName=sissel.language-literals)
extension so that syntax highlighting also _just works_.
A neat feature of inlining the scaffolding like this is to make it very
simple to test through a variety of versions. For example, here's how we
can set up a test against Vite 5 and Vite 4:
```js
;['^4.5.3', '^5.3.5'].forEach(viteVersion => {
test(`works with production builds for Vite ${viteVersion}`, {
fs: {
'package.json': json`
{
"type": "module",
"devDependencies": {
"vite": "${viteVersion}"
}
}
`,
async () => {
// Do something
},
)
})
```
## Philosophy
Before we dive into the specifics, I want to clearly state the design
considerations we have chosen for this new test suite:
- All file mutations should be done in temp folders, nothing should ever
mess with your working directory
- Windows as a first-class citizen
- Have a clean and simple API that describes the test setup only using
public APIs
- Focus on reliability (make sure cleanup scripts work and are tolerant
to various error scenarios)
- If a user reports an issue with a specific configuration, we want to
be able to reproduce them with integration tests, no matter how obscure
the setup (this means the test need to be in control of most of the
variables)
- Tests should be reasonably fast (obviously this depends on the
integration. If we use a slow build tool, we can't magically speed it
up, but our overhead should be minimal).
## How it works
The current implementation provides a custom `test` helper function
that, when used, sets up the environment according to the configuration.
It'll create a new temporary directory and create all files, ensuring
things like proper `\r\n` line endings on Windows.
We do have to patch the `package.json` specifically, since we can not
use public versions of the tailwindcss packages as we want to be able to
test against a development build. To make this happen, every `pnpm
build` run now creates tarballs of the npm modules (that contain only
the files that would also in the published build). We then patch the
`package.json` to rewrite `workspace:^` versions to link to those
tarballs. We found this to work reliably on Windows and macOS as well as
being fast enough to not cause any issues. Furthermore we also decided
to use `pnpm` as the version manager for integration tests because of
it's global module cache (so installing `vite` is fast as soon as you
installed it once).
The test function will receive a few utilities that it can use to more
easily interact with the temp dir. One example is a `fs.glob` function
that you can use to easily find files in eventual `dist/` directories or
helpers around `spawn` and `exec` that make sure that processes are
cleaned up correctly.
Because we use tarballs from our build dependencies, working on changes
requires a workflow where you run `pnpm build` before running `pnpm
test:integrations`. However it also means we can run clients like our
CLI client with no additional overhead—just install the dependency like
any user would and set up your test cases this way.
## Test plan
This PR also includes two Vite specific integration tests: One testing a
static build (`pnpm vite build`) and one a dev mode build (`pnpm vite
dev`) that also makes changes to the file system and asserts that the
resources properly update.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-08-02 11:50:49 +02:00
|
|
|
|
2024-08-09 16:12:24 +02:00
|
|
|
tinybench@2.9.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-0+DUvqWMValLmha6lr4kD8iAMK1HzV0/aKnCtWb9v9641TnP/MFb7Pc2bxoxQjTXAErryXVgUOfv2YqNllqGeg==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
tinyclip@0.1.15:
|
|
|
|
|
resolution: {integrity: sha512-uo33abH+Ays0xYaDysoBt494Hb3hsEczMpcC0MwFl773pazORx4fmvKhclhR1wonUbB6vvpRsvVMwnhfqeMc+A==}
|
2026-04-24 21:21:12 +02:00
|
|
|
engines: {node: ^16.14.0 || >= 17.3.0}
|
|
|
|
|
|
2025-02-03 11:20:51 +01:00
|
|
|
tinyexec@0.3.2:
|
|
|
|
|
resolution: {integrity: sha512-KQQR9yN7R5+OSwaK0XQoj22pwHoTlgYqmUscPYoknOoWCWfj/5/ABTMRi69FrKU5ffPVh5QcFikpWJI/P1ocHA==}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
tinyexec@1.1.2:
|
|
|
|
|
resolution: {integrity: sha512-dAqSqE/RabpBKI8+h26GfLq6Vb3JVXs30XYQjdMjaj/c2tS8IYYMbIzP599KtRj7c57/wYApb3QjgRgXmrCukA==}
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
engines: {node: '>=18'}
|
|
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
tinyglobby@0.2.16:
|
|
|
|
|
resolution: {integrity: sha512-pn99VhoACYR8nFHhxqix+uvsbXineAasWm5ojXoN8xEwK5Kd3/TrhNn1wByuD52UxWRLy8pu+kRMniEi6Eq9Zg==}
|
|
|
|
|
engines: {node: '>=12.0.0'}
|
|
|
|
|
|
2026-07-02 11:45:49 +02:00
|
|
|
tinyglobby@0.2.17:
|
|
|
|
|
resolution: {integrity: sha512-wXR/dYpcqKmfWpEdZjiKJOwCNFndD0DMnrW/cYjVGttEkBfVgcLFHoNrlj47mjOVic9yyNu65alsgF4NQyTa2g==}
|
|
|
|
|
engines: {node: '>=12.0.0'}
|
|
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
tinyrainbow@3.1.0:
|
|
|
|
|
resolution: {integrity: sha512-Bf+ILmBgretUrdJxzXM0SgXLZ3XfiaUuOj/IKQHuTXip+05Xn+uyEYdVg0kYDipTBcLrCVyUzAPz7QmArb0mmw==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=14.0.0'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
|
|
|
|
to-regex-range@5.0.1:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ==}
|
|
|
|
|
engines: {node: '>=8.0'}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
|
|
|
|
tree-kill@1.2.2:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-L0Orpi8qGpRG//Nd+H90vFB+3iHnue1zSSGmNOOCh1GLJ7rUKVwV2HvijphGQS2UmhUZewS9VgvxYIdgr+fG1A==}
|
2024-05-24 15:07:44 +02:00
|
|
|
hasBin: true
|
|
|
|
|
|
2024-11-18 10:23:22 +01:00
|
|
|
tree-sitter-javascript@0.23.1:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-/bnhbrTD9frUYHQTiYnPcxyHORIw157ERBa6dqzaKxvR/x3PC4Yzd+D1pZIMS6zNg2v3a8BZ0oK7jHqsQo9fWA==}
|
2024-11-18 10:23:22 +01:00
|
|
|
peerDependencies:
|
|
|
|
|
tree-sitter: ^0.21.1
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
tree-sitter:
|
|
|
|
|
optional: true
|
|
|
|
|
|
|
|
|
|
tree-sitter-typescript@0.23.2:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-e04JUUKxTT53/x3Uq1zIL45DoYKVfHH4CZqwgZhPg5qYROl5nQjV+85ruFzFGZxu+QeFVbRTPDRnqL9UbU4VeA==}
|
2024-10-14 17:45:36 +02:00
|
|
|
peerDependencies:
|
|
|
|
|
tree-sitter: ^0.21.0
|
|
|
|
|
peerDependenciesMeta:
|
2024-11-18 10:23:22 +01:00
|
|
|
tree-sitter:
|
2024-10-14 17:45:36 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
tree-sitter@0.25.1:
|
|
|
|
|
resolution: {integrity: sha512-mrcEdkYtHfrK1A6fs3O6FxkBo0Qig5XUXqHhxUOQu0bmPo00QF4XaSx4edpazdHwxnSCjlGKGgIqWdaN4dvTLA==}
|
2024-10-14 17:45:36 +02:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
ts-interface-checker@0.1.13:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-Y/arvbn+rrz3JCKl9C4kVNfTfSm2/mEp5FSz5EsZSANGPSlQrpRI5M4PKF+mJnE52jOO90PnPSc3Ur3bTQw0gA==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
tslib@2.8.1:
|
|
|
|
|
resolution: {integrity: sha512-oJFu94HQb+KVduSUQL7wnpmqnfmLsOA/nAh6b6EH0wCEoK0/mPeXU6c3wKDV83MkOuHPRHtSXKKU99IBazS/2w==}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2025-11-19 18:18:45 -05:00
|
|
|
tsup@8.5.1:
|
|
|
|
|
resolution: {integrity: sha512-xtgkqwdhpKWr3tKPmCkvYmS9xnQK3m3XgxZHwSUjvfTjp7YfXe5tT3GgWi0F2N+ZSMsOeWeZFh7ZZFg5iPhing==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=18'}
|
2024-05-24 15:07:44 +02:00
|
|
|
hasBin: true
|
|
|
|
|
peerDependencies:
|
|
|
|
|
'@microsoft/api-extractor': ^7.36.0
|
|
|
|
|
'@swc/core': ^1
|
|
|
|
|
postcss: ^8.4.12
|
|
|
|
|
typescript: '>=4.5.0'
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@microsoft/api-extractor':
|
|
|
|
|
optional: true
|
|
|
|
|
'@swc/core':
|
|
|
|
|
optional: true
|
|
|
|
|
postcss:
|
|
|
|
|
optional: true
|
|
|
|
|
typescript:
|
|
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
turbo@2.10.8:
|
|
|
|
|
resolution: {integrity: sha512-9+8YX5QOkGXzZxcIykTHgaooRHGMWO+jfdyRK0o+rN0U7hBIig2MrJ8r/aNzIPDPhdA73SGb0O+tIztaModTMg==}
|
2024-05-24 15:07:44 +02:00
|
|
|
hasBin: true
|
|
|
|
|
|
2025-04-11 17:19:55 +02:00
|
|
|
typanion@3.14.0:
|
|
|
|
|
resolution: {integrity: sha512-ZW/lVMRabETuYCd9O9ZvMhAh8GslSqaUjxmK/JLPCh6l73CvLBiuXswj/+7LdnWOgYsQ130FqLzFz5aGT4I3Ug==}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
type-fest@5.6.0:
|
|
|
|
|
resolution: {integrity: sha512-8ZiHFm91orbSAe2PSAiSVBVko18pbhbiB3U9GglSzF/zCGkR+rxpHx6sEMCUm4kxY4LjDIUGgCfUMtwfZfjfUA==}
|
2025-12-26 12:36:51 -05:00
|
|
|
engines: {node: '>=20'}
|
Add integration test setup and tests for the Vite integration (#14089)
This PR adds a new root `/integrations` folder that will be the home of
integration tests. The idea of these tests is to use Tailwind in various
setups just like our users would (by only using the publishable npm
builds).
To avoid issues with concurrent tests making changes to the file system,
to make it very easy to test through a range of versions, and to avoid
changing configuration objects over and over in test runs, we decided to
inline the scaffolding completely into the test file and have no
examples checked into the repo.
Here's an example of how this can look like for a simple Vite test:
```ts
test('works with production builds', {
fs: {
'package.json': json`
{
"type": "module",
"dependencies": {
"@tailwindcss/vite": "workspace:^",
"tailwindcss": "workspace:^"
},
"devDependencies": {
"vite": "^5.3.5"
}
}
`,
'vite.config.ts': ts`
import tailwindcss from '@tailwindcss/vite'
import { defineConfig } from 'vite'
export default defineConfig({
build: { cssMinify: false },
plugins: [tailwindcss()],
})
`,
'index.html': html`
<head>
<link rel="stylesheet" href="./src/index.css">
</head>
<body>
<div class="underline m-2">Hello, world!</div>
</body>
`,
'src/index.css': css`
@import 'tailwindcss/theme' reference;
@import 'tailwindcss/utilities';
`,
},
},
async ({ fs, exec }) => {
await exec('pnpm vite build')
expect.assertions(2)
for (let [path, content] of await fs.glob('dist/**/*.css')) {
expect(path).toMatch(/\.css$/)
expect(stripTailwindComment(content)).toMatchInlineSnapshot(
`
".m-2 {
margin: var(--spacing-2, .5rem);
}
.underline {
text-decoration-line: underline;
}"
`,
)
}
},
)
```
By defining all dependencies this way, we never have to worry about
which fixtures are checked in and can more easily describe changes to
the setup.
For ergonomics, we've also added the [`embed` prettier
plugin](https://github.com/Sec-ant/prettier-plugin-embed). This will
mean that files inlined in the `fs` setup are properly indented. No
extra work needed!
If you're using VS Code, I can also recommend the [Language
Literals](https://marketplace.visualstudio.com/items?itemName=sissel.language-literals)
extension so that syntax highlighting also _just works_.
A neat feature of inlining the scaffolding like this is to make it very
simple to test through a variety of versions. For example, here's how we
can set up a test against Vite 5 and Vite 4:
```js
;['^4.5.3', '^5.3.5'].forEach(viteVersion => {
test(`works with production builds for Vite ${viteVersion}`, {
fs: {
'package.json': json`
{
"type": "module",
"devDependencies": {
"vite": "${viteVersion}"
}
}
`,
async () => {
// Do something
},
)
})
```
## Philosophy
Before we dive into the specifics, I want to clearly state the design
considerations we have chosen for this new test suite:
- All file mutations should be done in temp folders, nothing should ever
mess with your working directory
- Windows as a first-class citizen
- Have a clean and simple API that describes the test setup only using
public APIs
- Focus on reliability (make sure cleanup scripts work and are tolerant
to various error scenarios)
- If a user reports an issue with a specific configuration, we want to
be able to reproduce them with integration tests, no matter how obscure
the setup (this means the test need to be in control of most of the
variables)
- Tests should be reasonably fast (obviously this depends on the
integration. If we use a slow build tool, we can't magically speed it
up, but our overhead should be minimal).
## How it works
The current implementation provides a custom `test` helper function
that, when used, sets up the environment according to the configuration.
It'll create a new temporary directory and create all files, ensuring
things like proper `\r\n` line endings on Windows.
We do have to patch the `package.json` specifically, since we can not
use public versions of the tailwindcss packages as we want to be able to
test against a development build. To make this happen, every `pnpm
build` run now creates tarballs of the npm modules (that contain only
the files that would also in the published build). We then patch the
`package.json` to rewrite `workspace:^` versions to link to those
tarballs. We found this to work reliably on Windows and macOS as well as
being fast enough to not cause any issues. Furthermore we also decided
to use `pnpm` as the version manager for integration tests because of
it's global module cache (so installing `vite` is fast as soon as you
installed it once).
The test function will receive a few utilities that it can use to more
easily interact with the temp dir. One example is a `fs.glob` function
that you can use to easily find files in eventual `dist/` directories or
helpers around `spawn` and `exec` that make sure that processes are
cleaned up correctly.
Because we use tarballs from our build dependencies, working on changes
requires a workflow where you run `pnpm build` before running `pnpm
test:integrations`. However it also means we can run clients like our
CLI client with no additional overhead—just install the dependency like
any user would and set up your test cases this way.
## Test plan
This PR also includes two Vite specific integration tests: One testing a
static build (`pnpm vite build`) and one a dev mode build (`pnpm vite
dev`) that also makes changes to the file system and asserts that the
resources properly update.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-08-02 11:50:49 +02:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
typescript@5.9.3:
|
|
|
|
|
resolution: {integrity: sha512-jl1vZzPDinLr9eUt3J/t7V6FgNEw9QjvBPdysz9KfQDD41fQrC2Y4vKQdiaUpFT4bXlb1RHhLpp8wtm6M5TgSw==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=14.17'}
|
2024-05-24 15:07:44 +02:00
|
|
|
hasBin: true
|
|
|
|
|
|
2026-04-23 12:51:20 +02:00
|
|
|
typescript@6.0.3:
|
|
|
|
|
resolution: {integrity: sha512-y2TvuxSZPDyQakkFRPZHKFm+KKVqIisdg9/CZwm9ftvKXLP8NRWj38/ODjNbr43SsoXqNuAisEf1GdCxqWcdBw==}
|
2024-12-18 18:06:26 +00:00
|
|
|
engines: {node: '>=14.17'}
|
2024-10-24 11:00:25 -04:00
|
|
|
hasBin: true
|
|
|
|
|
|
2026-05-07 12:43:28 +00:00
|
|
|
ufo@1.6.4:
|
|
|
|
|
resolution: {integrity: sha512-JFNbkD1Svwe0KvGi8GOeLcP4kAWQ609twvCdcHxq1oSL8svv39ZuSvajcD8B+5D0eL4+s1Is2D/O6KN3qcTeRA==}
|
|
|
|
|
|
2025-01-07 09:57:34 -05:00
|
|
|
uncrypto@0.1.3:
|
|
|
|
|
resolution: {integrity: sha512-Ql87qFHB3s/De2ClA9e0gsnS6zXG27SkTiSJwjCc9MebbfapQfuPzumMIUMi38ezPZVNFcHI9sUIepeQfw8J8Q==}
|
|
|
|
|
|
2025-06-24 18:31:17 +02:00
|
|
|
undici-types@6.21.0:
|
|
|
|
|
resolution: {integrity: sha512-iwDZqg0QAGrg9Rav5H4n0M64c3mkR59cJ6wQp+7C4nI0gsmExaedaYLNO44eT4AtBBwjbTiGPMlt2Md0T9H9JQ==}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
undici-types@7.24.6:
|
|
|
|
|
resolution: {integrity: sha512-WRNW+sJgj5OBN4/0JpHFqtqzhpbnV0GuB+OozA9gCL7a993SmU+1JBZCzLNxYsbMfIeDL+lTsphD5jN5N+n0zg==}
|
|
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
unicorn-magic@0.4.0:
|
|
|
|
|
resolution: {integrity: sha512-wH590V9VNgYH9g3lH9wWjTrUoKsjLF6sGLjhR4sH1LWpLmCOH0Zf7PukhDA8BiS7KHe4oPNkcTHqYkj7SOGUOw==}
|
|
|
|
|
engines: {node: '>=20'}
|
2024-09-18 16:45:43 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
universal-user-agent@7.0.3:
|
|
|
|
|
resolution: {integrity: sha512-TmnEAEAsBJVZM/AADELsK76llnwcf9vMKuPz8JflO1frO8Lchitr0fNaN9d+Ap0BjKtqWqd/J17qeDnXh8CL2A==}
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
untun@0.2.2:
|
|
|
|
|
resolution: {integrity: sha512-+NnOJcSiEtYsVgJmXUzQbJeRAFXJC4yPJYuh6kF9B0Rm6zunXcs/3GZOTllyocSbUDIxD6Bj7e/4ATw7sph1Sw==}
|
2025-01-07 09:57:34 -05:00
|
|
|
hasBin: true
|
|
|
|
|
|
2025-12-22 22:59:07 -05:00
|
|
|
update-browserslist-db@1.2.3:
|
|
|
|
|
resolution: {integrity: sha512-Js0m9cx+qOgDxo0eMiFGEueWztz+d4+M3rGlmKPT+T4IS/jP4ylw3Nwpu6cpTTP8R1MAC1kF4VbdLt3ARf209w==}
|
|
|
|
|
hasBin: true
|
|
|
|
|
peerDependencies:
|
|
|
|
|
browserslist: '>= 4.21.0'
|
|
|
|
|
|
2026-05-07 12:43:28 +00:00
|
|
|
uqr@0.1.3:
|
|
|
|
|
resolution: {integrity: sha512-0rjE8iEJe4YmT9TOhwsZtqCMRLc5DXZUI2UEYUUg63ikBkqqE5EYWaI0etFe/5KUcmcYwLih2RND1kq+hrUJXA==}
|
2025-01-07 09:57:34 -05:00
|
|
|
|
Add CSS codemods for migrating `@layer utilities` (#14455)
This PR adds CSS codemods for migrating existing `@layer utilities` to
`@utility` directives.
This PR has the ability to migrate the following cases:
---
The most basic case is when you want to migrate a simple class to a
utility directive.
Input:
```css
@layer utilities {
.foo {
color: red;
}
.bar {
color: blue;
}
}
```
Output:
```css
@utility foo {
color: red;
}
@utility bar {
color: blue;
}
```
You'll notice that the class `foo` will be used as the utility name, the
declarations (and the rest of the body of the rule) will become the body
of the `@utility` definition.
---
In v3, every class in a selector will become a utility. To correctly
migrate this to `@utility` directives, we have to register each class in
the selector and generate `n` utilities.
We can use nesting syntax, and replace the current class with `&` to
ensure that the final result behaves the same.
Input:
```css
@layer utilities {
.foo .bar .baz {
color: red;
}
}
```
Output:
```css
@utility foo {
& .bar .baz {
color: red;
}
}
@utility bar {
.foo & .baz {
color: red;
}
}
@utility .baz {
.foo .bar & {
color: red;
}
}
```
In this case, it could be that you know that some of them will never be
used as a utility (e.g.: `hover:bar`), but then you can safely remove
them.
---
Even classes inside of `:has(…)` will become a utility. The only
exception to the rule is that we don't do it for `:not(…)`.
Input:
```css
@layer utilities {
.foo .bar:not(.qux):has(.baz) {
display: none;
}
}
```
Output:
```css
@utility foo {
& .bar:not(.qux):has(.baz) {
display: none;
}
}
@utility bar {
.foo &:not(.qux):has(.baz) {
display: none;
}
}
@utility baz {
.foo .bar:not(.qux):has(&) {
display: none;
}
}
```
Notice that there is no `@utility qux` because it was used inside of
`:not(…)`.
---
When classes are nested inside at-rules, then these classes will also
become utilities. However, the `@utility <name>` will be at the top and
the at-rules will live inside of it. If there are multiple classes
inside a shared at-rule, then the at-rule will be duplicated for each
class.
Let's look at an example to make it more clear:
Input:
```css
@layer utilities {
@media (min-width: 640px) {
.foo {
color: red;
}
.bar {
color: blue;
}
@media (min-width: 1024px) {
.baz {
color: green;
}
@media (min-width: 1280px) {
.qux {
color: yellow;
}
}
}
}
}
```
Output:
```css
@utility foo {
@media (min-width: 640px) {
color: red;
}
}
@utility bar {
@media (min-width: 640px) {
color: blue;
}
}
@utility baz {
@media (min-width: 640px) {
@media (min-width: 1024px) {
color: green;
}
}
}
@utility qux {
@media (min-width: 640px) {
@media (min-width: 1024px) {
@media (min-width: 1280px) {
color: yellow;
}
}
}
}
```
---
When classes result in multiple `@utility` directives with the same
name, then the definitions will be merged together.
Input:
```css
@layer utilities {
.no-scrollbar::-webkit-scrollbar {
display: none;
}
.no-scrollbar {
-ms-overflow-style: none;
scrollbar-width: none;
}
}
```
Intermediate representation:
```css
@utility no-scrollbar {
&::-webkit-scrollbar {
display: none;
}
}
@utility no-scrollbar {
-ms-overflow-style: none;
scrollbar-width: none;
}
```
Output:
```css
@utility no-scrollbar {
&::-webkit-scrollbar {
display: none;
}
-ms-overflow-style: none;
scrollbar-width: none
}
```
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-09-24 18:17:09 +02:00
|
|
|
util-deprecate@1.0.2:
|
2026-04-24 21:21:12 +02:00
|
|
|
resolution: {integrity: sha512-EPD5q1uXyFxJpCrLnCc1nHnq3gOa6DZBocAIiI2TaSCA7VCJ1UJDMagCzIkXNsUYfD1daK//LTEQ8xiIbrHtcw==}
|
2024-11-27 17:34:50 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
vite@8.2.0:
|
|
|
|
|
resolution: {integrity: sha512-pn+CFpM0lwDeKwmOq1ZaBK/9sjorZcgqxki6MbY/jPEVd9vichIlmlD4HmQ5wdP5EgqQCFRaACBxMC7uEGc6lQ==}
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
engines: {node: ^20.19.0 || >=22.12.0}
|
|
|
|
|
hasBin: true
|
|
|
|
|
peerDependencies:
|
|
|
|
|
'@types/node': ^20.19.0 || >=22.12.0
|
2026-08-04 13:55:03 +02:00
|
|
|
'@vitejs/devtools': ^0.4.0
|
2026-04-24 21:21:12 +02:00
|
|
|
esbuild: ^0.27.0 || ^0.28.0
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
jiti: '>=1.21.0'
|
|
|
|
|
less: ^4.0.0
|
|
|
|
|
sass: ^1.70.0
|
|
|
|
|
sass-embedded: ^1.70.0
|
|
|
|
|
stylus: '>=0.54.8'
|
|
|
|
|
sugarss: ^5.0.0
|
|
|
|
|
terser: ^5.16.0
|
|
|
|
|
tsx: ^4.8.1
|
|
|
|
|
yaml: ^2.4.2
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@types/node':
|
|
|
|
|
optional: true
|
2026-03-12 20:54:34 +01:00
|
|
|
'@vitejs/devtools':
|
|
|
|
|
optional: true
|
|
|
|
|
esbuild:
|
|
|
|
|
optional: true
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
jiti:
|
|
|
|
|
optional: true
|
|
|
|
|
less:
|
|
|
|
|
optional: true
|
|
|
|
|
sass:
|
|
|
|
|
optional: true
|
|
|
|
|
sass-embedded:
|
|
|
|
|
optional: true
|
|
|
|
|
stylus:
|
|
|
|
|
optional: true
|
|
|
|
|
sugarss:
|
|
|
|
|
optional: true
|
|
|
|
|
terser:
|
|
|
|
|
optional: true
|
|
|
|
|
tsx:
|
|
|
|
|
optional: true
|
|
|
|
|
yaml:
|
|
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
vitest@4.1.10:
|
|
|
|
|
resolution: {integrity: sha512-R9jUTe5S4Qb0HCd4TNqpC7oGcrMssMRGXLW80ubjWsW9VH5GF8y1Y0SFLY9AbqSk6nt0PnOx4H4WNJYZ13GUPw==}
|
2025-11-21 00:16:20 +01:00
|
|
|
engines: {node: ^20.0.0 || ^22.0.0 || >=24.0.0}
|
2024-05-24 15:07:44 +02:00
|
|
|
hasBin: true
|
|
|
|
|
peerDependencies:
|
|
|
|
|
'@edge-runtime/vm': '*'
|
2025-11-21 00:16:20 +01:00
|
|
|
'@opentelemetry/api': ^1.9.0
|
|
|
|
|
'@types/node': ^20.0.0 || ^22.0.0 || >=24.0.0
|
2026-08-04 13:55:03 +02:00
|
|
|
'@vitest/browser-playwright': 4.1.10
|
|
|
|
|
'@vitest/browser-preview': 4.1.10
|
|
|
|
|
'@vitest/browser-webdriverio': 4.1.10
|
|
|
|
|
'@vitest/coverage-istanbul': 4.1.10
|
|
|
|
|
'@vitest/coverage-v8': 4.1.10
|
|
|
|
|
'@vitest/ui': 4.1.10
|
2024-05-24 15:07:44 +02:00
|
|
|
happy-dom: '*'
|
|
|
|
|
jsdom: '*'
|
2026-04-24 21:21:12 +02:00
|
|
|
vite: ^6.0.0 || ^7.0.0 || ^8.0.0
|
2024-05-24 15:07:44 +02:00
|
|
|
peerDependenciesMeta:
|
|
|
|
|
'@edge-runtime/vm':
|
|
|
|
|
optional: true
|
2025-11-21 00:16:20 +01:00
|
|
|
'@opentelemetry/api':
|
|
|
|
|
optional: true
|
2024-05-24 15:07:44 +02:00
|
|
|
'@types/node':
|
|
|
|
|
optional: true
|
2025-11-21 00:16:20 +01:00
|
|
|
'@vitest/browser-playwright':
|
|
|
|
|
optional: true
|
|
|
|
|
'@vitest/browser-preview':
|
|
|
|
|
optional: true
|
|
|
|
|
'@vitest/browser-webdriverio':
|
2024-05-24 15:07:44 +02:00
|
|
|
optional: true
|
2026-04-24 21:21:12 +02:00
|
|
|
'@vitest/coverage-istanbul':
|
|
|
|
|
optional: true
|
|
|
|
|
'@vitest/coverage-v8':
|
|
|
|
|
optional: true
|
2024-05-24 15:07:44 +02:00
|
|
|
'@vitest/ui':
|
|
|
|
|
optional: true
|
|
|
|
|
happy-dom:
|
|
|
|
|
optional: true
|
|
|
|
|
jsdom:
|
|
|
|
|
optional: true
|
|
|
|
|
|
2026-07-02 11:45:49 +02:00
|
|
|
watchpack@2.5.2:
|
|
|
|
|
resolution: {integrity: sha512-6i/00NBjP4yGPs+caKSyRfpTF/8Torsu0MOW3mMzIbhgISFder8i7xbqgHlLMwJrdiN8ndBV3UA1/AfzPSr+jg==}
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
engines: {node: '>=10.13.0'}
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
webpack-sources@3.5.1:
|
|
|
|
|
resolution: {integrity: sha512-jyuiGJdtvY434z5bUZrjz67v76/ePNvFZTp9Mdz29IlH4+GPsgyGjiv0fKI+M7BdkU6ADjulUcKAd3tUK3WlEw==}
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
engines: {node: '>=10.13.0'}
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
webpack@5.109.2:
|
|
|
|
|
resolution: {integrity: sha512-U9/cvLzxObKNEZ9+TtdqrHM5/9z3lgl2c+c4BzbqGxFQvQvBAq87yql5A8pQ+rrMbS496MZJeF5enVBndIy2hw==}
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
engines: {node: '>=10.13.0'}
|
|
|
|
|
hasBin: true
|
|
|
|
|
peerDependencies:
|
|
|
|
|
webpack-cli: '*'
|
|
|
|
|
peerDependenciesMeta:
|
|
|
|
|
webpack-cli:
|
|
|
|
|
optional: true
|
|
|
|
|
|
2024-08-02 10:33:14 +02:00
|
|
|
why-is-node-running@2.3.0:
|
2024-12-18 18:06:26 +00:00
|
|
|
resolution: {integrity: sha512-hUrmaWBdVDcxvYqnyh09zunKzROWjbZTiNy8dBEjkS7ehEDQibXJ7XvlmtbwuTclUiIyN+CyXQD4Vmko8fNm8w==}
|
|
|
|
|
engines: {node: '>=8'}
|
2024-05-24 15:07:44 +02:00
|
|
|
hasBin: true
|
|
|
|
|
|
2026-06-25 19:14:10 +02:00
|
|
|
yaml@2.9.0:
|
|
|
|
|
resolution: {integrity: sha512-2AvhNX3mb8zd6Zy7INTtSpl1F15HW6Wnqj0srWlkKLcpYl/gMIMJiyuGq2KeI2YFxUPjdlB+3Lc10seMLtL4cA==}
|
|
|
|
|
engines: {node: '>= 14.6'}
|
|
|
|
|
hasBin: true
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
snapshots:
|
2024-12-18 18:06:26 +00:00
|
|
|
|
2024-10-03 16:21:54 +02:00
|
|
|
'@alloc/quick-lru@5.2.0': {}
|
|
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
'@emnapi/core@1.10.0':
|
|
|
|
|
dependencies:
|
|
|
|
|
'@emnapi/wasi-threads': 1.2.1
|
|
|
|
|
tslib: 2.8.1
|
2026-06-15 13:13:32 +00:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@emnapi/core@1.11.3':
|
|
|
|
|
dependencies:
|
|
|
|
|
'@emnapi/wasi-threads': 1.2.3
|
|
|
|
|
tslib: 2.8.1
|
|
|
|
|
|
|
|
|
|
'@emnapi/core@2.0.0-alpha.3':
|
2026-06-15 13:13:32 +00:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@emnapi/wasi-threads': 2.0.1
|
2026-06-15 13:13:32 +00:00
|
|
|
tslib: 2.8.1
|
2026-08-04 13:55:03 +02:00
|
|
|
optional: true
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
'@emnapi/runtime@1.10.0':
|
|
|
|
|
dependencies:
|
|
|
|
|
tslib: 2.8.1
|
2026-06-15 13:13:32 +00:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@emnapi/runtime@1.11.3':
|
2026-06-15 13:13:32 +00:00
|
|
|
dependencies:
|
|
|
|
|
tslib: 2.8.1
|
2025-07-25 07:07:46 -04:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@emnapi/runtime@2.0.0-alpha.3':
|
|
|
|
|
dependencies:
|
|
|
|
|
tslib: 2.8.1
|
|
|
|
|
optional: true
|
|
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
'@emnapi/wasi-threads@1.2.1':
|
|
|
|
|
dependencies:
|
|
|
|
|
tslib: 2.8.1
|
2026-06-15 13:13:32 +00:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@emnapi/wasi-threads@1.2.3':
|
2026-06-15 13:13:32 +00:00
|
|
|
dependencies:
|
|
|
|
|
tslib: 2.8.1
|
2024-11-13 11:38:43 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@emnapi/wasi-threads@2.0.1':
|
|
|
|
|
dependencies:
|
|
|
|
|
tslib: 2.8.1
|
|
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/aix-ppc64@0.27.7':
|
2024-11-13 11:38:43 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/android-arm64@0.27.7':
|
2025-11-19 18:18:45 -05:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/android-arm@0.27.7':
|
2024-11-13 11:38:43 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/android-x64@0.27.7':
|
2025-11-19 18:18:45 -05:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/darwin-arm64@0.27.7':
|
2024-11-13 11:38:43 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/darwin-x64@0.27.7':
|
2025-11-19 18:18:45 -05:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/freebsd-arm64@0.27.7':
|
2024-11-13 11:38:43 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/freebsd-x64@0.27.7':
|
2025-11-19 18:18:45 -05:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/linux-arm64@0.27.7':
|
2024-11-13 11:38:43 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/linux-arm@0.27.7':
|
2025-11-19 18:18:45 -05:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/linux-ia32@0.27.7':
|
2024-11-13 11:38:43 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/linux-loong64@0.27.7':
|
2025-11-19 18:18:45 -05:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/linux-mips64el@0.27.7':
|
2024-11-13 11:38:43 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/linux-ppc64@0.27.7':
|
2025-11-19 18:18:45 -05:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/linux-riscv64@0.27.7':
|
2024-11-13 11:38:43 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/linux-s390x@0.27.7':
|
2025-11-19 18:18:45 -05:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/linux-x64@0.27.7':
|
2024-11-13 11:38:43 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/netbsd-arm64@0.27.7':
|
2025-11-19 18:18:45 -05:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/netbsd-x64@0.27.7':
|
2024-11-13 11:38:43 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/openbsd-arm64@0.27.7':
|
2025-11-19 18:18:45 -05:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/openbsd-x64@0.27.7':
|
2024-11-13 11:38:43 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/openharmony-arm64@0.27.7':
|
2025-11-19 18:18:45 -05:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/sunos-x64@0.27.7':
|
2025-11-19 18:18:45 -05:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/win32-arm64@0.27.7':
|
2024-11-13 11:38:43 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/win32-ia32@0.27.7':
|
2025-11-19 18:18:45 -05:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/win32-x64@0.27.7':
|
2024-11-13 11:38:43 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@img/colour@1.1.0':
|
2026-04-03 21:07:27 +02:00
|
|
|
optional: true
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-04-03 21:07:27 +02:00
|
|
|
'@img/sharp-darwin-arm64@0.34.5':
|
|
|
|
|
optionalDependencies:
|
|
|
|
|
'@img/sharp-libvips-darwin-arm64': 1.2.4
|
|
|
|
|
optional: true
|
2024-11-27 11:49:43 +01:00
|
|
|
|
2026-04-03 21:07:27 +02:00
|
|
|
'@img/sharp-darwin-x64@0.34.5':
|
|
|
|
|
optionalDependencies:
|
|
|
|
|
'@img/sharp-libvips-darwin-x64': 1.2.4
|
|
|
|
|
optional: true
|
2024-10-16 14:45:07 +00:00
|
|
|
|
2026-04-03 21:07:27 +02:00
|
|
|
'@img/sharp-libvips-darwin-arm64@1.2.4':
|
|
|
|
|
optional: true
|
2024-11-26 18:31:12 +01:00
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-darwin-x64@1.2.4':
|
2024-11-26 18:31:12 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-linux-arm64@1.2.4':
|
2024-11-26 18:31:12 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-linux-arm@1.2.4':
|
2024-11-26 18:31:12 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-linux-ppc64@1.2.4':
|
2024-11-26 18:31:12 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-linux-riscv64@1.2.4':
|
2024-11-26 18:31:12 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-linux-s390x@1.2.4':
|
2024-11-26 18:31:12 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-linux-x64@1.2.4':
|
2024-11-26 18:31:12 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-linuxmusl-arm64@1.2.4':
|
2024-11-26 18:31:12 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-linuxmusl-x64@1.2.4':
|
2025-04-25 09:56:24 +00:00
|
|
|
optional: true
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-linux-arm64@0.34.5':
|
2024-11-26 18:31:12 +01:00
|
|
|
optionalDependencies:
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-linux-arm64': 1.2.4
|
2024-11-26 18:31:12 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-linux-arm@0.34.5':
|
2024-11-26 18:31:12 +01:00
|
|
|
optionalDependencies:
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-linux-arm': 1.2.4
|
2024-11-26 18:31:12 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-linux-ppc64@0.34.5':
|
2024-11-26 18:31:12 +01:00
|
|
|
optionalDependencies:
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-linux-ppc64': 1.2.4
|
2024-11-26 18:31:12 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-linux-riscv64@0.34.5':
|
2024-11-26 18:31:12 +01:00
|
|
|
optionalDependencies:
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-linux-riscv64': 1.2.4
|
2024-11-26 18:31:12 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-linux-s390x@0.34.5':
|
2024-11-26 18:31:12 +01:00
|
|
|
optionalDependencies:
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-linux-s390x': 1.2.4
|
2024-11-26 18:31:12 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-linux-x64@0.34.5':
|
2024-11-26 18:31:12 +01:00
|
|
|
optionalDependencies:
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-linux-x64': 1.2.4
|
2024-11-26 18:31:12 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-linuxmusl-arm64@0.34.5':
|
2025-07-30 10:32:16 -04:00
|
|
|
optionalDependencies:
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-libvips-linuxmusl-arm64': 1.2.4
|
2025-07-30 10:32:16 -04:00
|
|
|
optional: true
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-linuxmusl-x64@0.34.5':
|
|
|
|
|
optionalDependencies:
|
|
|
|
|
'@img/sharp-libvips-linuxmusl-x64': 1.2.4
|
|
|
|
|
optional: true
|
|
|
|
|
|
|
|
|
|
'@img/sharp-wasm32@0.34.5':
|
2024-11-26 18:31:12 +01:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@emnapi/runtime': 1.11.3
|
2024-11-26 18:31:12 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-win32-arm64@0.34.5':
|
2025-07-30 10:32:16 -04:00
|
|
|
optional: true
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-win32-ia32@0.34.5':
|
2024-11-26 18:31:12 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-win32-x64@0.34.5':
|
2024-11-26 18:31:12 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/ansi@2.0.7': {}
|
2025-09-19 17:08:41 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/checkbox@5.2.1(@types/node@25.9.1)':
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/ansi': 2.0.7
|
|
|
|
|
'@inquirer/core': 11.2.1(@types/node@25.9.1)
|
|
|
|
|
'@inquirer/figures': 2.0.7
|
|
|
|
|
'@inquirer/type': 4.0.7(@types/node@25.9.1)
|
2025-04-11 17:19:55 +02:00
|
|
|
optionalDependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@types/node': 25.9.1
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/confirm@6.1.1(@types/node@25.9.1)':
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/core': 11.2.1(@types/node@25.9.1)
|
|
|
|
|
'@inquirer/type': 4.0.7(@types/node@25.9.1)
|
2025-04-11 17:19:55 +02:00
|
|
|
optionalDependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@types/node': 25.9.1
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/core@11.2.1(@types/node@25.9.1)':
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/ansi': 2.0.7
|
|
|
|
|
'@inquirer/figures': 2.0.7
|
|
|
|
|
'@inquirer/type': 4.0.7(@types/node@25.9.1)
|
2025-04-11 17:19:55 +02:00
|
|
|
cli-width: 4.1.0
|
2026-05-22 16:57:46 +02:00
|
|
|
fast-wrap-ansi: 0.2.2
|
2026-04-26 17:49:06 +02:00
|
|
|
mute-stream: 3.0.0
|
2025-04-11 17:19:55 +02:00
|
|
|
signal-exit: 4.1.0
|
|
|
|
|
optionalDependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@types/node': 25.9.1
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/editor@5.2.2(@types/node@25.9.1)':
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/core': 11.2.1(@types/node@25.9.1)
|
|
|
|
|
'@inquirer/external-editor': 3.0.3(@types/node@25.9.1)
|
|
|
|
|
'@inquirer/type': 4.0.7(@types/node@25.9.1)
|
2025-04-11 17:19:55 +02:00
|
|
|
optionalDependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@types/node': 25.9.1
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/expand@5.1.1(@types/node@25.9.1)':
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/core': 11.2.1(@types/node@25.9.1)
|
|
|
|
|
'@inquirer/type': 4.0.7(@types/node@25.9.1)
|
2025-04-11 17:19:55 +02:00
|
|
|
optionalDependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@types/node': 25.9.1
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/external-editor@3.0.3(@types/node@25.9.1)':
|
2025-09-19 17:08:41 +02:00
|
|
|
dependencies:
|
2026-01-06 12:44:27 +01:00
|
|
|
chardet: 2.1.1
|
2026-04-26 17:49:06 +02:00
|
|
|
iconv-lite: 0.7.2
|
2025-09-19 17:08:41 +02:00
|
|
|
optionalDependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@types/node': 25.9.1
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/figures@2.0.7': {}
|
2025-09-19 17:08:41 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/input@5.1.2(@types/node@25.9.1)':
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/core': 11.2.1(@types/node@25.9.1)
|
|
|
|
|
'@inquirer/type': 4.0.7(@types/node@25.9.1)
|
2025-04-11 17:19:55 +02:00
|
|
|
optionalDependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@types/node': 25.9.1
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/number@4.1.1(@types/node@25.9.1)':
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/core': 11.2.1(@types/node@25.9.1)
|
|
|
|
|
'@inquirer/type': 4.0.7(@types/node@25.9.1)
|
2025-04-11 17:19:55 +02:00
|
|
|
optionalDependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@types/node': 25.9.1
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/password@5.1.1(@types/node@25.9.1)':
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/ansi': 2.0.7
|
|
|
|
|
'@inquirer/core': 11.2.1(@types/node@25.9.1)
|
|
|
|
|
'@inquirer/type': 4.0.7(@types/node@25.9.1)
|
2025-04-11 17:19:55 +02:00
|
|
|
optionalDependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@types/node': 25.9.1
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/prompts@8.5.2(@types/node@25.9.1)':
|
|
|
|
|
dependencies:
|
|
|
|
|
'@inquirer/checkbox': 5.2.1(@types/node@25.9.1)
|
|
|
|
|
'@inquirer/confirm': 6.1.1(@types/node@25.9.1)
|
|
|
|
|
'@inquirer/editor': 5.2.2(@types/node@25.9.1)
|
|
|
|
|
'@inquirer/expand': 5.1.1(@types/node@25.9.1)
|
|
|
|
|
'@inquirer/input': 5.1.2(@types/node@25.9.1)
|
|
|
|
|
'@inquirer/number': 4.1.1(@types/node@25.9.1)
|
|
|
|
|
'@inquirer/password': 5.1.1(@types/node@25.9.1)
|
|
|
|
|
'@inquirer/rawlist': 5.3.1(@types/node@25.9.1)
|
|
|
|
|
'@inquirer/search': 4.2.1(@types/node@25.9.1)
|
|
|
|
|
'@inquirer/select': 5.2.1(@types/node@25.9.1)
|
2025-04-11 17:19:55 +02:00
|
|
|
optionalDependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@types/node': 25.9.1
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/rawlist@5.3.1(@types/node@25.9.1)':
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/core': 11.2.1(@types/node@25.9.1)
|
|
|
|
|
'@inquirer/type': 4.0.7(@types/node@25.9.1)
|
2025-04-11 17:19:55 +02:00
|
|
|
optionalDependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@types/node': 25.9.1
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/search@4.2.1(@types/node@25.9.1)':
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/core': 11.2.1(@types/node@25.9.1)
|
|
|
|
|
'@inquirer/figures': 2.0.7
|
|
|
|
|
'@inquirer/type': 4.0.7(@types/node@25.9.1)
|
2025-04-11 17:19:55 +02:00
|
|
|
optionalDependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@types/node': 25.9.1
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/select@5.2.1(@types/node@25.9.1)':
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/ansi': 2.0.7
|
|
|
|
|
'@inquirer/core': 11.2.1(@types/node@25.9.1)
|
|
|
|
|
'@inquirer/figures': 2.0.7
|
|
|
|
|
'@inquirer/type': 4.0.7(@types/node@25.9.1)
|
2025-04-11 17:19:55 +02:00
|
|
|
optionalDependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@types/node': 25.9.1
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/type@4.0.7(@types/node@25.9.1)':
|
2025-04-11 17:19:55 +02:00
|
|
|
optionalDependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@types/node': 25.9.1
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@jridgewell/gen-mapping@0.3.13':
|
2024-05-24 15:07:44 +02:00
|
|
|
dependencies:
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
'@jridgewell/sourcemap-codec': 1.5.5
|
2026-05-22 16:57:46 +02:00
|
|
|
'@jridgewell/trace-mapping': 0.3.31
|
2025-05-12 15:49:18 +02:00
|
|
|
|
2025-08-12 15:52:35 +02:00
|
|
|
'@jridgewell/remapping@2.3.5':
|
|
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@jridgewell/gen-mapping': 0.3.13
|
|
|
|
|
'@jridgewell/trace-mapping': 0.3.31
|
2025-08-12 15:52:35 +02:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
'@jridgewell/resolve-uri@3.1.2': {}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@jridgewell/source-map@0.3.11':
|
2024-09-04 10:09:24 +02:00
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@jridgewell/gen-mapping': 0.3.13
|
|
|
|
|
'@jridgewell/trace-mapping': 0.3.31
|
2024-09-04 10:09:24 +02:00
|
|
|
|
2025-08-29 14:22:19 +00:00
|
|
|
'@jridgewell/sourcemap-codec@1.5.5': {}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@jridgewell/trace-mapping@0.3.31':
|
2024-05-24 15:07:44 +02:00
|
|
|
dependencies:
|
|
|
|
|
'@jridgewell/resolve-uri': 3.1.2
|
2025-09-26 19:00:31 +00:00
|
|
|
'@jridgewell/sourcemap-codec': 1.5.5
|
2024-05-24 15:07:44 +02:00
|
|
|
|
Use wasm as a fallback for `@tailwindcss/oxide` (#20383)
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]
2026-08-04 18:41:43 +02:00
|
|
|
'@napi-rs/cli@3.7.4(patch_hash=9912bf0a9c2cef8329d11c41fbce4d33ce2bdcf660a630b258c962c0a3c44bed)(@emnapi/core@1.11.3)(@emnapi/runtime@1.11.3)(@types/node@25.9.1)(node-addon-api@8.7.0)':
|
2025-07-25 07:13:25 -04:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@inquirer/prompts': 8.5.2(@types/node@25.9.1)
|
|
|
|
|
'@napi-rs/cross-toolchain': 1.0.3(@emnapi/core@1.11.3)(@emnapi/runtime@1.11.3)
|
|
|
|
|
'@napi-rs/wasm-tools': 1.0.1(@emnapi/core@1.11.3)(@emnapi/runtime@1.11.3)
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/rest': 22.0.1
|
2025-04-11 17:19:55 +02:00
|
|
|
clipanion: 4.0.0-rc.4(typanion@3.14.0)
|
|
|
|
|
colorette: 2.0.20
|
2026-08-04 13:55:03 +02:00
|
|
|
emnapi: 1.11.3(node-addon-api@8.7.0)
|
|
|
|
|
es-toolkit: 1.50.0
|
|
|
|
|
js-yaml: 4.3.1
|
|
|
|
|
obug: 2.1.4
|
|
|
|
|
semver: 7.8.5
|
2025-04-11 17:19:55 +02:00
|
|
|
typanion: 3.14.0
|
|
|
|
|
optionalDependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@emnapi/runtime': 1.11.3
|
2025-04-11 17:19:55 +02:00
|
|
|
transitivePeerDependencies:
|
2026-04-26 17:49:06 +02:00
|
|
|
- '@emnapi/core'
|
2025-04-11 17:19:55 +02:00
|
|
|
- '@napi-rs/cross-toolchain-arm64-target-aarch64'
|
|
|
|
|
- '@napi-rs/cross-toolchain-arm64-target-armv7'
|
2025-09-19 17:08:41 +02:00
|
|
|
- '@napi-rs/cross-toolchain-arm64-target-ppc64le'
|
|
|
|
|
- '@napi-rs/cross-toolchain-arm64-target-s390x'
|
2025-04-11 17:19:55 +02:00
|
|
|
- '@napi-rs/cross-toolchain-arm64-target-x86_64'
|
|
|
|
|
- '@napi-rs/cross-toolchain-x64-target-aarch64'
|
|
|
|
|
- '@napi-rs/cross-toolchain-x64-target-armv7'
|
2025-09-19 17:08:41 +02:00
|
|
|
- '@napi-rs/cross-toolchain-x64-target-ppc64le'
|
|
|
|
|
- '@napi-rs/cross-toolchain-x64-target-s390x'
|
2025-04-11 17:19:55 +02:00
|
|
|
- '@napi-rs/cross-toolchain-x64-target-x86_64'
|
|
|
|
|
- '@types/node'
|
2025-10-10 12:44:16 -04:00
|
|
|
- node-addon-api
|
2025-04-11 17:19:55 +02:00
|
|
|
- supports-color
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@napi-rs/cross-toolchain@1.0.3(@emnapi/core@1.11.3)(@emnapi/runtime@1.11.3)':
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@napi-rs/lzma': 1.4.5(@emnapi/core@1.11.3)(@emnapi/runtime@1.11.3)
|
|
|
|
|
'@napi-rs/tar': 1.1.0(@emnapi/core@1.11.3)(@emnapi/runtime@1.11.3)
|
2025-09-19 17:08:41 +02:00
|
|
|
debug: 4.4.3
|
2025-04-11 17:19:55 +02:00
|
|
|
transitivePeerDependencies:
|
2026-04-26 17:49:06 +02:00
|
|
|
- '@emnapi/core'
|
|
|
|
|
- '@emnapi/runtime'
|
2025-04-11 17:19:55 +02:00
|
|
|
- supports-color
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-android-arm-eabi@1.4.5':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-android-arm64@1.4.5':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-darwin-arm64@1.4.5':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-darwin-x64@1.4.5':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-freebsd-x64@1.4.5':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-linux-arm-gnueabihf@1.4.5':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-linux-arm64-gnu@1.4.5':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-linux-arm64-musl@1.4.5':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-linux-ppc64-gnu@1.4.5':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-linux-riscv64-gnu@1.4.5':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-linux-s390x-gnu@1.4.5':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-linux-x64-gnu@1.4.5':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-linux-x64-musl@1.4.5':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@napi-rs/lzma-wasm32-wasi@1.4.5(@emnapi/core@1.11.3)(@emnapi/runtime@1.11.3)':
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@napi-rs/wasm-runtime': 1.2.2(@emnapi/core@1.11.3)(@emnapi/runtime@1.11.3)
|
2026-04-26 17:49:06 +02:00
|
|
|
transitivePeerDependencies:
|
|
|
|
|
- '@emnapi/core'
|
|
|
|
|
- '@emnapi/runtime'
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-win32-arm64-msvc@1.4.5':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-win32-ia32-msvc@1.4.5':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-win32-x64-msvc@1.4.5':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@napi-rs/lzma@1.4.5(@emnapi/core@1.11.3)(@emnapi/runtime@1.11.3)':
|
2025-04-11 17:19:55 +02:00
|
|
|
optionalDependencies:
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-android-arm-eabi': 1.4.5
|
|
|
|
|
'@napi-rs/lzma-android-arm64': 1.4.5
|
|
|
|
|
'@napi-rs/lzma-darwin-arm64': 1.4.5
|
|
|
|
|
'@napi-rs/lzma-darwin-x64': 1.4.5
|
|
|
|
|
'@napi-rs/lzma-freebsd-x64': 1.4.5
|
|
|
|
|
'@napi-rs/lzma-linux-arm-gnueabihf': 1.4.5
|
|
|
|
|
'@napi-rs/lzma-linux-arm64-gnu': 1.4.5
|
|
|
|
|
'@napi-rs/lzma-linux-arm64-musl': 1.4.5
|
|
|
|
|
'@napi-rs/lzma-linux-ppc64-gnu': 1.4.5
|
|
|
|
|
'@napi-rs/lzma-linux-riscv64-gnu': 1.4.5
|
|
|
|
|
'@napi-rs/lzma-linux-s390x-gnu': 1.4.5
|
|
|
|
|
'@napi-rs/lzma-linux-x64-gnu': 1.4.5
|
|
|
|
|
'@napi-rs/lzma-linux-x64-musl': 1.4.5
|
2026-08-04 13:55:03 +02:00
|
|
|
'@napi-rs/lzma-wasm32-wasi': 1.4.5(@emnapi/core@1.11.3)(@emnapi/runtime@1.11.3)
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/lzma-win32-arm64-msvc': 1.4.5
|
|
|
|
|
'@napi-rs/lzma-win32-ia32-msvc': 1.4.5
|
|
|
|
|
'@napi-rs/lzma-win32-x64-msvc': 1.4.5
|
2026-04-26 17:49:06 +02:00
|
|
|
transitivePeerDependencies:
|
|
|
|
|
- '@emnapi/core'
|
|
|
|
|
- '@emnapi/runtime'
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-android-arm-eabi@1.1.0':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-android-arm64@1.1.0':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-darwin-arm64@1.1.0':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-darwin-x64@1.1.0':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-freebsd-x64@1.1.0':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-linux-arm-gnueabihf@1.1.0':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-linux-arm64-gnu@1.1.0':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-linux-arm64-musl@1.1.0':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-linux-ppc64-gnu@1.1.0':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-linux-s390x-gnu@1.1.0':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-linux-x64-gnu@1.1.0':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-linux-x64-musl@1.1.0':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@napi-rs/tar-wasm32-wasi@1.1.0(@emnapi/core@1.11.3)(@emnapi/runtime@1.11.3)':
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@napi-rs/wasm-runtime': 1.2.2(@emnapi/core@1.11.3)(@emnapi/runtime@1.11.3)
|
2026-04-26 17:49:06 +02:00
|
|
|
transitivePeerDependencies:
|
|
|
|
|
- '@emnapi/core'
|
|
|
|
|
- '@emnapi/runtime'
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-win32-arm64-msvc@1.1.0':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-win32-ia32-msvc@1.1.0':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-win32-x64-msvc@1.1.0':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@napi-rs/tar@1.1.0(@emnapi/core@1.11.3)(@emnapi/runtime@1.11.3)':
|
2025-04-11 17:19:55 +02:00
|
|
|
optionalDependencies:
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-android-arm-eabi': 1.1.0
|
|
|
|
|
'@napi-rs/tar-android-arm64': 1.1.0
|
|
|
|
|
'@napi-rs/tar-darwin-arm64': 1.1.0
|
|
|
|
|
'@napi-rs/tar-darwin-x64': 1.1.0
|
|
|
|
|
'@napi-rs/tar-freebsd-x64': 1.1.0
|
|
|
|
|
'@napi-rs/tar-linux-arm-gnueabihf': 1.1.0
|
|
|
|
|
'@napi-rs/tar-linux-arm64-gnu': 1.1.0
|
|
|
|
|
'@napi-rs/tar-linux-arm64-musl': 1.1.0
|
|
|
|
|
'@napi-rs/tar-linux-ppc64-gnu': 1.1.0
|
|
|
|
|
'@napi-rs/tar-linux-s390x-gnu': 1.1.0
|
|
|
|
|
'@napi-rs/tar-linux-x64-gnu': 1.1.0
|
|
|
|
|
'@napi-rs/tar-linux-x64-musl': 1.1.0
|
2026-08-04 13:55:03 +02:00
|
|
|
'@napi-rs/tar-wasm32-wasi': 1.1.0(@emnapi/core@1.11.3)(@emnapi/runtime@1.11.3)
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/tar-win32-arm64-msvc': 1.1.0
|
|
|
|
|
'@napi-rs/tar-win32-ia32-msvc': 1.1.0
|
|
|
|
|
'@napi-rs/tar-win32-x64-msvc': 1.1.0
|
2026-04-26 17:49:06 +02:00
|
|
|
transitivePeerDependencies:
|
|
|
|
|
- '@emnapi/core'
|
|
|
|
|
- '@emnapi/runtime'
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
'@napi-rs/wasm-runtime@1.1.4(@emnapi/core@1.10.0)(@emnapi/runtime@1.10.0)':
|
|
|
|
|
dependencies:
|
|
|
|
|
'@emnapi/core': 1.10.0
|
|
|
|
|
'@emnapi/runtime': 1.10.0
|
2026-08-04 13:55:03 +02:00
|
|
|
'@tybys/wasm-util': 0.10.3
|
2026-06-15 13:13:32 +00:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@napi-rs/wasm-runtime@1.2.2(@emnapi/core@1.11.3)(@emnapi/runtime@1.11.3)':
|
2026-06-15 13:13:32 +00:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@emnapi/core': 1.11.3
|
|
|
|
|
'@emnapi/runtime': 1.11.3
|
|
|
|
|
'@tybys/wasm-util': 0.10.3
|
2026-06-15 13:13:32 +00:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@napi-rs/wasm-runtime@1.2.2(@emnapi/core@2.0.0-alpha.3)(@emnapi/runtime@2.0.0-alpha.3)':
|
2026-06-15 13:13:32 +00:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@emnapi/core': 2.0.0-alpha.3
|
|
|
|
|
'@emnapi/runtime': 2.0.0-alpha.3
|
2026-07-02 11:45:49 +02:00
|
|
|
'@tybys/wasm-util': 0.10.3
|
|
|
|
|
optional: true
|
2026-04-24 21:21:12 +02:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-android-arm-eabi@1.0.1':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-android-arm64@1.0.1':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-darwin-arm64@1.0.1':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-darwin-x64@1.0.1':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-freebsd-x64@1.0.1':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-linux-arm64-gnu@1.0.1':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-linux-arm64-musl@1.0.1':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-linux-x64-gnu@1.0.1':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-linux-x64-musl@1.0.1':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@napi-rs/wasm-tools-wasm32-wasi@1.0.1(@emnapi/core@1.11.3)(@emnapi/runtime@1.11.3)':
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@napi-rs/wasm-runtime': 1.2.2(@emnapi/core@1.11.3)(@emnapi/runtime@1.11.3)
|
2026-04-26 17:49:06 +02:00
|
|
|
transitivePeerDependencies:
|
|
|
|
|
- '@emnapi/core'
|
|
|
|
|
- '@emnapi/runtime'
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-win32-arm64-msvc@1.0.1':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-win32-ia32-msvc@1.0.1':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-win32-x64-msvc@1.0.1':
|
2025-04-11 17:19:55 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@napi-rs/wasm-tools@1.0.1(@emnapi/core@1.11.3)(@emnapi/runtime@1.11.3)':
|
2025-04-11 17:19:55 +02:00
|
|
|
optionalDependencies:
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-android-arm-eabi': 1.0.1
|
|
|
|
|
'@napi-rs/wasm-tools-android-arm64': 1.0.1
|
|
|
|
|
'@napi-rs/wasm-tools-darwin-arm64': 1.0.1
|
|
|
|
|
'@napi-rs/wasm-tools-darwin-x64': 1.0.1
|
|
|
|
|
'@napi-rs/wasm-tools-freebsd-x64': 1.0.1
|
|
|
|
|
'@napi-rs/wasm-tools-linux-arm64-gnu': 1.0.1
|
|
|
|
|
'@napi-rs/wasm-tools-linux-arm64-musl': 1.0.1
|
|
|
|
|
'@napi-rs/wasm-tools-linux-x64-gnu': 1.0.1
|
|
|
|
|
'@napi-rs/wasm-tools-linux-x64-musl': 1.0.1
|
2026-08-04 13:55:03 +02:00
|
|
|
'@napi-rs/wasm-tools-wasm32-wasi': 1.0.1(@emnapi/core@1.11.3)(@emnapi/runtime@1.11.3)
|
2025-09-19 17:08:41 +02:00
|
|
|
'@napi-rs/wasm-tools-win32-arm64-msvc': 1.0.1
|
|
|
|
|
'@napi-rs/wasm-tools-win32-ia32-msvc': 1.0.1
|
|
|
|
|
'@napi-rs/wasm-tools-win32-x64-msvc': 1.0.1
|
2026-04-26 17:49:06 +02:00
|
|
|
transitivePeerDependencies:
|
|
|
|
|
- '@emnapi/core'
|
|
|
|
|
- '@emnapi/runtime'
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-06-09 12:38:33 +02:00
|
|
|
'@next/env@16.2.7': {}
|
2024-10-24 11:00:25 -04:00
|
|
|
|
2026-06-09 12:38:33 +02:00
|
|
|
'@next/swc-darwin-arm64@16.2.7':
|
2024-05-24 15:07:44 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-06-09 12:38:33 +02:00
|
|
|
'@next/swc-darwin-x64@16.2.7':
|
2024-05-24 15:07:44 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-06-09 12:38:33 +02:00
|
|
|
'@next/swc-linux-arm64-gnu@16.2.7':
|
2024-05-24 15:07:44 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-06-09 12:38:33 +02:00
|
|
|
'@next/swc-linux-arm64-musl@16.2.7':
|
2024-05-24 15:07:44 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-06-09 12:38:33 +02:00
|
|
|
'@next/swc-linux-x64-gnu@16.2.7':
|
2024-05-24 15:07:44 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-06-09 12:38:33 +02:00
|
|
|
'@next/swc-linux-x64-musl@16.2.7':
|
2024-05-24 15:07:44 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-06-09 12:38:33 +02:00
|
|
|
'@next/swc-win32-arm64-msvc@16.2.7':
|
2024-05-24 15:07:44 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-06-09 12:38:33 +02:00
|
|
|
'@next/swc-win32-x64-msvc@16.2.7':
|
2024-05-24 15:07:44 +02:00
|
|
|
optional: true
|
|
|
|
|
|
|
|
|
|
'@nodelib/fs.scandir@2.1.5':
|
|
|
|
|
dependencies:
|
|
|
|
|
'@nodelib/fs.stat': 2.0.5
|
|
|
|
|
run-parallel: 1.2.0
|
|
|
|
|
|
|
|
|
|
'@nodelib/fs.stat@2.0.5': {}
|
|
|
|
|
|
|
|
|
|
'@nodelib/fs.walk@1.2.8':
|
|
|
|
|
dependencies:
|
|
|
|
|
'@nodelib/fs.scandir': 2.1.5
|
2026-05-22 16:57:46 +02:00
|
|
|
fastq: 1.20.1
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
'@octokit/auth-token@6.0.0': {}
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/core@7.0.6':
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
2025-09-19 17:08:41 +02:00
|
|
|
'@octokit/auth-token': 6.0.0
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/graphql': 9.0.3
|
2026-05-22 16:57:46 +02:00
|
|
|
'@octokit/request': 10.0.9
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/request-error': 7.1.0
|
|
|
|
|
'@octokit/types': 16.0.0
|
2025-09-19 17:08:41 +02:00
|
|
|
before-after-hook: 4.0.0
|
2026-05-22 16:57:46 +02:00
|
|
|
universal-user-agent: 7.0.3
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@octokit/endpoint@11.0.3':
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/types': 16.0.0
|
2026-05-22 16:57:46 +02:00
|
|
|
universal-user-agent: 7.0.3
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/graphql@9.0.3':
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@octokit/request': 10.0.9
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/types': 16.0.0
|
2026-05-22 16:57:46 +02:00
|
|
|
universal-user-agent: 7.0.3
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/openapi-types@27.0.0': {}
|
2025-12-10 11:26:51 -05:00
|
|
|
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/plugin-paginate-rest@14.0.0(@octokit/core@7.0.6)':
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/core': 7.0.6
|
|
|
|
|
'@octokit/types': 16.0.0
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/plugin-request-log@6.0.0(@octokit/core@7.0.6)':
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/core': 7.0.6
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/plugin-rest-endpoint-methods@17.0.0(@octokit/core@7.0.6)':
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/core': 7.0.6
|
|
|
|
|
'@octokit/types': 16.0.0
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/request-error@7.1.0':
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/types': 16.0.0
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@octokit/request@10.0.9':
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@octokit/endpoint': 11.0.3
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/request-error': 7.1.0
|
|
|
|
|
'@octokit/types': 16.0.0
|
2026-05-22 16:57:46 +02:00
|
|
|
content-type: 2.0.0
|
2025-09-19 17:08:41 +02:00
|
|
|
fast-content-type-parse: 3.0.0
|
2026-05-22 16:57:46 +02:00
|
|
|
json-with-bigint: 3.5.8
|
|
|
|
|
universal-user-agent: 7.0.3
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/rest@22.0.1':
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/core': 7.0.6
|
|
|
|
|
'@octokit/plugin-paginate-rest': 14.0.0(@octokit/core@7.0.6)
|
|
|
|
|
'@octokit/plugin-request-log': 6.0.0(@octokit/core@7.0.6)
|
|
|
|
|
'@octokit/plugin-rest-endpoint-methods': 17.0.0(@octokit/core@7.0.6)
|
2025-12-10 11:26:51 -05:00
|
|
|
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/types@16.0.0':
|
2025-12-10 11:26:51 -05:00
|
|
|
dependencies:
|
2026-01-06 12:44:27 +01:00
|
|
|
'@octokit/openapi-types': 27.0.0
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-darwin-aarch64@1.3.14':
|
|
|
|
|
optional: true
|
|
|
|
|
|
|
|
|
|
'@oven/bun-darwin-x64-baseline@1.3.14':
|
|
|
|
|
optional: true
|
|
|
|
|
|
|
|
|
|
'@oven/bun-darwin-x64@1.3.14':
|
|
|
|
|
optional: true
|
|
|
|
|
|
|
|
|
|
'@oven/bun-freebsd-aarch64@1.3.14':
|
|
|
|
|
optional: true
|
|
|
|
|
|
|
|
|
|
'@oven/bun-freebsd-x64@1.3.14':
|
2026-04-23 12:51:20 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-linux-aarch64-android@1.3.14':
|
2026-04-23 12:51:20 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-linux-aarch64-musl@1.3.14':
|
2026-04-23 12:51:20 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-linux-aarch64@1.3.14':
|
2026-04-23 12:51:20 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-linux-x64-android@1.3.14':
|
2026-04-23 12:51:20 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-linux-x64-baseline@1.3.14':
|
2026-04-23 12:51:20 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-linux-x64-musl-baseline@1.3.14':
|
2026-04-23 12:51:20 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-linux-x64-musl@1.3.14':
|
2026-04-23 12:51:20 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-linux-x64@1.3.14':
|
2026-04-23 12:51:20 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-windows-aarch64@1.3.14':
|
2026-04-23 12:51:20 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-windows-x64-baseline@1.3.14':
|
2026-04-23 12:51:20 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-windows-x64@1.3.14':
|
2026-04-23 12:51:20 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@oxc-project/types@0.142.0': {}
|
2025-02-04 15:14:52 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-android-arm64@2.6.0':
|
2025-02-04 15:14:52 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-darwin-arm64@2.6.0': {}
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-darwin-x64@2.6.0': {}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-freebsd-x64@2.6.0':
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-linux-arm-glibc@2.6.0':
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-linux-arm-musl@2.6.0':
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-linux-arm64-glibc@2.6.0': {}
|
2025-02-04 15:14:52 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-linux-arm64-musl@2.6.0': {}
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-linux-x64-glibc@2.6.0': {}
|
2025-02-04 15:14:52 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-linux-x64-musl@2.6.0': {}
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
'@parcel/watcher-wasm@2.5.6':
|
2025-01-07 09:57:34 -05:00
|
|
|
dependencies:
|
|
|
|
|
is-glob: 4.0.3
|
2026-08-04 13:55:03 +02:00
|
|
|
picomatch: 4.0.5
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-win32-arm64@2.6.0':
|
2025-02-04 15:14:52 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-win32-x64@2.6.0': {}
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher@2.6.0(patch_hash=705ce75ccea54337110c4d7fe0a8b421658ea0c23e1a77c1fa890a86041179da)':
|
2026-04-24 21:21:12 +02:00
|
|
|
dependencies:
|
|
|
|
|
detect-libc: 2.1.2
|
|
|
|
|
is-glob: 4.0.3
|
|
|
|
|
node-addon-api: 7.1.1
|
2026-08-04 13:55:03 +02:00
|
|
|
picomatch: 4.0.5
|
2026-04-24 21:21:12 +02:00
|
|
|
optionalDependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@parcel/watcher-android-arm64': 2.6.0
|
|
|
|
|
'@parcel/watcher-darwin-arm64': 2.6.0
|
|
|
|
|
'@parcel/watcher-darwin-x64': 2.6.0
|
|
|
|
|
'@parcel/watcher-freebsd-x64': 2.6.0
|
|
|
|
|
'@parcel/watcher-linux-arm-glibc': 2.6.0
|
|
|
|
|
'@parcel/watcher-linux-arm-musl': 2.6.0
|
|
|
|
|
'@parcel/watcher-linux-arm64-glibc': 2.6.0
|
|
|
|
|
'@parcel/watcher-linux-arm64-musl': 2.6.0
|
|
|
|
|
'@parcel/watcher-linux-x64-glibc': 2.6.0
|
|
|
|
|
'@parcel/watcher-linux-x64-musl': 2.6.0
|
|
|
|
|
'@parcel/watcher-win32-arm64': 2.6.0
|
|
|
|
|
'@parcel/watcher-win32-x64': 2.6.0
|
2026-04-24 21:21:12 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@playwright/test@1.62.1':
|
2024-05-24 15:07:44 +02:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
playwright: 1.62.1
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-android-arm64@1.2.1':
|
2026-03-12 20:54:34 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-darwin-arm64@1.2.1':
|
2026-03-12 20:54:34 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-darwin-x64@1.2.1':
|
2026-03-12 20:54:34 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-freebsd-x64@1.2.1':
|
2026-03-12 20:54:34 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-linux-arm-gnueabihf@1.2.1':
|
2026-03-12 20:54:34 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-linux-arm64-gnu@1.2.1':
|
2026-03-12 20:54:34 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-linux-arm64-musl@1.2.1':
|
2026-03-12 20:54:34 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-linux-ppc64-gnu@1.2.1':
|
2026-03-12 20:54:34 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-linux-s390x-gnu@1.2.1':
|
2026-03-12 20:54:34 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-linux-x64-gnu@1.2.1':
|
2026-03-12 20:54:34 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-linux-x64-musl@1.2.1':
|
2026-03-12 20:54:34 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-openharmony-arm64@1.2.1':
|
2026-03-12 20:54:34 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-wasm32-wasi@1.2.1':
|
2026-03-12 20:54:34 +01:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@emnapi/core': 2.0.0-alpha.3
|
|
|
|
|
'@emnapi/runtime': 2.0.0-alpha.3
|
|
|
|
|
'@napi-rs/wasm-runtime': 1.2.2(@emnapi/core@2.0.0-alpha.3)(@emnapi/runtime@2.0.0-alpha.3)
|
2026-03-12 20:54:34 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-win32-arm64-msvc@1.2.1':
|
2026-03-12 20:54:34 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-win32-x64-msvc@1.2.1':
|
2026-03-12 20:54:34 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@rolldown/pluginutils@1.0.1': {}
|
2026-03-12 20:54:34 +01:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-android-arm-eabi@4.60.4':
|
|
|
|
|
optional: true
|
|
|
|
|
|
|
|
|
|
'@rollup/rollup-android-arm64@4.60.4':
|
2025-06-24 18:31:17 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-darwin-arm64@4.60.4':
|
2025-06-24 18:31:17 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-darwin-x64@4.60.4':
|
2025-06-24 18:31:17 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-freebsd-arm64@4.60.4':
|
2025-06-24 18:31:17 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-freebsd-x64@4.60.4':
|
2025-06-24 18:31:17 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-linux-arm-gnueabihf@4.60.4':
|
2025-06-24 18:31:17 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-linux-arm-musleabihf@4.60.4':
|
2025-06-24 18:31:17 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-linux-arm64-gnu@4.60.4':
|
2025-06-24 18:31:17 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-linux-arm64-musl@4.60.4':
|
2025-06-24 18:31:17 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-linux-loong64-gnu@4.60.4':
|
2025-06-24 18:31:17 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-linux-loong64-musl@4.60.4':
|
2025-06-24 18:31:17 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-linux-ppc64-gnu@4.60.4':
|
2025-06-24 18:31:17 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-linux-ppc64-musl@4.60.4':
|
2025-06-24 18:31:17 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-linux-riscv64-gnu@4.60.4':
|
2025-06-24 18:31:17 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-linux-riscv64-musl@4.60.4':
|
2025-06-24 18:31:17 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-linux-s390x-gnu@4.60.4':
|
2025-06-24 18:31:17 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-linux-x64-gnu@4.60.4':
|
2025-06-24 18:31:17 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-linux-x64-musl@4.60.4':
|
2025-06-24 18:31:17 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-openbsd-x64@4.60.4':
|
2025-06-24 18:31:17 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-openharmony-arm64@4.60.4':
|
|
|
|
|
optional: true
|
|
|
|
|
|
|
|
|
|
'@rollup/rollup-win32-arm64-msvc@4.60.4':
|
|
|
|
|
optional: true
|
|
|
|
|
|
|
|
|
|
'@rollup/rollup-win32-ia32-msvc@4.60.4':
|
|
|
|
|
optional: true
|
|
|
|
|
|
|
|
|
|
'@rollup/rollup-win32-x64-gnu@4.60.4':
|
|
|
|
|
optional: true
|
|
|
|
|
|
|
|
|
|
'@rollup/rollup-win32-x64-msvc@4.60.4':
|
2025-06-24 18:31:17 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-05-23 17:14:48 +08:00
|
|
|
'@rspack/binding-darwin-arm64@2.0.2':
|
|
|
|
|
optional: true
|
|
|
|
|
|
|
|
|
|
'@rspack/binding-darwin-x64@2.0.2':
|
|
|
|
|
optional: true
|
|
|
|
|
|
|
|
|
|
'@rspack/binding-linux-arm64-gnu@2.0.2':
|
|
|
|
|
optional: true
|
|
|
|
|
|
|
|
|
|
'@rspack/binding-linux-arm64-musl@2.0.2':
|
|
|
|
|
optional: true
|
|
|
|
|
|
|
|
|
|
'@rspack/binding-linux-x64-gnu@2.0.2':
|
|
|
|
|
optional: true
|
|
|
|
|
|
|
|
|
|
'@rspack/binding-linux-x64-musl@2.0.2':
|
|
|
|
|
optional: true
|
|
|
|
|
|
|
|
|
|
'@rspack/binding-wasm32-wasi@2.0.2':
|
|
|
|
|
dependencies:
|
|
|
|
|
'@emnapi/core': 1.10.0
|
|
|
|
|
'@emnapi/runtime': 1.10.0
|
|
|
|
|
'@napi-rs/wasm-runtime': 1.1.4(@emnapi/core@1.10.0)(@emnapi/runtime@1.10.0)
|
|
|
|
|
optional: true
|
|
|
|
|
|
|
|
|
|
'@rspack/binding-win32-arm64-msvc@2.0.2':
|
|
|
|
|
optional: true
|
|
|
|
|
|
|
|
|
|
'@rspack/binding-win32-ia32-msvc@2.0.2':
|
|
|
|
|
optional: true
|
|
|
|
|
|
|
|
|
|
'@rspack/binding-win32-x64-msvc@2.0.2':
|
|
|
|
|
optional: true
|
|
|
|
|
|
|
|
|
|
'@rspack/binding@2.0.2':
|
|
|
|
|
optionalDependencies:
|
|
|
|
|
'@rspack/binding-darwin-arm64': 2.0.2
|
|
|
|
|
'@rspack/binding-darwin-x64': 2.0.2
|
|
|
|
|
'@rspack/binding-linux-arm64-gnu': 2.0.2
|
|
|
|
|
'@rspack/binding-linux-arm64-musl': 2.0.2
|
|
|
|
|
'@rspack/binding-linux-x64-gnu': 2.0.2
|
|
|
|
|
'@rspack/binding-linux-x64-musl': 2.0.2
|
|
|
|
|
'@rspack/binding-wasm32-wasi': 2.0.2
|
|
|
|
|
'@rspack/binding-win32-arm64-msvc': 2.0.2
|
|
|
|
|
'@rspack/binding-win32-ia32-msvc': 2.0.2
|
|
|
|
|
'@rspack/binding-win32-x64-msvc': 2.0.2
|
|
|
|
|
|
|
|
|
|
'@rspack/core@2.0.2(@swc/helpers@0.5.15)':
|
|
|
|
|
dependencies:
|
|
|
|
|
'@rspack/binding': 2.0.2
|
|
|
|
|
optionalDependencies:
|
|
|
|
|
'@swc/helpers': 0.5.15
|
|
|
|
|
|
2025-10-06 11:14:31 +02:00
|
|
|
'@sindresorhus/merge-streams@4.0.0': {}
|
2024-09-18 16:45:43 +02:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
'@standard-schema/spec@1.1.0': {}
|
2025-11-21 00:16:20 +01:00
|
|
|
|
2025-01-06 11:18:39 +01:00
|
|
|
'@swc/helpers@0.5.15':
|
2024-05-24 15:07:44 +02:00
|
|
|
dependencies:
|
2025-09-19 17:08:41 +02:00
|
|
|
tslib: 2.8.1
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2024-11-19 16:19:08 +01:00
|
|
|
'@tailwindcss/aspect-ratio@0.4.2(tailwindcss@packages+tailwindcss)':
|
|
|
|
|
dependencies:
|
|
|
|
|
tailwindcss: link:packages/tailwindcss
|
|
|
|
|
|
2025-12-24 17:20:21 -05:00
|
|
|
'@tailwindcss/forms@0.5.11(tailwindcss@packages+tailwindcss)':
|
2024-11-19 16:19:08 +01:00
|
|
|
dependencies:
|
|
|
|
|
mini-svg-data-uri: 1.4.4
|
|
|
|
|
tailwindcss: link:packages/tailwindcss
|
|
|
|
|
|
2026-06-15 13:13:32 +00:00
|
|
|
'@tailwindcss/typography@0.5.20(tailwindcss@packages+tailwindcss)':
|
2024-11-19 16:19:08 +01:00
|
|
|
dependencies:
|
|
|
|
|
postcss-selector-parser: 6.0.10
|
|
|
|
|
tailwindcss: link:packages/tailwindcss
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@turbo/darwin-64@2.10.8':
|
2026-04-24 21:21:12 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@turbo/darwin-arm64@2.10.8':
|
2026-04-24 21:21:12 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@turbo/linux-64@2.10.8':
|
2026-04-24 21:21:12 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@turbo/linux-arm64@2.10.8':
|
2026-04-24 21:21:12 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@turbo/windows-64@2.10.8':
|
2026-04-24 21:21:12 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@turbo/windows-arm64@2.10.8':
|
2026-04-24 21:21:12 +02:00
|
|
|
optional: true
|
|
|
|
|
|
2026-07-02 11:45:49 +02:00
|
|
|
'@tybys/wasm-util@0.10.3':
|
|
|
|
|
dependencies:
|
|
|
|
|
tslib: 2.8.1
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@types/bun@1.3.14':
|
2024-09-02 15:23:46 +02:00
|
|
|
dependencies:
|
2026-05-21 17:58:55 +02:00
|
|
|
bun-types: 1.3.14
|
2024-09-02 15:23:46 +02:00
|
|
|
|
2025-11-21 00:16:20 +01:00
|
|
|
'@types/chai@5.2.3':
|
|
|
|
|
dependencies:
|
|
|
|
|
'@types/deep-eql': 4.0.2
|
|
|
|
|
assertion-error: 2.0.1
|
|
|
|
|
|
|
|
|
|
'@types/deep-eql@4.0.2': {}
|
|
|
|
|
|
2025-06-24 18:31:17 +02:00
|
|
|
'@types/estree@1.0.8': {}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@types/estree@1.0.9': {}
|
|
|
|
|
|
2024-10-16 14:45:07 +00:00
|
|
|
'@types/json-schema@7.0.15': {}
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@types/node@22.20.1':
|
2025-06-24 18:31:17 +02:00
|
|
|
dependencies:
|
|
|
|
|
undici-types: 6.21.0
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
'@types/node@25.9.1':
|
|
|
|
|
dependencies:
|
|
|
|
|
undici-types: 7.24.6
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
'@types/postcss-import@14.0.3':
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
postcss: 8.5.25
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@types/react-dom@19.2.3(@types/react@19.2.15)':
|
2025-11-20 10:54:23 -05:00
|
|
|
dependencies:
|
2026-05-21 17:58:55 +02:00
|
|
|
'@types/react': 19.2.15
|
2025-11-20 10:54:23 -05:00
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
'@types/react@19.2.15':
|
2025-11-20 10:54:23 -05:00
|
|
|
dependencies:
|
|
|
|
|
csstype: 3.2.3
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@types/semver@7.8.0': {}
|
Ensure `@tailwindcss/upgrade` runs on Tailwind CSS v4 projects and is idempotent (#17717)
This PR ensures that the `@tailwindcss/upgrade` tool works on existing
Tailwind CSS v4 projects. This PR also ensures that the upgrade tool is
idempotent, meaning that it can be run multiple times and it should
result in the same output.
One awesome feature this unlocks is that you can run the upgrade tool on
your codebase at any time and upgrade classes if you still have some
legacy syntaxes, such as `bg-[var(--my-color)]`, in your muscle memory.
One small note: If something changed in the first run, re-running will
not work immediately because your git repository will not be clean and
the upgrade tool requires your git repo to be clean. But once you
verified and committed your changes, the upgrade tool will be
idempotent.
Idempotency is guaranteed by ensuring that some migrations are skipped
by checking what version of Tailwind CSS you are on _before_ the version
is upgraded.
For the Tailwind CSS version: We will resolve `tailwindcss` itself to
know the _actual_ version that is installed (the one resolved from
`node_modules`). Not the one available in your package.json. Your
`package.json` could be out of sync if you reverted changes but didn't
run `npm install` yet.
Back to Idempotency:
For example, we have migrations where we change the variant order of
stacked variants. If we would run these migrations every time you run
the upgrade tool then we would be flip-flopping the order every run.
See: https://tailwindcss.com/docs/upgrade-guide#variant-stacking-order
Another example is where we rename some utilities. For example, we
rename:
| Before | After |
| ----------- | ----------- |
| `shadow` | `shadow-sm` |
| `shadow-sm` | `shadow-xs` |
Notice how we have `shadow-sm` in both the `before` and `after` column.
If we would run the upgrade tool again, then we would eventually migrate
your original `shadow` to `shadow-sm` (first run) and then to
`shadow-xs` (second run). Which would result in the wrong shadow.
See: https://tailwindcss.com/docs/upgrade-guide#renamed-utilities
---
The order of upgrade steps changed a bit as well to make the internals
are easier to work with and reason about.
1. Find CSS files
2. Link JS config files (if you are in a Tailwind CSS v3 project)
3. Migrate the JS config files (if you are in a Tailwind CSS v3 project)
4. Upgrade Tailwind CSS to v4 (or the latest version at that point)
5. Migrate the stylesheets (we used to migrate the source files first)
6. Migrate the source files
This is done so that step 5 and 6 will always operate on a Tailwind CSS
v4 project and we don't need to check the version number again. This is
also necessary because your CSS file will now very likely contain
`@import "tailwindcss";` which doesn't exist in Tailwind CSS v3.
This also means that we can rely on the same internals that Tailwind CSS
actually uses for locating the source files. We will use
`@tailwindcss/oxide`'s scanner to find the source files (and it also
keeps your custom `@source` directives into account).
This PR also introduces a few actual migrations related to recent
features and changes we shipped.
1. We migrate deprecated classes to their new names:
| Before | After |
| --------------------- | --------------------- |
| `bg-left-top` | `bg-top-left` |
| `bg-left-bottom` | `bg-bottom-left` |
| `bg-right-top` | `bg-top-right` |
| `bg-right-bottom` | `bg-bottom-right` |
| `object-left-top` | `object-top-left` |
| `object-left-bottom` | `object-bottom-left` |
| `object-right-top` | `object-top-right` |
| `object-right-bottom` | `object-bottom-right` |
Introduced in:
- https://github.com/tailwindlabs/tailwindcss/pull/17378
- https://github.com/tailwindlabs/tailwindcss/pull/17437
2. We migrate simple arbitrary variants to their dedicated variant:
| Before | After |
| ----------------------- | ------------------- |
| `[&:user-valid]:flex` | `user-valid:flex` |
| `[&:user-invalid]:flex` | `user-invalid:flex` |
Introduced in:
- https://github.com/tailwindlabs/tailwindcss/pull/12370
3. We migrate `@media` variants to their dedicated variant:
| Before | After |
| ----------------------------------------------------- |
------------------------- |
| `[@media_print]:flex` | `print:flex` |
| `[@media(prefers-reduced-motion:no-preference)]:flex` |
`motion-safe:flex` |
| `[@media(prefers-reduced-motion:reduce)]:flex` | `motion-reduce:flex`
|
| `[@media(prefers-contrast:more)]:flex` | `contrast-more:flex` |
| `[@media(prefers-contrast:less)]:flex` | `contrast-less:flex` |
| `[@media(orientation:portrait)]:flex` | `portrait:flex` |
| `[@media(orientation:landscape)]:flex` | `landscape:flex` |
| `[@media(forced-colors:active)]:flex` | `forced-colors:flex` |
| `[@media(inverted-colors:inverted)]:flex` | `inverted-colors:flex` |
| `[@media(pointer:none)]:flex` | `pointer-none:flex` |
| `[@media(pointer:coarse)]:flex` | `pointer-coarse:flex` |
| `[@media(pointer:fine)]:flex` | `pointer-fine:flex` |
| `[@media(any-pointer:none)]:flex` | `any-pointer-none:flex` |
| `[@media(any-pointer:coarse)]:flex` | `any-pointer-coarse:flex` |
| `[@media(any-pointer:fine)]:flex` | `any-pointer-fine:flex` |
| `[@media(scripting:none)]:flex` | `noscript:flex` |
The new variants related to `inverted-colors`, `pointer`, `any-pointer`
and `scripting` were introduced in:
- https://github.com/tailwindlabs/tailwindcss/pull/11693
- https://github.com/tailwindlabs/tailwindcss/pull/16946
- https://github.com/tailwindlabs/tailwindcss/pull/11929
- https://github.com/tailwindlabs/tailwindcss/pull/17431
This also applies to the `not` case, e.g.:
| Before | After |
| --------------------------------------------------------- |
----------------------------- |
| `[@media_not_print]:flex` | `not-print:flex` |
| `[@media_not(prefers-reduced-motion:no-preference)]:flex` |
`not-motion-safe:flex` |
| `[@media_not(prefers-reduced-motion:reduce)]:flex` |
`not-motion-reduce:flex` |
| `[@media_not(prefers-contrast:more)]:flex` | `not-contrast-more:flex`
|
| `[@media_not(prefers-contrast:less)]:flex` | `not-contrast-less:flex`
|
| `[@media_not(orientation:portrait)]:flex` | `not-portrait:flex` |
| `[@media_not(orientation:landscape)]:flex` | `not-landscape:flex` |
| `[@media_not(forced-colors:active)]:flex` | `not-forced-colors:flex` |
| `[@media_not(inverted-colors:inverted)]:flex` |
`not-inverted-colors:flex` |
| `[@media_not(pointer:none)]:flex` | `not-pointer-none:flex` |
| `[@media_not(pointer:coarse)]:flex` | `not-pointer-coarse:flex` |
| `[@media_not(pointer:fine)]:flex` | `not-pointer-fine:flex` |
| `[@media_not(any-pointer:none)]:flex` | `not-any-pointer-none:flex` |
| `[@media_not(any-pointer:coarse)]:flex` |
`not-any-pointer-coarse:flex` |
| `[@media_not(any-pointer:fine)]:flex` | `not-any-pointer-fine:flex` |
| `[@media_not(scripting:none)]:flex` | `not-noscript:flex` |
For each candidate, we run a set of upgrade migrations. If at the end of
the migrations the original candidate is still the same as the new
candidate, then we will parse & print the candidate one more time to
pretty print into consistent classes. Luckily parsing is cached so there
is no real downside overhead.
Consistency (especially with arbitrary variants and values) will reduce
your CSS file because there will be fewer "versions" of your class.
Concretely, the pretty printing will apply changes such as:
| Before | After |
| ---------------------- | ----------------- |
| `bg-[var(--my-color)]` | `bg-(--my-color)` |
| `bg-[rgb(0,_0,_0)]` | `bg-[rgb(0,0,0)]` |
Another big important reason for this change is that these classes on
their own
would have been migrated _if_ another migration was relevant for this
candidate.
This means that there are were some inconsistencies. E.g.:
| Before | After | Reason |
| ----------------------- | ---------------------- |
------------------------------------ |
| `!bg-[var(--my-color)]` | `bg-(--my-color)!` | Because the `!` is in
the wrong spot |
| `bg-[var(--my-color)]` | `bg-[var(--my-color)]` | Because no
migrations rand |
As you can see, the way the `--my-color` variable is used, is different.
This
changes will make sure it will now always be consistent:
| Before | After |
| ----------------------- | ---------------------- |
| `!bg-[var(--my-color)]` | `bg-(--my-color)!` |
| `bg-[var(--my-color)]` | `bg-(--my-color)` |
Yay!
Of course, if you don't want these more cosmetic changes, you can always
ignore the upgrade and revert these changes and only commit the changes
you want.
# Test plan
- All existing tests still pass.
- But I had to delete 1 test (we tested that Tailwind CSS v3 was
required).
- And had to mock the `version.isMajor` call to ensure we run the
individual migration tests correctly.
- Added new tests to test:
1. Migrating Tailwind CSS v4 projects works
1. Idempotency of the upgrade tool
[ci-all]
2025-04-22 17:10:46 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@vitejs/plugin-react@6.0.2(vite@8.2.0(@types/node@25.9.1)(esbuild@0.27.7)(jiti@2.7.0)(terser@5.48.0)(yaml@2.9.0))':
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
2026-05-21 17:58:55 +02:00
|
|
|
'@rolldown/pluginutils': 1.0.1
|
2026-08-04 13:55:03 +02:00
|
|
|
vite: 8.2.0(@types/node@25.9.1)(esbuild@0.27.7)(jiti@2.7.0)(terser@5.48.0)(yaml@2.9.0)
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@vitest/expect@4.1.10':
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
2026-04-24 21:21:12 +02:00
|
|
|
'@standard-schema/spec': 1.1.0
|
2025-11-21 00:16:20 +01:00
|
|
|
'@types/chai': 5.2.3
|
2026-08-04 13:55:03 +02:00
|
|
|
'@vitest/spy': 4.1.10
|
|
|
|
|
'@vitest/utils': 4.1.10
|
2026-04-24 21:21:12 +02:00
|
|
|
chai: 6.2.2
|
|
|
|
|
tinyrainbow: 3.1.0
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@vitest/mocker@4.1.10(vite@8.2.0(@types/node@22.20.1)(esbuild@0.27.7)(jiti@2.7.0)(terser@5.48.0)(yaml@2.9.0))':
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@vitest/spy': 4.1.10
|
2025-11-21 00:16:20 +01:00
|
|
|
estree-walker: 3.0.3
|
|
|
|
|
magic-string: 0.30.21
|
|
|
|
|
optionalDependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
vite: 8.2.0(@types/node@22.20.1)(esbuild@0.27.7)(jiti@2.7.0)(terser@5.48.0)(yaml@2.9.0)
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@vitest/pretty-format@4.1.10':
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
2026-04-24 21:21:12 +02:00
|
|
|
tinyrainbow: 3.1.0
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@vitest/runner@4.1.10':
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@vitest/utils': 4.1.10
|
2025-11-21 00:16:20 +01:00
|
|
|
pathe: 2.0.3
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@vitest/snapshot@4.1.10':
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@vitest/pretty-format': 4.1.10
|
|
|
|
|
'@vitest/utils': 4.1.10
|
2025-11-21 00:16:20 +01:00
|
|
|
magic-string: 0.30.21
|
|
|
|
|
pathe: 2.0.3
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@vitest/spy@4.1.10': {}
|
2025-11-21 00:16:20 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
'@vitest/utils@4.1.10':
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@vitest/pretty-format': 4.1.10
|
2026-04-24 21:21:12 +02:00
|
|
|
convert-source-map: 2.0.0
|
|
|
|
|
tinyrainbow: 3.1.0
|
2024-03-05 14:23:26 +01:00
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
'@webassemblyjs/ast@1.14.1':
|
|
|
|
|
dependencies:
|
|
|
|
|
'@webassemblyjs/helper-numbers': 1.13.2
|
|
|
|
|
'@webassemblyjs/helper-wasm-bytecode': 1.13.2
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/floating-point-hex-parser@1.13.2': {}
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/helper-api-error@1.13.2': {}
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/helper-buffer@1.14.1': {}
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/helper-numbers@1.13.2':
|
|
|
|
|
dependencies:
|
|
|
|
|
'@webassemblyjs/floating-point-hex-parser': 1.13.2
|
|
|
|
|
'@webassemblyjs/helper-api-error': 1.13.2
|
|
|
|
|
'@xtuc/long': 4.2.2
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/helper-wasm-bytecode@1.13.2': {}
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/helper-wasm-section@1.14.1':
|
|
|
|
|
dependencies:
|
|
|
|
|
'@webassemblyjs/ast': 1.14.1
|
|
|
|
|
'@webassemblyjs/helper-buffer': 1.14.1
|
|
|
|
|
'@webassemblyjs/helper-wasm-bytecode': 1.13.2
|
|
|
|
|
'@webassemblyjs/wasm-gen': 1.14.1
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/ieee754@1.13.2':
|
|
|
|
|
dependencies:
|
|
|
|
|
'@xtuc/ieee754': 1.2.0
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/leb128@1.13.2':
|
|
|
|
|
dependencies:
|
|
|
|
|
'@xtuc/long': 4.2.2
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/utf8@1.13.2': {}
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/wasm-edit@1.14.1':
|
|
|
|
|
dependencies:
|
|
|
|
|
'@webassemblyjs/ast': 1.14.1
|
|
|
|
|
'@webassemblyjs/helper-buffer': 1.14.1
|
|
|
|
|
'@webassemblyjs/helper-wasm-bytecode': 1.13.2
|
|
|
|
|
'@webassemblyjs/helper-wasm-section': 1.14.1
|
|
|
|
|
'@webassemblyjs/wasm-gen': 1.14.1
|
|
|
|
|
'@webassemblyjs/wasm-opt': 1.14.1
|
|
|
|
|
'@webassemblyjs/wasm-parser': 1.14.1
|
|
|
|
|
'@webassemblyjs/wast-printer': 1.14.1
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/wasm-gen@1.14.1':
|
|
|
|
|
dependencies:
|
|
|
|
|
'@webassemblyjs/ast': 1.14.1
|
|
|
|
|
'@webassemblyjs/helper-wasm-bytecode': 1.13.2
|
|
|
|
|
'@webassemblyjs/ieee754': 1.13.2
|
|
|
|
|
'@webassemblyjs/leb128': 1.13.2
|
|
|
|
|
'@webassemblyjs/utf8': 1.13.2
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/wasm-opt@1.14.1':
|
|
|
|
|
dependencies:
|
|
|
|
|
'@webassemblyjs/ast': 1.14.1
|
|
|
|
|
'@webassemblyjs/helper-buffer': 1.14.1
|
|
|
|
|
'@webassemblyjs/wasm-gen': 1.14.1
|
|
|
|
|
'@webassemblyjs/wasm-parser': 1.14.1
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/wasm-parser@1.14.1':
|
|
|
|
|
dependencies:
|
|
|
|
|
'@webassemblyjs/ast': 1.14.1
|
|
|
|
|
'@webassemblyjs/helper-api-error': 1.13.2
|
|
|
|
|
'@webassemblyjs/helper-wasm-bytecode': 1.13.2
|
|
|
|
|
'@webassemblyjs/ieee754': 1.13.2
|
|
|
|
|
'@webassemblyjs/leb128': 1.13.2
|
|
|
|
|
'@webassemblyjs/utf8': 1.13.2
|
|
|
|
|
|
|
|
|
|
'@webassemblyjs/wast-printer@1.14.1':
|
|
|
|
|
dependencies:
|
|
|
|
|
'@webassemblyjs/ast': 1.14.1
|
|
|
|
|
'@xtuc/long': 4.2.2
|
|
|
|
|
|
|
|
|
|
'@xtuc/ieee754@1.2.0': {}
|
|
|
|
|
|
|
|
|
|
'@xtuc/long@4.2.2': {}
|
|
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
acorn@8.16.0: {}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
ajv-formats@2.1.1(ajv@8.20.0):
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
optionalDependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
ajv: 8.20.0
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
ajv-keywords@5.1.0(ajv@8.20.0):
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
ajv: 8.20.0
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
fast-deep-equal: 3.1.3
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
ajv@8.20.0:
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
dependencies:
|
|
|
|
|
fast-deep-equal: 3.1.3
|
2026-05-22 16:57:46 +02:00
|
|
|
fast-uri: 3.1.2
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
json-schema-traverse: 1.0.0
|
|
|
|
|
require-from-string: 2.0.2
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
any-promise@1.3.0: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
anymatch@3.1.3:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
|
|
|
|
normalize-path: 3.0.0
|
2026-05-22 16:57:46 +02:00
|
|
|
picomatch: 2.3.2
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-10-24 11:00:25 -04:00
|
|
|
arg@5.0.2: {}
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
argparse@2.0.1: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-08-02 10:33:14 +02:00
|
|
|
assertion-error@2.0.1: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
autoprefixer@10.5.0(postcss@8.5.25):
|
2024-10-24 11:00:25 -04:00
|
|
|
dependencies:
|
2026-04-23 12:51:20 +02:00
|
|
|
browserslist: 4.28.2
|
2026-05-22 16:57:46 +02:00
|
|
|
caniuse-lite: 1.0.30001793
|
2025-11-17 17:22:37 -05:00
|
|
|
fraction.js: 5.3.4
|
2024-10-24 11:00:25 -04:00
|
|
|
picocolors: 1.1.1
|
2026-08-04 13:55:03 +02:00
|
|
|
postcss: 8.5.25
|
2024-10-24 11:00:25 -04:00
|
|
|
postcss-value-parser: 4.2.0
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
baseline-browser-mapping@2.10.31: {}
|
2025-11-17 17:22:37 -05:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
before-after-hook@4.0.0: {}
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
binary-extensions@2.3.0: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
braces@3.0.3:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
2024-05-24 15:07:44 +02:00
|
|
|
fill-range: 7.1.1
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-04-23 12:51:20 +02:00
|
|
|
browserslist@4.28.2:
|
|
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
baseline-browser-mapping: 2.10.31
|
|
|
|
|
caniuse-lite: 1.0.30001793
|
|
|
|
|
electron-to-chromium: 1.5.361
|
|
|
|
|
node-releases: 2.0.46
|
2026-04-23 12:51:20 +02:00
|
|
|
update-browserslist-db: 1.2.3(browserslist@4.28.2)
|
|
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
buffer-from@1.1.2: {}
|
2024-09-04 10:09:24 +02:00
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
bun-types@1.3.14:
|
2024-09-02 15:23:46 +02:00
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@types/node': 25.9.1
|
2024-09-02 15:23:46 +02:00
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
bun@1.3.14:
|
2026-04-23 12:51:20 +02:00
|
|
|
optionalDependencies:
|
2026-05-21 17:58:55 +02:00
|
|
|
'@oven/bun-darwin-aarch64': 1.3.14
|
|
|
|
|
'@oven/bun-darwin-x64': 1.3.14
|
|
|
|
|
'@oven/bun-darwin-x64-baseline': 1.3.14
|
|
|
|
|
'@oven/bun-freebsd-aarch64': 1.3.14
|
|
|
|
|
'@oven/bun-freebsd-x64': 1.3.14
|
|
|
|
|
'@oven/bun-linux-aarch64': 1.3.14
|
|
|
|
|
'@oven/bun-linux-aarch64-android': 1.3.14
|
|
|
|
|
'@oven/bun-linux-aarch64-musl': 1.3.14
|
|
|
|
|
'@oven/bun-linux-x64': 1.3.14
|
|
|
|
|
'@oven/bun-linux-x64-android': 1.3.14
|
|
|
|
|
'@oven/bun-linux-x64-baseline': 1.3.14
|
|
|
|
|
'@oven/bun-linux-x64-musl': 1.3.14
|
|
|
|
|
'@oven/bun-linux-x64-musl-baseline': 1.3.14
|
|
|
|
|
'@oven/bun-windows-aarch64': 1.3.14
|
|
|
|
|
'@oven/bun-windows-x64': 1.3.14
|
|
|
|
|
'@oven/bun-windows-x64-baseline': 1.3.14
|
2026-04-23 12:51:20 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
bundle-require@5.1.0(esbuild@0.27.7):
|
2024-08-02 10:33:14 +02:00
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
esbuild: 0.27.7
|
2024-03-05 14:23:26 +01:00
|
|
|
load-tsconfig: 0.2.5
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
cac@6.7.14: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-10-24 11:00:25 -04:00
|
|
|
camelcase-css@2.0.1: {}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
caniuse-lite@1.0.30001793: {}
|
2026-04-23 12:51:20 +02:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
chai@6.2.2: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-01-06 12:44:27 +01:00
|
|
|
chardet@2.1.1: {}
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
chokidar@3.6.0:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
|
|
|
|
anymatch: 3.1.3
|
2024-05-24 15:07:44 +02:00
|
|
|
braces: 3.0.3
|
2024-03-05 14:23:26 +01:00
|
|
|
glob-parent: 5.1.2
|
|
|
|
|
is-binary-path: 2.1.0
|
|
|
|
|
is-glob: 4.0.3
|
|
|
|
|
normalize-path: 3.0.0
|
|
|
|
|
readdirp: 3.6.0
|
|
|
|
|
optionalDependencies:
|
|
|
|
|
fsevents: 2.3.3
|
|
|
|
|
|
2025-02-03 11:20:51 +01:00
|
|
|
chokidar@4.0.3:
|
|
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
readdirp: 4.1.2
|
2025-02-03 11:20:51 +01:00
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
chrome-trace-event@1.0.4: {}
|
|
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
citty@0.2.2: {}
|
2025-01-07 09:57:34 -05:00
|
|
|
|
2025-04-11 17:19:55 +02:00
|
|
|
cli-width@4.1.0: {}
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
client-only@0.0.1: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2025-04-11 17:19:55 +02:00
|
|
|
clipanion@4.0.0-rc.4(typanion@3.14.0):
|
|
|
|
|
dependencies:
|
|
|
|
|
typanion: 3.14.0
|
|
|
|
|
|
|
|
|
|
colorette@2.0.20: {}
|
|
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
commander@2.20.3: {}
|
2024-09-04 10:09:24 +02:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
commander@4.1.1: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2025-01-07 09:57:34 -05:00
|
|
|
confbox@0.1.8: {}
|
|
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
consola@3.4.2: {}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
content-type@2.0.0: {}
|
|
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
convert-source-map@2.0.0: {}
|
|
|
|
|
|
|
|
|
|
cookie-es@1.2.3: {}
|
2025-01-07 09:57:34 -05:00
|
|
|
|
2025-08-11 10:12:46 -04:00
|
|
|
crossws@0.3.5:
|
2025-02-14 11:44:43 +01:00
|
|
|
dependencies:
|
|
|
|
|
uncrypto: 0.1.3
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
crossws@0.4.10: {}
|
2026-05-22 16:57:46 +02:00
|
|
|
|
Add CSS codemods for migrating `@layer utilities` (#14455)
This PR adds CSS codemods for migrating existing `@layer utilities` to
`@utility` directives.
This PR has the ability to migrate the following cases:
---
The most basic case is when you want to migrate a simple class to a
utility directive.
Input:
```css
@layer utilities {
.foo {
color: red;
}
.bar {
color: blue;
}
}
```
Output:
```css
@utility foo {
color: red;
}
@utility bar {
color: blue;
}
```
You'll notice that the class `foo` will be used as the utility name, the
declarations (and the rest of the body of the rule) will become the body
of the `@utility` definition.
---
In v3, every class in a selector will become a utility. To correctly
migrate this to `@utility` directives, we have to register each class in
the selector and generate `n` utilities.
We can use nesting syntax, and replace the current class with `&` to
ensure that the final result behaves the same.
Input:
```css
@layer utilities {
.foo .bar .baz {
color: red;
}
}
```
Output:
```css
@utility foo {
& .bar .baz {
color: red;
}
}
@utility bar {
.foo & .baz {
color: red;
}
}
@utility .baz {
.foo .bar & {
color: red;
}
}
```
In this case, it could be that you know that some of them will never be
used as a utility (e.g.: `hover:bar`), but then you can safely remove
them.
---
Even classes inside of `:has(…)` will become a utility. The only
exception to the rule is that we don't do it for `:not(…)`.
Input:
```css
@layer utilities {
.foo .bar:not(.qux):has(.baz) {
display: none;
}
}
```
Output:
```css
@utility foo {
& .bar:not(.qux):has(.baz) {
display: none;
}
}
@utility bar {
.foo &:not(.qux):has(.baz) {
display: none;
}
}
@utility baz {
.foo .bar:not(.qux):has(&) {
display: none;
}
}
```
Notice that there is no `@utility qux` because it was used inside of
`:not(…)`.
---
When classes are nested inside at-rules, then these classes will also
become utilities. However, the `@utility <name>` will be at the top and
the at-rules will live inside of it. If there are multiple classes
inside a shared at-rule, then the at-rule will be duplicated for each
class.
Let's look at an example to make it more clear:
Input:
```css
@layer utilities {
@media (min-width: 640px) {
.foo {
color: red;
}
.bar {
color: blue;
}
@media (min-width: 1024px) {
.baz {
color: green;
}
@media (min-width: 1280px) {
.qux {
color: yellow;
}
}
}
}
}
```
Output:
```css
@utility foo {
@media (min-width: 640px) {
color: red;
}
}
@utility bar {
@media (min-width: 640px) {
color: blue;
}
}
@utility baz {
@media (min-width: 640px) {
@media (min-width: 1024px) {
color: green;
}
}
}
@utility qux {
@media (min-width: 640px) {
@media (min-width: 1024px) {
@media (min-width: 1280px) {
color: yellow;
}
}
}
}
```
---
When classes result in multiple `@utility` directives with the same
name, then the definitions will be merged together.
Input:
```css
@layer utilities {
.no-scrollbar::-webkit-scrollbar {
display: none;
}
.no-scrollbar {
-ms-overflow-style: none;
scrollbar-width: none;
}
}
```
Intermediate representation:
```css
@utility no-scrollbar {
&::-webkit-scrollbar {
display: none;
}
}
@utility no-scrollbar {
-ms-overflow-style: none;
scrollbar-width: none;
}
```
Output:
```css
@utility no-scrollbar {
&::-webkit-scrollbar {
display: none;
}
-ms-overflow-style: none;
scrollbar-width: none
}
```
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-09-24 18:17:09 +02:00
|
|
|
cssesc@3.0.0: {}
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
csstype@3.2.3: {}
|
|
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
debug@4.4.3:
|
|
|
|
|
dependencies:
|
|
|
|
|
ms: 2.1.3
|
|
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
dedent@1.7.2: {}
|
|
|
|
|
|
|
|
|
|
defu@6.1.7: {}
|
2025-01-07 09:57:34 -05:00
|
|
|
|
2025-05-05 10:30:10 +00:00
|
|
|
destr@2.0.5: {}
|
2025-01-07 09:57:34 -05:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
detect-libc@1.0.3: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
detect-libc@2.1.2: {}
|
2025-11-20 10:54:23 -05:00
|
|
|
|
2024-10-24 11:00:25 -04:00
|
|
|
didyoumean@1.2.2: {}
|
|
|
|
|
|
|
|
|
|
dlv@1.1.3: {}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
electron-to-chromium@1.5.361: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
emnapi@1.11.3(node-addon-api@8.7.0):
|
2025-04-11 17:19:55 +02:00
|
|
|
optionalDependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
node-addon-api: 8.7.0
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
enhanced-resolve@5.24.5:
|
2026-05-22 16:57:46 +02:00
|
|
|
dependencies:
|
|
|
|
|
graceful-fs: 4.2.11
|
|
|
|
|
tapable: 2.3.3
|
|
|
|
|
|
|
|
|
|
es-errors@1.3.0: {}
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
es-module-lexer@2.1.0: {}
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
es-toolkit@1.50.0: {}
|
2025-09-19 17:08:41 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
esbuild@0.27.7:
|
2024-11-13 11:38:43 +01:00
|
|
|
optionalDependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@esbuild/aix-ppc64': 0.27.7
|
|
|
|
|
'@esbuild/android-arm': 0.27.7
|
|
|
|
|
'@esbuild/android-arm64': 0.27.7
|
|
|
|
|
'@esbuild/android-x64': 0.27.7
|
|
|
|
|
'@esbuild/darwin-arm64': 0.27.7
|
|
|
|
|
'@esbuild/darwin-x64': 0.27.7
|
|
|
|
|
'@esbuild/freebsd-arm64': 0.27.7
|
|
|
|
|
'@esbuild/freebsd-x64': 0.27.7
|
|
|
|
|
'@esbuild/linux-arm': 0.27.7
|
|
|
|
|
'@esbuild/linux-arm64': 0.27.7
|
|
|
|
|
'@esbuild/linux-ia32': 0.27.7
|
|
|
|
|
'@esbuild/linux-loong64': 0.27.7
|
|
|
|
|
'@esbuild/linux-mips64el': 0.27.7
|
|
|
|
|
'@esbuild/linux-ppc64': 0.27.7
|
|
|
|
|
'@esbuild/linux-riscv64': 0.27.7
|
|
|
|
|
'@esbuild/linux-s390x': 0.27.7
|
|
|
|
|
'@esbuild/linux-x64': 0.27.7
|
|
|
|
|
'@esbuild/netbsd-arm64': 0.27.7
|
|
|
|
|
'@esbuild/netbsd-x64': 0.27.7
|
|
|
|
|
'@esbuild/openbsd-arm64': 0.27.7
|
|
|
|
|
'@esbuild/openbsd-x64': 0.27.7
|
|
|
|
|
'@esbuild/openharmony-arm64': 0.27.7
|
|
|
|
|
'@esbuild/sunos-x64': 0.27.7
|
|
|
|
|
'@esbuild/win32-arm64': 0.27.7
|
|
|
|
|
'@esbuild/win32-ia32': 0.27.7
|
|
|
|
|
'@esbuild/win32-x64': 0.27.7
|
2025-11-19 18:18:45 -05:00
|
|
|
|
2024-10-24 11:00:25 -04:00
|
|
|
escalade@3.2.0: {}
|
|
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
eslint-scope@5.1.1:
|
|
|
|
|
dependencies:
|
|
|
|
|
esrecurse: 4.3.0
|
|
|
|
|
estraverse: 4.3.0
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
esrecurse@4.3.0:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
|
|
|
|
estraverse: 5.3.0
|
|
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
estraverse@4.3.0: {}
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
estraverse@5.3.0: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
estree-walker@3.0.3:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@types/estree': 1.0.9
|
2024-03-05 14:23:26 +01:00
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
events@3.3.0: {}
|
|
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
expect-type@1.3.0: {}
|
2025-11-21 00:16:20 +01:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
fast-content-type-parse@3.0.0: {}
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
fast-deep-equal@3.1.3: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2025-12-26 12:36:51 -05:00
|
|
|
fast-equals@5.4.0: {}
|
|
|
|
|
|
2025-01-13 11:11:35 +01:00
|
|
|
fast-glob@3.3.3:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
|
|
|
|
'@nodelib/fs.stat': 2.0.5
|
|
|
|
|
'@nodelib/fs.walk': 1.2.8
|
|
|
|
|
glob-parent: 5.1.2
|
|
|
|
|
merge2: 1.4.1
|
2025-01-13 11:11:35 +01:00
|
|
|
micromatch: 4.0.8
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-04-26 17:49:06 +02:00
|
|
|
fast-string-truncated-width@3.0.3: {}
|
|
|
|
|
|
|
|
|
|
fast-string-width@3.0.2:
|
|
|
|
|
dependencies:
|
|
|
|
|
fast-string-truncated-width: 3.0.3
|
|
|
|
|
|
2025-12-26 12:36:51 -05:00
|
|
|
fast-stringify@4.0.0: {}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
fast-uri@3.1.2: {}
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
fast-wrap-ansi@0.2.2:
|
2026-04-26 17:49:06 +02:00
|
|
|
dependencies:
|
|
|
|
|
fast-string-width: 3.0.2
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
fastq@1.20.1:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
reusify: 1.1.0
|
2025-06-24 18:31:17 +02:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
fdir@6.5.0(picomatch@4.0.4):
|
|
|
|
|
optionalDependencies:
|
|
|
|
|
picomatch: 4.0.4
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
fdir@6.5.0(picomatch@4.0.5):
|
|
|
|
|
optionalDependencies:
|
|
|
|
|
picomatch: 4.0.5
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
fill-range@7.1.1:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
|
|
|
|
to-regex-range: 5.0.1
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
find-up-simple@1.0.1: {}
|
Add integration test setup and tests for the Vite integration (#14089)
This PR adds a new root `/integrations` folder that will be the home of
integration tests. The idea of these tests is to use Tailwind in various
setups just like our users would (by only using the publishable npm
builds).
To avoid issues with concurrent tests making changes to the file system,
to make it very easy to test through a range of versions, and to avoid
changing configuration objects over and over in test runs, we decided to
inline the scaffolding completely into the test file and have no
examples checked into the repo.
Here's an example of how this can look like for a simple Vite test:
```ts
test('works with production builds', {
fs: {
'package.json': json`
{
"type": "module",
"dependencies": {
"@tailwindcss/vite": "workspace:^",
"tailwindcss": "workspace:^"
},
"devDependencies": {
"vite": "^5.3.5"
}
}
`,
'vite.config.ts': ts`
import tailwindcss from '@tailwindcss/vite'
import { defineConfig } from 'vite'
export default defineConfig({
build: { cssMinify: false },
plugins: [tailwindcss()],
})
`,
'index.html': html`
<head>
<link rel="stylesheet" href="./src/index.css">
</head>
<body>
<div class="underline m-2">Hello, world!</div>
</body>
`,
'src/index.css': css`
@import 'tailwindcss/theme' reference;
@import 'tailwindcss/utilities';
`,
},
},
async ({ fs, exec }) => {
await exec('pnpm vite build')
expect.assertions(2)
for (let [path, content] of await fs.glob('dist/**/*.css')) {
expect(path).toMatch(/\.css$/)
expect(stripTailwindComment(content)).toMatchInlineSnapshot(
`
".m-2 {
margin: var(--spacing-2, .5rem);
}
.underline {
text-decoration-line: underline;
}"
`,
)
}
},
)
```
By defining all dependencies this way, we never have to worry about
which fixtures are checked in and can more easily describe changes to
the setup.
For ergonomics, we've also added the [`embed` prettier
plugin](https://github.com/Sec-ant/prettier-plugin-embed). This will
mean that files inlined in the `fs` setup are properly indented. No
extra work needed!
If you're using VS Code, I can also recommend the [Language
Literals](https://marketplace.visualstudio.com/items?itemName=sissel.language-literals)
extension so that syntax highlighting also _just works_.
A neat feature of inlining the scaffolding like this is to make it very
simple to test through a variety of versions. For example, here's how we
can set up a test against Vite 5 and Vite 4:
```js
;['^4.5.3', '^5.3.5'].forEach(viteVersion => {
test(`works with production builds for Vite ${viteVersion}`, {
fs: {
'package.json': json`
{
"type": "module",
"devDependencies": {
"vite": "${viteVersion}"
}
}
`,
async () => {
// Do something
},
)
})
```
## Philosophy
Before we dive into the specifics, I want to clearly state the design
considerations we have chosen for this new test suite:
- All file mutations should be done in temp folders, nothing should ever
mess with your working directory
- Windows as a first-class citizen
- Have a clean and simple API that describes the test setup only using
public APIs
- Focus on reliability (make sure cleanup scripts work and are tolerant
to various error scenarios)
- If a user reports an issue with a specific configuration, we want to
be able to reproduce them with integration tests, no matter how obscure
the setup (this means the test need to be in control of most of the
variables)
- Tests should be reasonably fast (obviously this depends on the
integration. If we use a slow build tool, we can't magically speed it
up, but our overhead should be minimal).
## How it works
The current implementation provides a custom `test` helper function
that, when used, sets up the environment according to the configuration.
It'll create a new temporary directory and create all files, ensuring
things like proper `\r\n` line endings on Windows.
We do have to patch the `package.json` specifically, since we can not
use public versions of the tailwindcss packages as we want to be able to
test against a development build. To make this happen, every `pnpm
build` run now creates tarballs of the npm modules (that contain only
the files that would also in the published build). We then patch the
`package.json` to rewrite `workspace:^` versions to link to those
tarballs. We found this to work reliably on Windows and macOS as well as
being fast enough to not cause any issues. Furthermore we also decided
to use `pnpm` as the version manager for integration tests because of
it's global module cache (so installing `vite` is fast as soon as you
installed it once).
The test function will receive a few utilities that it can use to more
easily interact with the temp dir. One example is a `fs.glob` function
that you can use to easily find files in eventual `dist/` directories or
helpers around `spawn` and `exec` that make sure that processes are
cleaned up correctly.
Because we use tarballs from our build dependencies, working on changes
requires a workflow where you run `pnpm build` before running `pnpm
test:integrations`. However it also means we can run clients like our
CLI client with no additional overhead—just install the dependency like
any user would and set up your test cases this way.
## Test plan
This PR also includes two Vite specific integration tests: One testing a
static build (`pnpm vite build`) and one a dev mode build (`pnpm vite
dev`) that also makes changes to the file system and asserts that the
resources properly update.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-08-02 11:50:49 +02:00
|
|
|
|
2025-05-29 13:38:00 -04:00
|
|
|
fix-dts-default-cjs-exports@1.0.1:
|
|
|
|
|
dependencies:
|
2025-10-31 07:34:21 -04:00
|
|
|
magic-string: 0.30.21
|
2026-05-22 16:57:46 +02:00
|
|
|
mlly: 1.8.2
|
|
|
|
|
rollup: 4.60.4
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2025-11-17 17:22:37 -05:00
|
|
|
fraction.js@5.3.4: {}
|
2024-10-24 11:00:25 -04:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
fsevents@2.3.2:
|
2024-03-05 14:23:26 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
fsevents@2.3.3:
|
2024-03-05 14:23:26 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
function-bind@1.1.2: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
get-port-please@3.2.0: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
glob-parent@5.1.2:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
|
|
|
|
is-glob: 4.0.3
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
glob-parent@6.0.2:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
|
|
|
|
is-glob: 4.0.3
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
globby@16.2.2:
|
2024-09-18 16:45:43 +02:00
|
|
|
dependencies:
|
2025-10-06 11:14:31 +02:00
|
|
|
'@sindresorhus/merge-streams': 4.0.0
|
2025-01-13 11:11:35 +01:00
|
|
|
fast-glob: 3.3.3
|
2025-10-06 11:14:31 +02:00
|
|
|
ignore: 7.0.5
|
2026-04-24 21:21:12 +02:00
|
|
|
is-path-inside: 4.0.0
|
2024-09-18 16:45:43 +02:00
|
|
|
slash: 5.1.0
|
2026-04-24 21:21:12 +02:00
|
|
|
unicorn-magic: 0.4.0
|
2024-09-18 16:45:43 +02:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
graceful-fs@4.2.11: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
h3@1.15.11:
|
2025-01-07 09:57:34 -05:00
|
|
|
dependencies:
|
2026-04-24 21:21:12 +02:00
|
|
|
cookie-es: 1.2.3
|
2025-08-11 10:12:46 -04:00
|
|
|
crossws: 0.3.5
|
2026-04-24 21:21:12 +02:00
|
|
|
defu: 6.1.7
|
2025-05-05 10:30:10 +00:00
|
|
|
destr: 2.0.5
|
2025-01-07 09:57:34 -05:00
|
|
|
iron-webcrypto: 1.2.1
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
node-mock-http: 1.0.4
|
2025-01-07 09:57:34 -05:00
|
|
|
radix3: 1.1.2
|
2026-05-22 16:57:46 +02:00
|
|
|
ufo: 1.6.4
|
2025-01-07 09:57:34 -05:00
|
|
|
uncrypto: 0.1.3
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
has-flag@4.0.0: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
hasown@2.0.3:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
|
|
|
|
function-bind: 1.1.2
|
|
|
|
|
|
2025-01-07 09:57:34 -05:00
|
|
|
http-shutdown@1.2.2: {}
|
|
|
|
|
|
2026-04-26 17:49:06 +02:00
|
|
|
iconv-lite@0.7.2:
|
2025-04-11 17:19:55 +02:00
|
|
|
dependencies:
|
|
|
|
|
safer-buffer: 2.1.2
|
|
|
|
|
|
2025-10-06 11:14:31 +02:00
|
|
|
ignore@7.0.5: {}
|
2025-02-17 12:06:53 +01:00
|
|
|
|
2025-01-07 09:57:34 -05:00
|
|
|
iron-webcrypto@1.2.1: {}
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
is-binary-path@2.1.0:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
2024-05-24 15:07:44 +02:00
|
|
|
binary-extensions: 2.3.0
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
is-core-module@2.16.2:
|
2024-10-24 11:00:25 -04:00
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
hasown: 2.0.3
|
2024-10-24 11:00:25 -04:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
is-extglob@2.1.1: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
is-glob@4.0.3:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
|
|
|
|
is-extglob: 2.1.1
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
is-number@7.0.0: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
is-path-inside@4.0.0: {}
|
2025-01-07 09:57:34 -05:00
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
jest-worker@27.5.1:
|
|
|
|
|
dependencies:
|
2026-07-02 11:45:49 +02:00
|
|
|
'@types/node': 25.9.1
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
merge-stream: 2.0.0
|
|
|
|
|
supports-color: 8.1.1
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
jiti@1.21.7: {}
|
2024-10-24 11:00:25 -04:00
|
|
|
|
2026-05-13 12:02:13 +02:00
|
|
|
jiti@2.7.0: {}
|
2025-07-31 11:48:58 -04:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
joycon@3.1.1: {}
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
js-yaml@4.3.1:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
|
|
|
|
argparse: 2.0.1
|
|
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
json-schema-traverse@1.0.0: {}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
json-with-bigint@3.5.8: {}
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss-android-arm64@1.33.0:
|
2026-03-12 20:54:34 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss-darwin-arm64@1.33.0: {}
|
2026-03-12 20:54:34 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss-darwin-x64@1.33.0: {}
|
2025-03-11 17:39:30 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss-freebsd-x64@1.33.0:
|
2026-03-12 20:54:34 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss-linux-arm-gnueabihf@1.33.0:
|
2026-03-12 20:54:34 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss-linux-arm64-gnu@1.33.0: {}
|
2025-03-11 17:39:30 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss-linux-arm64-musl@1.33.0: {}
|
2026-03-12 20:54:34 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss-linux-x64-gnu@1.33.0: {}
|
2026-03-12 20:54:34 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss-linux-x64-musl@1.33.0: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss-win32-arm64-msvc@1.33.0:
|
2026-03-12 20:54:34 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss-win32-x64-msvc@1.33.0: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss@1.33.0(patch_hash=1d4a8800d60d13d42887b88b3a86576df4b451670308145fb432ec8abbf40930):
|
2026-03-12 20:54:34 +01:00
|
|
|
dependencies:
|
|
|
|
|
detect-libc: 2.1.2
|
|
|
|
|
optionalDependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss-android-arm64: 1.33.0
|
|
|
|
|
lightningcss-darwin-arm64: 1.33.0
|
|
|
|
|
lightningcss-darwin-x64: 1.33.0
|
|
|
|
|
lightningcss-freebsd-x64: 1.33.0
|
|
|
|
|
lightningcss-linux-arm-gnueabihf: 1.33.0
|
|
|
|
|
lightningcss-linux-arm64-gnu: 1.33.0
|
|
|
|
|
lightningcss-linux-arm64-musl: 1.33.0
|
|
|
|
|
lightningcss-linux-x64-gnu: 1.33.0
|
|
|
|
|
lightningcss-linux-x64-musl: 1.33.0
|
|
|
|
|
lightningcss-win32-arm64-msvc: 1.33.0
|
|
|
|
|
lightningcss-win32-x64-msvc: 1.33.0
|
2026-03-12 20:54:34 +01:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
lilconfig@3.1.3: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
lines-and-columns@1.2.4: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
listhen@1.10.1(@parcel/watcher@2.6.0(patch_hash=705ce75ccea54337110c4d7fe0a8b421658ea0c23e1a77c1fa890a86041179da)):
|
2025-01-07 09:57:34 -05:00
|
|
|
dependencies:
|
2026-04-24 21:21:12 +02:00
|
|
|
'@parcel/watcher-wasm': 2.5.6
|
|
|
|
|
citty: 0.2.2
|
|
|
|
|
consola: 3.4.2
|
2026-08-04 13:55:03 +02:00
|
|
|
crossws: 0.4.10
|
2026-04-24 21:21:12 +02:00
|
|
|
defu: 6.1.7
|
|
|
|
|
get-port-please: 3.2.0
|
|
|
|
|
h3: 1.15.11
|
2025-01-07 09:57:34 -05:00
|
|
|
http-shutdown: 1.2.2
|
2026-05-13 12:02:13 +02:00
|
|
|
jiti: 2.7.0
|
2026-04-24 21:21:12 +02:00
|
|
|
node-forge: 1.4.0
|
|
|
|
|
pathe: 2.0.3
|
2026-08-04 13:55:03 +02:00
|
|
|
std-env: 4.2.0
|
|
|
|
|
tinyclip: 0.1.15
|
2026-05-07 12:43:28 +00:00
|
|
|
ufo: 1.6.4
|
2026-08-04 13:55:03 +02:00
|
|
|
untun: 0.2.2
|
2026-05-07 12:43:28 +00:00
|
|
|
uqr: 0.1.3
|
2026-08-04 13:55:03 +02:00
|
|
|
optionalDependencies:
|
|
|
|
|
'@parcel/watcher': 2.6.0(patch_hash=705ce75ccea54337110c4d7fe0a8b421658ea0c23e1a77c1fa890a86041179da)
|
2026-05-22 16:57:46 +02:00
|
|
|
transitivePeerDependencies:
|
|
|
|
|
- srvx
|
2025-01-07 09:57:34 -05:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
load-tsconfig@0.2.5: {}
|
|
|
|
|
|
2025-10-31 07:34:21 -04:00
|
|
|
magic-string@0.30.21:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
2025-08-29 14:22:19 +00:00
|
|
|
'@jridgewell/sourcemap-codec': 1.5.5
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
magic-string@1.1.0:
|
|
|
|
|
dependencies:
|
|
|
|
|
'@jridgewell/sourcemap-codec': 1.5.5
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
merge-stream@2.0.0: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
merge2@1.4.1: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2025-12-26 12:36:51 -05:00
|
|
|
micro-memoize@5.1.1:
|
|
|
|
|
dependencies:
|
|
|
|
|
fast-equals: 5.4.0
|
|
|
|
|
fast-stringify: 4.0.0
|
Add integration test setup and tests for the Vite integration (#14089)
This PR adds a new root `/integrations` folder that will be the home of
integration tests. The idea of these tests is to use Tailwind in various
setups just like our users would (by only using the publishable npm
builds).
To avoid issues with concurrent tests making changes to the file system,
to make it very easy to test through a range of versions, and to avoid
changing configuration objects over and over in test runs, we decided to
inline the scaffolding completely into the test file and have no
examples checked into the repo.
Here's an example of how this can look like for a simple Vite test:
```ts
test('works with production builds', {
fs: {
'package.json': json`
{
"type": "module",
"dependencies": {
"@tailwindcss/vite": "workspace:^",
"tailwindcss": "workspace:^"
},
"devDependencies": {
"vite": "^5.3.5"
}
}
`,
'vite.config.ts': ts`
import tailwindcss from '@tailwindcss/vite'
import { defineConfig } from 'vite'
export default defineConfig({
build: { cssMinify: false },
plugins: [tailwindcss()],
})
`,
'index.html': html`
<head>
<link rel="stylesheet" href="./src/index.css">
</head>
<body>
<div class="underline m-2">Hello, world!</div>
</body>
`,
'src/index.css': css`
@import 'tailwindcss/theme' reference;
@import 'tailwindcss/utilities';
`,
},
},
async ({ fs, exec }) => {
await exec('pnpm vite build')
expect.assertions(2)
for (let [path, content] of await fs.glob('dist/**/*.css')) {
expect(path).toMatch(/\.css$/)
expect(stripTailwindComment(content)).toMatchInlineSnapshot(
`
".m-2 {
margin: var(--spacing-2, .5rem);
}
.underline {
text-decoration-line: underline;
}"
`,
)
}
},
)
```
By defining all dependencies this way, we never have to worry about
which fixtures are checked in and can more easily describe changes to
the setup.
For ergonomics, we've also added the [`embed` prettier
plugin](https://github.com/Sec-ant/prettier-plugin-embed). This will
mean that files inlined in the `fs` setup are properly indented. No
extra work needed!
If you're using VS Code, I can also recommend the [Language
Literals](https://marketplace.visualstudio.com/items?itemName=sissel.language-literals)
extension so that syntax highlighting also _just works_.
A neat feature of inlining the scaffolding like this is to make it very
simple to test through a variety of versions. For example, here's how we
can set up a test against Vite 5 and Vite 4:
```js
;['^4.5.3', '^5.3.5'].forEach(viteVersion => {
test(`works with production builds for Vite ${viteVersion}`, {
fs: {
'package.json': json`
{
"type": "module",
"devDependencies": {
"vite": "${viteVersion}"
}
}
`,
async () => {
// Do something
},
)
})
```
## Philosophy
Before we dive into the specifics, I want to clearly state the design
considerations we have chosen for this new test suite:
- All file mutations should be done in temp folders, nothing should ever
mess with your working directory
- Windows as a first-class citizen
- Have a clean and simple API that describes the test setup only using
public APIs
- Focus on reliability (make sure cleanup scripts work and are tolerant
to various error scenarios)
- If a user reports an issue with a specific configuration, we want to
be able to reproduce them with integration tests, no matter how obscure
the setup (this means the test need to be in control of most of the
variables)
- Tests should be reasonably fast (obviously this depends on the
integration. If we use a slow build tool, we can't magically speed it
up, but our overhead should be minimal).
## How it works
The current implementation provides a custom `test` helper function
that, when used, sets up the environment according to the configuration.
It'll create a new temporary directory and create all files, ensuring
things like proper `\r\n` line endings on Windows.
We do have to patch the `package.json` specifically, since we can not
use public versions of the tailwindcss packages as we want to be able to
test against a development build. To make this happen, every `pnpm
build` run now creates tarballs of the npm modules (that contain only
the files that would also in the published build). We then patch the
`package.json` to rewrite `workspace:^` versions to link to those
tarballs. We found this to work reliably on Windows and macOS as well as
being fast enough to not cause any issues. Furthermore we also decided
to use `pnpm` as the version manager for integration tests because of
it's global module cache (so installing `vite` is fast as soon as you
installed it once).
The test function will receive a few utilities that it can use to more
easily interact with the temp dir. One example is a `fs.glob` function
that you can use to easily find files in eventual `dist/` directories or
helpers around `spawn` and `exec` that make sure that processes are
cleaned up correctly.
Because we use tarballs from our build dependencies, working on changes
requires a workflow where you run `pnpm build` before running `pnpm
test:integrations`. However it also means we can run clients like our
CLI client with no additional overhead—just install the dependency like
any user would and set up your test cases this way.
## Test plan
This PR also includes two Vite specific integration tests: One testing a
static build (`pnpm vite build`) and one a dev mode build (`pnpm vite
dev`) that also makes changes to the file system and asserts that the
resources properly update.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-08-02 11:50:49 +02:00
|
|
|
|
2025-01-13 11:11:35 +01:00
|
|
|
micromatch@4.0.8:
|
|
|
|
|
dependencies:
|
|
|
|
|
braces: 3.0.3
|
2026-05-22 16:57:46 +02:00
|
|
|
picomatch: 2.3.2
|
2025-01-13 11:11:35 +01:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
mime-db@1.54.0: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-11-19 16:19:08 +01:00
|
|
|
mini-svg-data-uri@1.4.4: {}
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
minimizer-webpack-plugin@5.6.1(esbuild@0.27.7)(postcss@8.5.25)(webpack@5.109.2(esbuild@0.27.7)(postcss@8.5.25)):
|
2026-07-02 11:45:49 +02:00
|
|
|
dependencies:
|
|
|
|
|
'@jridgewell/trace-mapping': 0.3.31
|
|
|
|
|
jest-worker: 27.5.1
|
|
|
|
|
schema-utils: 4.3.3
|
|
|
|
|
terser: 5.48.0
|
2026-08-04 13:55:03 +02:00
|
|
|
webpack: 5.109.2(esbuild@0.27.7)(postcss@8.5.25)
|
2026-07-02 11:45:49 +02:00
|
|
|
optionalDependencies:
|
|
|
|
|
esbuild: 0.27.7
|
2026-08-04 13:55:03 +02:00
|
|
|
postcss: 8.5.25
|
2026-07-02 11:45:49 +02:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
mlly@1.8.2:
|
|
|
|
|
dependencies:
|
|
|
|
|
acorn: 8.16.0
|
|
|
|
|
pathe: 2.0.3
|
|
|
|
|
pkg-types: 1.3.1
|
2026-05-07 12:43:28 +00:00
|
|
|
ufo: 1.6.4
|
2026-04-24 21:21:12 +02:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
mri@1.2.0: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
ms@2.1.3: {}
|
|
|
|
|
|
2026-04-26 17:49:06 +02:00
|
|
|
mute-stream@3.0.0: {}
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
mz@2.7.0:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
|
|
|
|
any-promise: 1.3.0
|
|
|
|
|
object-assign: 4.1.1
|
|
|
|
|
thenify-all: 1.6.0
|
|
|
|
|
|
2026-05-21 17:58:55 +02:00
|
|
|
nanoid@3.3.12: {}
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
nanoid@3.3.16: {}
|
|
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
neo-async@2.6.2: {}
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
next@16.2.7(@playwright/test@1.62.1)(react-dom@19.2.7(react@19.2.7))(react@19.2.7):
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
2026-06-09 12:38:33 +02:00
|
|
|
'@next/env': 16.2.7
|
2025-01-06 11:18:39 +01:00
|
|
|
'@swc/helpers': 0.5.15
|
2026-05-22 16:57:46 +02:00
|
|
|
baseline-browser-mapping: 2.10.31
|
|
|
|
|
caniuse-lite: 1.0.30001793
|
2024-03-05 14:23:26 +01:00
|
|
|
postcss: 8.4.31
|
2026-06-09 10:44:01 +00:00
|
|
|
react: 19.2.7
|
|
|
|
|
react-dom: 19.2.7(react@19.2.7)
|
|
|
|
|
styled-jsx: 5.1.6(react@19.2.7)
|
2024-03-05 14:23:26 +01:00
|
|
|
optionalDependencies:
|
2026-06-09 12:38:33 +02:00
|
|
|
'@next/swc-darwin-arm64': 16.2.7
|
|
|
|
|
'@next/swc-darwin-x64': 16.2.7
|
|
|
|
|
'@next/swc-linux-arm64-gnu': 16.2.7
|
|
|
|
|
'@next/swc-linux-arm64-musl': 16.2.7
|
|
|
|
|
'@next/swc-linux-x64-gnu': 16.2.7
|
|
|
|
|
'@next/swc-linux-x64-musl': 16.2.7
|
|
|
|
|
'@next/swc-win32-arm64-msvc': 16.2.7
|
|
|
|
|
'@next/swc-win32-x64-msvc': 16.2.7
|
2026-08-04 13:55:03 +02:00
|
|
|
'@playwright/test': 1.62.1
|
2025-11-20 10:54:23 -05:00
|
|
|
sharp: 0.34.5
|
2024-03-05 14:23:26 +01:00
|
|
|
transitivePeerDependencies:
|
|
|
|
|
- '@babel/core'
|
|
|
|
|
- babel-plugin-macros
|
|
|
|
|
|
2024-08-02 10:33:14 +02:00
|
|
|
node-addon-api@7.1.1: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
node-addon-api@8.7.0: {}
|
2025-01-10 10:26:48 +01:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
node-forge@1.4.0: {}
|
2025-01-07 09:57:34 -05:00
|
|
|
|
2025-01-10 10:26:48 +01:00
|
|
|
node-gyp-build@4.8.4: {}
|
|
|
|
|
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
node-mock-http@1.0.4: {}
|
2025-02-14 11:44:43 +01:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
node-releases@2.0.46: {}
|
2026-04-23 12:51:20 +02:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
normalize-path@3.0.0: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
object-assign@4.1.1: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-10-24 11:00:25 -04:00
|
|
|
object-hash@3.0.0: {}
|
|
|
|
|
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
obug@2.1.1: {}
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
obug@2.1.4: {}
|
|
|
|
|
|
Add integration test setup and tests for the Vite integration (#14089)
This PR adds a new root `/integrations` folder that will be the home of
integration tests. The idea of these tests is to use Tailwind in various
setups just like our users would (by only using the publishable npm
builds).
To avoid issues with concurrent tests making changes to the file system,
to make it very easy to test through a range of versions, and to avoid
changing configuration objects over and over in test runs, we decided to
inline the scaffolding completely into the test file and have no
examples checked into the repo.
Here's an example of how this can look like for a simple Vite test:
```ts
test('works with production builds', {
fs: {
'package.json': json`
{
"type": "module",
"dependencies": {
"@tailwindcss/vite": "workspace:^",
"tailwindcss": "workspace:^"
},
"devDependencies": {
"vite": "^5.3.5"
}
}
`,
'vite.config.ts': ts`
import tailwindcss from '@tailwindcss/vite'
import { defineConfig } from 'vite'
export default defineConfig({
build: { cssMinify: false },
plugins: [tailwindcss()],
})
`,
'index.html': html`
<head>
<link rel="stylesheet" href="./src/index.css">
</head>
<body>
<div class="underline m-2">Hello, world!</div>
</body>
`,
'src/index.css': css`
@import 'tailwindcss/theme' reference;
@import 'tailwindcss/utilities';
`,
},
},
async ({ fs, exec }) => {
await exec('pnpm vite build')
expect.assertions(2)
for (let [path, content] of await fs.glob('dist/**/*.css')) {
expect(path).toMatch(/\.css$/)
expect(stripTailwindComment(content)).toMatchInlineSnapshot(
`
".m-2 {
margin: var(--spacing-2, .5rem);
}
.underline {
text-decoration-line: underline;
}"
`,
)
}
},
)
```
By defining all dependencies this way, we never have to worry about
which fixtures are checked in and can more easily describe changes to
the setup.
For ergonomics, we've also added the [`embed` prettier
plugin](https://github.com/Sec-ant/prettier-plugin-embed). This will
mean that files inlined in the `fs` setup are properly indented. No
extra work needed!
If you're using VS Code, I can also recommend the [Language
Literals](https://marketplace.visualstudio.com/items?itemName=sissel.language-literals)
extension so that syntax highlighting also _just works_.
A neat feature of inlining the scaffolding like this is to make it very
simple to test through a variety of versions. For example, here's how we
can set up a test against Vite 5 and Vite 4:
```js
;['^4.5.3', '^5.3.5'].forEach(viteVersion => {
test(`works with production builds for Vite ${viteVersion}`, {
fs: {
'package.json': json`
{
"type": "module",
"devDependencies": {
"vite": "${viteVersion}"
}
}
`,
async () => {
// Do something
},
)
})
```
## Philosophy
Before we dive into the specifics, I want to clearly state the design
considerations we have chosen for this new test suite:
- All file mutations should be done in temp folders, nothing should ever
mess with your working directory
- Windows as a first-class citizen
- Have a clean and simple API that describes the test setup only using
public APIs
- Focus on reliability (make sure cleanup scripts work and are tolerant
to various error scenarios)
- If a user reports an issue with a specific configuration, we want to
be able to reproduce them with integration tests, no matter how obscure
the setup (this means the test need to be in control of most of the
variables)
- Tests should be reasonably fast (obviously this depends on the
integration. If we use a slow build tool, we can't magically speed it
up, but our overhead should be minimal).
## How it works
The current implementation provides a custom `test` helper function
that, when used, sets up the environment according to the configuration.
It'll create a new temporary directory and create all files, ensuring
things like proper `\r\n` line endings on Windows.
We do have to patch the `package.json` specifically, since we can not
use public versions of the tailwindcss packages as we want to be able to
test against a development build. To make this happen, every `pnpm
build` run now creates tarballs of the npm modules (that contain only
the files that would also in the published build). We then patch the
`package.json` to rewrite `workspace:^` versions to link to those
tarballs. We found this to work reliably on Windows and macOS as well as
being fast enough to not cause any issues. Furthermore we also decided
to use `pnpm` as the version manager for integration tests because of
it's global module cache (so installing `vite` is fast as soon as you
installed it once).
The test function will receive a few utilities that it can use to more
easily interact with the temp dir. One example is a `fs.glob` function
that you can use to easily find files in eventual `dist/` directories or
helpers around `spawn` and `exec` that make sure that processes are
cleaned up correctly.
Because we use tarballs from our build dependencies, working on changes
requires a workflow where you run `pnpm build` before running `pnpm
test:integrations`. However it also means we can run clients like our
CLI client with no additional overhead—just install the dependency like
any user would and set up your test cases this way.
## Test plan
This PR also includes two Vite specific integration tests: One testing a
static build (`pnpm vite build`) and one a dev mode build (`pnpm vite
dev`) that also makes changes to the file system and asserts that the
resources properly update.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-08-02 11:50:49 +02:00
|
|
|
package-up@5.0.0:
|
|
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
find-up-simple: 1.0.1
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
path-parse@1.0.7: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2025-05-29 13:38:00 -04:00
|
|
|
pathe@2.0.3: {}
|
|
|
|
|
|
2024-10-24 11:25:50 +02:00
|
|
|
picocolors@1.1.1: {}
|
2024-10-03 11:15:18 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
picomatch@2.3.2: {}
|
2025-02-03 11:20:51 +01:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
picomatch@4.0.4: {}
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
picomatch@4.0.5: {}
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
pify@2.3.0: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
pirates@4.0.7: {}
|
2025-01-07 09:57:34 -05:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
pkg-types@1.3.1:
|
|
|
|
|
dependencies:
|
|
|
|
|
confbox: 0.1.8
|
|
|
|
|
mlly: 1.8.2
|
|
|
|
|
pathe: 2.0.3
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
playwright-core@1.62.1: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
playwright@1.62.1:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
playwright-core: 1.62.1
|
2024-03-05 14:23:26 +01:00
|
|
|
optionalDependencies:
|
|
|
|
|
fsevents: 2.3.2
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
postcss-import@15.1.0(postcss@8.5.16):
|
2024-10-24 11:00:25 -04:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
postcss: 8.5.16
|
2024-03-05 14:23:26 +01:00
|
|
|
postcss-value-parser: 4.2.0
|
|
|
|
|
read-cache: 1.0.0
|
2026-05-22 16:57:46 +02:00
|
|
|
resolve: 1.22.12
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
postcss-import@16.1.1(postcss@8.5.25):
|
2024-10-03 11:15:18 +02:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
postcss: 8.5.25
|
2024-10-03 11:15:18 +02:00
|
|
|
postcss-value-parser: 4.2.0
|
|
|
|
|
read-cache: 1.0.0
|
2026-05-22 16:57:46 +02:00
|
|
|
resolve: 1.22.12
|
2024-10-03 11:15:18 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
postcss-js@4.1.0(postcss@8.5.16):
|
2024-10-24 11:00:25 -04:00
|
|
|
dependencies:
|
|
|
|
|
camelcase-css: 2.0.1
|
2026-08-04 13:55:03 +02:00
|
|
|
postcss: 8.5.16
|
2024-10-24 11:00:25 -04:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
postcss-load-config@6.0.1(jiti@1.21.7)(postcss@8.5.16)(yaml@2.9.0):
|
2024-10-24 11:00:25 -04:00
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
lilconfig: 3.1.3
|
2024-10-24 11:00:25 -04:00
|
|
|
optionalDependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
jiti: 1.21.7
|
2026-08-04 13:55:03 +02:00
|
|
|
postcss: 8.5.16
|
2026-06-25 19:14:10 +02:00
|
|
|
yaml: 2.9.0
|
2024-10-24 11:00:25 -04:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
postcss-load-config@6.0.1(jiti@2.7.0)(postcss@8.5.25)(yaml@2.9.0):
|
2024-08-07 16:38:44 +02:00
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
lilconfig: 3.1.3
|
2024-08-07 16:38:44 +02:00
|
|
|
optionalDependencies:
|
2026-05-13 12:02:13 +02:00
|
|
|
jiti: 2.7.0
|
2026-08-04 13:55:03 +02:00
|
|
|
postcss: 8.5.25
|
2026-06-25 19:14:10 +02:00
|
|
|
yaml: 2.9.0
|
2024-10-24 11:00:25 -04:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
postcss-nested@6.2.0(postcss@8.5.16):
|
2024-10-24 11:00:25 -04:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
postcss: 8.5.16
|
2024-10-24 11:00:25 -04:00
|
|
|
postcss-selector-parser: 6.1.2
|
2024-08-07 16:38:44 +02:00
|
|
|
|
2024-11-19 16:19:08 +01:00
|
|
|
postcss-selector-parser@6.0.10:
|
|
|
|
|
dependencies:
|
|
|
|
|
cssesc: 3.0.0
|
|
|
|
|
util-deprecate: 1.0.2
|
|
|
|
|
|
Add CSS codemods for migrating `@layer utilities` (#14455)
This PR adds CSS codemods for migrating existing `@layer utilities` to
`@utility` directives.
This PR has the ability to migrate the following cases:
---
The most basic case is when you want to migrate a simple class to a
utility directive.
Input:
```css
@layer utilities {
.foo {
color: red;
}
.bar {
color: blue;
}
}
```
Output:
```css
@utility foo {
color: red;
}
@utility bar {
color: blue;
}
```
You'll notice that the class `foo` will be used as the utility name, the
declarations (and the rest of the body of the rule) will become the body
of the `@utility` definition.
---
In v3, every class in a selector will become a utility. To correctly
migrate this to `@utility` directives, we have to register each class in
the selector and generate `n` utilities.
We can use nesting syntax, and replace the current class with `&` to
ensure that the final result behaves the same.
Input:
```css
@layer utilities {
.foo .bar .baz {
color: red;
}
}
```
Output:
```css
@utility foo {
& .bar .baz {
color: red;
}
}
@utility bar {
.foo & .baz {
color: red;
}
}
@utility .baz {
.foo .bar & {
color: red;
}
}
```
In this case, it could be that you know that some of them will never be
used as a utility (e.g.: `hover:bar`), but then you can safely remove
them.
---
Even classes inside of `:has(…)` will become a utility. The only
exception to the rule is that we don't do it for `:not(…)`.
Input:
```css
@layer utilities {
.foo .bar:not(.qux):has(.baz) {
display: none;
}
}
```
Output:
```css
@utility foo {
& .bar:not(.qux):has(.baz) {
display: none;
}
}
@utility bar {
.foo &:not(.qux):has(.baz) {
display: none;
}
}
@utility baz {
.foo .bar:not(.qux):has(&) {
display: none;
}
}
```
Notice that there is no `@utility qux` because it was used inside of
`:not(…)`.
---
When classes are nested inside at-rules, then these classes will also
become utilities. However, the `@utility <name>` will be at the top and
the at-rules will live inside of it. If there are multiple classes
inside a shared at-rule, then the at-rule will be duplicated for each
class.
Let's look at an example to make it more clear:
Input:
```css
@layer utilities {
@media (min-width: 640px) {
.foo {
color: red;
}
.bar {
color: blue;
}
@media (min-width: 1024px) {
.baz {
color: green;
}
@media (min-width: 1280px) {
.qux {
color: yellow;
}
}
}
}
}
```
Output:
```css
@utility foo {
@media (min-width: 640px) {
color: red;
}
}
@utility bar {
@media (min-width: 640px) {
color: blue;
}
}
@utility baz {
@media (min-width: 640px) {
@media (min-width: 1024px) {
color: green;
}
}
}
@utility qux {
@media (min-width: 640px) {
@media (min-width: 1024px) {
@media (min-width: 1280px) {
color: yellow;
}
}
}
}
```
---
When classes result in multiple `@utility` directives with the same
name, then the definitions will be merged together.
Input:
```css
@layer utilities {
.no-scrollbar::-webkit-scrollbar {
display: none;
}
.no-scrollbar {
-ms-overflow-style: none;
scrollbar-width: none;
}
}
```
Intermediate representation:
```css
@utility no-scrollbar {
&::-webkit-scrollbar {
display: none;
}
}
@utility no-scrollbar {
-ms-overflow-style: none;
scrollbar-width: none;
}
```
Output:
```css
@utility no-scrollbar {
&::-webkit-scrollbar {
display: none;
}
-ms-overflow-style: none;
scrollbar-width: none
}
```
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-09-24 18:17:09 +02:00
|
|
|
postcss-selector-parser@6.1.2:
|
|
|
|
|
dependencies:
|
|
|
|
|
cssesc: 3.0.0
|
|
|
|
|
util-deprecate: 1.0.2
|
|
|
|
|
|
2026-06-19 13:11:16 +02:00
|
|
|
postcss-selector-parser@7.1.4:
|
2024-10-30 15:27:53 -04:00
|
|
|
dependencies:
|
|
|
|
|
cssesc: 3.0.0
|
|
|
|
|
util-deprecate: 1.0.2
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
postcss-value-parser@4.2.0: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
postcss@8.4.31:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
nanoid: 3.3.12
|
2024-10-24 11:25:50 +02:00
|
|
|
picocolors: 1.1.1
|
2024-10-24 11:00:25 -04:00
|
|
|
source-map-js: 1.2.1
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
postcss@8.5.16:
|
2026-03-12 20:54:34 +01:00
|
|
|
dependencies:
|
2026-05-21 17:58:55 +02:00
|
|
|
nanoid: 3.3.12
|
2026-05-12 15:21:44 +00:00
|
|
|
picocolors: 1.1.1
|
|
|
|
|
source-map-js: 1.2.1
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
postcss@8.5.25:
|
2026-07-02 11:45:49 +02:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
nanoid: 3.3.16
|
2026-07-02 11:45:49 +02:00
|
|
|
picocolors: 1.1.1
|
|
|
|
|
source-map-js: 1.2.1
|
|
|
|
|
|
2025-12-26 12:36:51 -05:00
|
|
|
prettier-plugin-embed@0.5.1:
|
Add integration test setup and tests for the Vite integration (#14089)
This PR adds a new root `/integrations` folder that will be the home of
integration tests. The idea of these tests is to use Tailwind in various
setups just like our users would (by only using the publishable npm
builds).
To avoid issues with concurrent tests making changes to the file system,
to make it very easy to test through a range of versions, and to avoid
changing configuration objects over and over in test runs, we decided to
inline the scaffolding completely into the test file and have no
examples checked into the repo.
Here's an example of how this can look like for a simple Vite test:
```ts
test('works with production builds', {
fs: {
'package.json': json`
{
"type": "module",
"dependencies": {
"@tailwindcss/vite": "workspace:^",
"tailwindcss": "workspace:^"
},
"devDependencies": {
"vite": "^5.3.5"
}
}
`,
'vite.config.ts': ts`
import tailwindcss from '@tailwindcss/vite'
import { defineConfig } from 'vite'
export default defineConfig({
build: { cssMinify: false },
plugins: [tailwindcss()],
})
`,
'index.html': html`
<head>
<link rel="stylesheet" href="./src/index.css">
</head>
<body>
<div class="underline m-2">Hello, world!</div>
</body>
`,
'src/index.css': css`
@import 'tailwindcss/theme' reference;
@import 'tailwindcss/utilities';
`,
},
},
async ({ fs, exec }) => {
await exec('pnpm vite build')
expect.assertions(2)
for (let [path, content] of await fs.glob('dist/**/*.css')) {
expect(path).toMatch(/\.css$/)
expect(stripTailwindComment(content)).toMatchInlineSnapshot(
`
".m-2 {
margin: var(--spacing-2, .5rem);
}
.underline {
text-decoration-line: underline;
}"
`,
)
}
},
)
```
By defining all dependencies this way, we never have to worry about
which fixtures are checked in and can more easily describe changes to
the setup.
For ergonomics, we've also added the [`embed` prettier
plugin](https://github.com/Sec-ant/prettier-plugin-embed). This will
mean that files inlined in the `fs` setup are properly indented. No
extra work needed!
If you're using VS Code, I can also recommend the [Language
Literals](https://marketplace.visualstudio.com/items?itemName=sissel.language-literals)
extension so that syntax highlighting also _just works_.
A neat feature of inlining the scaffolding like this is to make it very
simple to test through a variety of versions. For example, here's how we
can set up a test against Vite 5 and Vite 4:
```js
;['^4.5.3', '^5.3.5'].forEach(viteVersion => {
test(`works with production builds for Vite ${viteVersion}`, {
fs: {
'package.json': json`
{
"type": "module",
"devDependencies": {
"vite": "${viteVersion}"
}
}
`,
async () => {
// Do something
},
)
})
```
## Philosophy
Before we dive into the specifics, I want to clearly state the design
considerations we have chosen for this new test suite:
- All file mutations should be done in temp folders, nothing should ever
mess with your working directory
- Windows as a first-class citizen
- Have a clean and simple API that describes the test setup only using
public APIs
- Focus on reliability (make sure cleanup scripts work and are tolerant
to various error scenarios)
- If a user reports an issue with a specific configuration, we want to
be able to reproduce them with integration tests, no matter how obscure
the setup (this means the test need to be in control of most of the
variables)
- Tests should be reasonably fast (obviously this depends on the
integration. If we use a slow build tool, we can't magically speed it
up, but our overhead should be minimal).
## How it works
The current implementation provides a custom `test` helper function
that, when used, sets up the environment according to the configuration.
It'll create a new temporary directory and create all files, ensuring
things like proper `\r\n` line endings on Windows.
We do have to patch the `package.json` specifically, since we can not
use public versions of the tailwindcss packages as we want to be able to
test against a development build. To make this happen, every `pnpm
build` run now creates tarballs of the npm modules (that contain only
the files that would also in the published build). We then patch the
`package.json` to rewrite `workspace:^` versions to link to those
tarballs. We found this to work reliably on Windows and macOS as well as
being fast enough to not cause any issues. Furthermore we also decided
to use `pnpm` as the version manager for integration tests because of
it's global module cache (so installing `vite` is fast as soon as you
installed it once).
The test function will receive a few utilities that it can use to more
easily interact with the temp dir. One example is a `fs.glob` function
that you can use to easily find files in eventual `dist/` directories or
helpers around `spawn` and `exec` that make sure that processes are
cleaned up correctly.
Because we use tarballs from our build dependencies, working on changes
requires a workflow where you run `pnpm build` before running `pnpm
test:integrations`. However it also means we can run clients like our
CLI client with no additional overhead—just install the dependency like
any user would and set up your test cases this way.
## Test plan
This PR also includes two Vite specific integration tests: One testing a
static build (`pnpm vite build`) and one a dev mode build (`pnpm vite
dev`) that also makes changes to the file system and asserts that the
resources properly update.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-08-02 11:50:49 +02:00
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@types/estree': 1.0.9
|
|
|
|
|
dedent: 1.7.2
|
2025-12-26 12:36:51 -05:00
|
|
|
micro-memoize: 5.1.1
|
Add integration test setup and tests for the Vite integration (#14089)
This PR adds a new root `/integrations` folder that will be the home of
integration tests. The idea of these tests is to use Tailwind in various
setups just like our users would (by only using the publishable npm
builds).
To avoid issues with concurrent tests making changes to the file system,
to make it very easy to test through a range of versions, and to avoid
changing configuration objects over and over in test runs, we decided to
inline the scaffolding completely into the test file and have no
examples checked into the repo.
Here's an example of how this can look like for a simple Vite test:
```ts
test('works with production builds', {
fs: {
'package.json': json`
{
"type": "module",
"dependencies": {
"@tailwindcss/vite": "workspace:^",
"tailwindcss": "workspace:^"
},
"devDependencies": {
"vite": "^5.3.5"
}
}
`,
'vite.config.ts': ts`
import tailwindcss from '@tailwindcss/vite'
import { defineConfig } from 'vite'
export default defineConfig({
build: { cssMinify: false },
plugins: [tailwindcss()],
})
`,
'index.html': html`
<head>
<link rel="stylesheet" href="./src/index.css">
</head>
<body>
<div class="underline m-2">Hello, world!</div>
</body>
`,
'src/index.css': css`
@import 'tailwindcss/theme' reference;
@import 'tailwindcss/utilities';
`,
},
},
async ({ fs, exec }) => {
await exec('pnpm vite build')
expect.assertions(2)
for (let [path, content] of await fs.glob('dist/**/*.css')) {
expect(path).toMatch(/\.css$/)
expect(stripTailwindComment(content)).toMatchInlineSnapshot(
`
".m-2 {
margin: var(--spacing-2, .5rem);
}
.underline {
text-decoration-line: underline;
}"
`,
)
}
},
)
```
By defining all dependencies this way, we never have to worry about
which fixtures are checked in and can more easily describe changes to
the setup.
For ergonomics, we've also added the [`embed` prettier
plugin](https://github.com/Sec-ant/prettier-plugin-embed). This will
mean that files inlined in the `fs` setup are properly indented. No
extra work needed!
If you're using VS Code, I can also recommend the [Language
Literals](https://marketplace.visualstudio.com/items?itemName=sissel.language-literals)
extension so that syntax highlighting also _just works_.
A neat feature of inlining the scaffolding like this is to make it very
simple to test through a variety of versions. For example, here's how we
can set up a test against Vite 5 and Vite 4:
```js
;['^4.5.3', '^5.3.5'].forEach(viteVersion => {
test(`works with production builds for Vite ${viteVersion}`, {
fs: {
'package.json': json`
{
"type": "module",
"devDependencies": {
"vite": "${viteVersion}"
}
}
`,
async () => {
// Do something
},
)
})
```
## Philosophy
Before we dive into the specifics, I want to clearly state the design
considerations we have chosen for this new test suite:
- All file mutations should be done in temp folders, nothing should ever
mess with your working directory
- Windows as a first-class citizen
- Have a clean and simple API that describes the test setup only using
public APIs
- Focus on reliability (make sure cleanup scripts work and are tolerant
to various error scenarios)
- If a user reports an issue with a specific configuration, we want to
be able to reproduce them with integration tests, no matter how obscure
the setup (this means the test need to be in control of most of the
variables)
- Tests should be reasonably fast (obviously this depends on the
integration. If we use a slow build tool, we can't magically speed it
up, but our overhead should be minimal).
## How it works
The current implementation provides a custom `test` helper function
that, when used, sets up the environment according to the configuration.
It'll create a new temporary directory and create all files, ensuring
things like proper `\r\n` line endings on Windows.
We do have to patch the `package.json` specifically, since we can not
use public versions of the tailwindcss packages as we want to be able to
test against a development build. To make this happen, every `pnpm
build` run now creates tarballs of the npm modules (that contain only
the files that would also in the published build). We then patch the
`package.json` to rewrite `workspace:^` versions to link to those
tarballs. We found this to work reliably on Windows and macOS as well as
being fast enough to not cause any issues. Furthermore we also decided
to use `pnpm` as the version manager for integration tests because of
it's global module cache (so installing `vite` is fast as soon as you
installed it once).
The test function will receive a few utilities that it can use to more
easily interact with the temp dir. One example is a `fs.glob` function
that you can use to easily find files in eventual `dist/` directories or
helpers around `spawn` and `exec` that make sure that processes are
cleaned up correctly.
Because we use tarballs from our build dependencies, working on changes
requires a workflow where you run `pnpm build` before running `pnpm
test:integrations`. However it also means we can run clients like our
CLI client with no additional overhead—just install the dependency like
any user would and set up your test cases this way.
## Test plan
This PR also includes two Vite specific integration tests: One testing a
static build (`pnpm vite build`) and one a dev mode build (`pnpm vite
dev`) that also makes changes to the file system and asserts that the
resources properly update.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-08-02 11:50:49 +02:00
|
|
|
package-up: 5.0.0
|
2025-03-03 13:22:51 +01:00
|
|
|
tiny-jsonc: 1.0.2
|
2026-05-22 16:57:46 +02:00
|
|
|
type-fest: 5.6.0
|
Add integration test setup and tests for the Vite integration (#14089)
This PR adds a new root `/integrations` folder that will be the home of
integration tests. The idea of these tests is to use Tailwind in various
setups just like our users would (by only using the publishable npm
builds).
To avoid issues with concurrent tests making changes to the file system,
to make it very easy to test through a range of versions, and to avoid
changing configuration objects over and over in test runs, we decided to
inline the scaffolding completely into the test file and have no
examples checked into the repo.
Here's an example of how this can look like for a simple Vite test:
```ts
test('works with production builds', {
fs: {
'package.json': json`
{
"type": "module",
"dependencies": {
"@tailwindcss/vite": "workspace:^",
"tailwindcss": "workspace:^"
},
"devDependencies": {
"vite": "^5.3.5"
}
}
`,
'vite.config.ts': ts`
import tailwindcss from '@tailwindcss/vite'
import { defineConfig } from 'vite'
export default defineConfig({
build: { cssMinify: false },
plugins: [tailwindcss()],
})
`,
'index.html': html`
<head>
<link rel="stylesheet" href="./src/index.css">
</head>
<body>
<div class="underline m-2">Hello, world!</div>
</body>
`,
'src/index.css': css`
@import 'tailwindcss/theme' reference;
@import 'tailwindcss/utilities';
`,
},
},
async ({ fs, exec }) => {
await exec('pnpm vite build')
expect.assertions(2)
for (let [path, content] of await fs.glob('dist/**/*.css')) {
expect(path).toMatch(/\.css$/)
expect(stripTailwindComment(content)).toMatchInlineSnapshot(
`
".m-2 {
margin: var(--spacing-2, .5rem);
}
.underline {
text-decoration-line: underline;
}"
`,
)
}
},
)
```
By defining all dependencies this way, we never have to worry about
which fixtures are checked in and can more easily describe changes to
the setup.
For ergonomics, we've also added the [`embed` prettier
plugin](https://github.com/Sec-ant/prettier-plugin-embed). This will
mean that files inlined in the `fs` setup are properly indented. No
extra work needed!
If you're using VS Code, I can also recommend the [Language
Literals](https://marketplace.visualstudio.com/items?itemName=sissel.language-literals)
extension so that syntax highlighting also _just works_.
A neat feature of inlining the scaffolding like this is to make it very
simple to test through a variety of versions. For example, here's how we
can set up a test against Vite 5 and Vite 4:
```js
;['^4.5.3', '^5.3.5'].forEach(viteVersion => {
test(`works with production builds for Vite ${viteVersion}`, {
fs: {
'package.json': json`
{
"type": "module",
"devDependencies": {
"vite": "${viteVersion}"
}
}
`,
async () => {
// Do something
},
)
})
```
## Philosophy
Before we dive into the specifics, I want to clearly state the design
considerations we have chosen for this new test suite:
- All file mutations should be done in temp folders, nothing should ever
mess with your working directory
- Windows as a first-class citizen
- Have a clean and simple API that describes the test setup only using
public APIs
- Focus on reliability (make sure cleanup scripts work and are tolerant
to various error scenarios)
- If a user reports an issue with a specific configuration, we want to
be able to reproduce them with integration tests, no matter how obscure
the setup (this means the test need to be in control of most of the
variables)
- Tests should be reasonably fast (obviously this depends on the
integration. If we use a slow build tool, we can't magically speed it
up, but our overhead should be minimal).
## How it works
The current implementation provides a custom `test` helper function
that, when used, sets up the environment according to the configuration.
It'll create a new temporary directory and create all files, ensuring
things like proper `\r\n` line endings on Windows.
We do have to patch the `package.json` specifically, since we can not
use public versions of the tailwindcss packages as we want to be able to
test against a development build. To make this happen, every `pnpm
build` run now creates tarballs of the npm modules (that contain only
the files that would also in the published build). We then patch the
`package.json` to rewrite `workspace:^` versions to link to those
tarballs. We found this to work reliably on Windows and macOS as well as
being fast enough to not cause any issues. Furthermore we also decided
to use `pnpm` as the version manager for integration tests because of
it's global module cache (so installing `vite` is fast as soon as you
installed it once).
The test function will receive a few utilities that it can use to more
easily interact with the temp dir. One example is a `fs.glob` function
that you can use to easily find files in eventual `dist/` directories or
helpers around `spawn` and `exec` that make sure that processes are
cleaned up correctly.
Because we use tarballs from our build dependencies, working on changes
requires a workflow where you run `pnpm build` before running `pnpm
test:integrations`. However it also means we can run clients like our
CLI client with no additional overhead—just install the dependency like
any user would and set up your test cases this way.
## Test plan
This PR also includes two Vite specific integration tests: One testing a
static build (`pnpm vite build`) and one a dev mode build (`pnpm vite
dev`) that also makes changes to the file system and asserts that the
resources properly update.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-08-02 11:50:49 +02:00
|
|
|
transitivePeerDependencies:
|
|
|
|
|
- babel-plugin-macros
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
prettier-plugin-organize-imports@4.3.0(prettier@3.9.6)(typescript@5.9.3):
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
prettier: 3.9.6
|
2026-04-24 21:21:12 +02:00
|
|
|
typescript: 5.9.3
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
prettier@3.9.6: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
queue-microtask@1.2.3: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2025-01-07 09:57:34 -05:00
|
|
|
radix3@1.1.2: {}
|
|
|
|
|
|
2026-05-14 12:41:48 +02:00
|
|
|
react-dom@19.2.6(react@19.2.6):
|
|
|
|
|
dependencies:
|
|
|
|
|
react: 19.2.6
|
|
|
|
|
scheduler: 0.27.0
|
|
|
|
|
|
2026-06-09 10:44:01 +00:00
|
|
|
react-dom@19.2.7(react@19.2.7):
|
|
|
|
|
dependencies:
|
|
|
|
|
react: 19.2.7
|
|
|
|
|
scheduler: 0.27.0
|
|
|
|
|
|
2026-05-14 12:41:48 +02:00
|
|
|
react@19.2.6: {}
|
|
|
|
|
|
2026-06-09 10:44:01 +00:00
|
|
|
react@19.2.7: {}
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
read-cache@1.0.0:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
|
|
|
|
pify: 2.3.0
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
readdirp@3.6.0:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
picomatch: 2.3.2
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
readdirp@4.1.2: {}
|
2025-02-03 11:20:51 +01:00
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
require-from-string@2.0.2: {}
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
resolve-from@5.0.0: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
resolve@1.22.12:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
es-errors: 1.3.0
|
|
|
|
|
is-core-module: 2.16.2
|
2024-03-05 14:23:26 +01:00
|
|
|
path-parse: 1.0.7
|
|
|
|
|
supports-preserve-symlinks-flag: 1.0.0
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
reusify@1.1.0: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
rolldown@1.2.1:
|
2026-03-12 20:54:34 +01:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@oxc-project/types': 0.142.0
|
2026-05-21 17:58:55 +02:00
|
|
|
'@rolldown/pluginutils': 1.0.1
|
2026-03-12 20:54:34 +01:00
|
|
|
optionalDependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@rolldown/binding-android-arm64': 1.2.1
|
|
|
|
|
'@rolldown/binding-darwin-arm64': 1.2.1
|
|
|
|
|
'@rolldown/binding-darwin-x64': 1.2.1
|
|
|
|
|
'@rolldown/binding-freebsd-x64': 1.2.1
|
|
|
|
|
'@rolldown/binding-linux-arm-gnueabihf': 1.2.1
|
|
|
|
|
'@rolldown/binding-linux-arm64-gnu': 1.2.1
|
|
|
|
|
'@rolldown/binding-linux-arm64-musl': 1.2.1
|
|
|
|
|
'@rolldown/binding-linux-ppc64-gnu': 1.2.1
|
|
|
|
|
'@rolldown/binding-linux-s390x-gnu': 1.2.1
|
|
|
|
|
'@rolldown/binding-linux-x64-gnu': 1.2.1
|
|
|
|
|
'@rolldown/binding-linux-x64-musl': 1.2.1
|
|
|
|
|
'@rolldown/binding-openharmony-arm64': 1.2.1
|
|
|
|
|
'@rolldown/binding-wasm32-wasi': 1.2.1
|
|
|
|
|
'@rolldown/binding-win32-arm64-msvc': 1.2.1
|
|
|
|
|
'@rolldown/binding-win32-x64-msvc': 1.2.1
|
2026-03-12 20:54:34 +01:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
rollup@4.60.4:
|
2025-06-24 18:31:17 +02:00
|
|
|
dependencies:
|
|
|
|
|
'@types/estree': 1.0.8
|
|
|
|
|
optionalDependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@rollup/rollup-android-arm-eabi': 4.60.4
|
|
|
|
|
'@rollup/rollup-android-arm64': 4.60.4
|
|
|
|
|
'@rollup/rollup-darwin-arm64': 4.60.4
|
|
|
|
|
'@rollup/rollup-darwin-x64': 4.60.4
|
|
|
|
|
'@rollup/rollup-freebsd-arm64': 4.60.4
|
|
|
|
|
'@rollup/rollup-freebsd-x64': 4.60.4
|
|
|
|
|
'@rollup/rollup-linux-arm-gnueabihf': 4.60.4
|
|
|
|
|
'@rollup/rollup-linux-arm-musleabihf': 4.60.4
|
|
|
|
|
'@rollup/rollup-linux-arm64-gnu': 4.60.4
|
|
|
|
|
'@rollup/rollup-linux-arm64-musl': 4.60.4
|
|
|
|
|
'@rollup/rollup-linux-loong64-gnu': 4.60.4
|
|
|
|
|
'@rollup/rollup-linux-loong64-musl': 4.60.4
|
|
|
|
|
'@rollup/rollup-linux-ppc64-gnu': 4.60.4
|
|
|
|
|
'@rollup/rollup-linux-ppc64-musl': 4.60.4
|
|
|
|
|
'@rollup/rollup-linux-riscv64-gnu': 4.60.4
|
|
|
|
|
'@rollup/rollup-linux-riscv64-musl': 4.60.4
|
|
|
|
|
'@rollup/rollup-linux-s390x-gnu': 4.60.4
|
|
|
|
|
'@rollup/rollup-linux-x64-gnu': 4.60.4
|
|
|
|
|
'@rollup/rollup-linux-x64-musl': 4.60.4
|
|
|
|
|
'@rollup/rollup-openbsd-x64': 4.60.4
|
|
|
|
|
'@rollup/rollup-openharmony-arm64': 4.60.4
|
|
|
|
|
'@rollup/rollup-win32-arm64-msvc': 4.60.4
|
|
|
|
|
'@rollup/rollup-win32-ia32-msvc': 4.60.4
|
|
|
|
|
'@rollup/rollup-win32-x64-gnu': 4.60.4
|
|
|
|
|
'@rollup/rollup-win32-x64-msvc': 4.60.4
|
2025-06-24 18:31:17 +02:00
|
|
|
fsevents: 2.3.3
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
run-parallel@1.2.0:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
|
|
|
|
queue-microtask: 1.2.3
|
|
|
|
|
|
2025-04-11 17:19:55 +02:00
|
|
|
safer-buffer@2.1.2: {}
|
|
|
|
|
|
Update all of react 19.1.1 → 19.2.0 (minor) (#19087)
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?
#### ✳️ react (19.1.1 → 19.2.0) ·
[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.0">19.2.0</a></h4>
<blockquote><p dir="auto">Below is a list of all new features, APIs, and
bug fixes.</p>
<p dir="auto">Read the <a
href="https://react.dev/blog/2025/10/01/react-19-2">React 19.2 release
post</a> for more information.</p>
<h2 dir="auto">New React Features</h2>
<ul dir="auto">
<li>
<a href="https://react.dev/reference/react/Activity"><code
class="notranslate"><Activity></code></a>: A new API to hide and
restore the UI and internal state of its children.</li>
<li>
<a href="https://react.dev/reference/react/useEffectEvent"><code
class="notranslate">useEffectEvent</code></a> is a React Hook that lets
you extract non-reactive logic into an <a
href="https://react.dev/learn/separating-events-from-effects#declaring-an-effect-event">Effect
Event</a>.</li>
<li>
<a href="https://react.dev/reference/react/cacheSignal"><code
class="notranslate">cacheSignal</code></a> (for RSCs) lets your know
when the <code class="notranslate">cache()</code> lifetime is over.</li>
<li>
<a
href="https://react.dev/reference/developer-tooling/react-performance-tracks">React
Performance tracks</a> appear on the Performance panel’s timeline in
your browser developer tools</li>
</ul>
<h2 dir="auto">New React DOM Features</h2>
<ul dir="auto">
<li>Added resume APIs for partial pre-rendering with Web Streams:
<ul dir="auto">
<li>
<a href="https://react.dev/reference/react-dom/server/resume"><code
class="notranslate">resume</code></a>: to resume a prerender to a
stream.</li>
<li>
<a
href="https://react.dev/reference/react-dom/static/resumeAndPrerender"><code
class="notranslate">resumeAndPrerender</code></a>: to resume a prerender
to HTML.</li>
</ul>
</li>
<li>Added resume APIs for partial pre-rendering with Node Streams:
<ul dir="auto">
<li>
<a
href="https://react.dev/reference/react-dom/server/resumeToPipeableStream"><code
class="notranslate">resumeToPipeableStream</code></a>: to resume a
prerender to a stream.</li>
<li>
<a
href="https://react.dev/reference/react-dom/static/resumeAndPrerenderToNodeStream"><code
class="notranslate">resumeAndPrerenderToNodeStream</code></a>: to resume
a prerender to HTML.</li>
</ul>
</li>
<li>Updated <a
href="https://react.dev/reference/react-dom/static/prerender"><code
class="notranslate">prerender</code></a> APIs to return a <code
class="notranslate">postponed</code> state that can be passed to the
<code class="notranslate">resume</code> APIs.</li>
</ul>
<h2 dir="auto">Notable changes</h2>
<ul dir="auto">
<li>React DOM now batches suspense boundary reveals, matching the
behavior of client side rendering. This change is especially noticeable
when animating the reveal of Suspense boundaries e.g. with the upcoming
<code class="notranslate"><ViewTransition></code> Component. React
will batch as much reveals as possible before the first paint while
trying to hit popular first-contentful paint metrics.</li>
<li>Add Node Web Streams (<code class="notranslate">prerender</code>,
<code class="notranslate">renderToReadableStream</code>) to
server-side-rendering APIs for Node.js</li>
<li>Use underscore instead of <code class="notranslate">:</code> IDs
generated by useId</li>
</ul>
<h2 dir="auto">All Changes</h2>
<h3 dir="auto">React</h3>
<ul dir="auto">
<li>
<code class="notranslate"><Activity /></code> was developed over
many years, starting before <code
class="notranslate">ClassComponent.setState</code> (<a
href="https://bounce.depfu.com/github.com/acdlite">@acdlite</a> <a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
and many others)</li>
<li>Stringify context as "SomeContext" instead of "SomeContext.Provider"
(<a href="https://bounce.depfu.com/github.com/kassens">@kassens</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33507">#33507</a>)</li>
<li>Include stack of cause of React instrumentation errors with <code
class="notranslate">%o</code> placeholder (<a
href="https://bounce.depfu.com/github.com/eps1lon">@eps1lon</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34198">#34198</a>)</li>
<li>Fix infinite <code class="notranslate">useDeferredValue</code> loop
in popstate event (<a
href="https://bounce.depfu.com/github.com/acdlite">@acdlite</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32821">#32821</a>)</li>
<li>Fix a bug when an initial value was passed to <code
class="notranslate">useDeferredValue</code> (<a
href="https://bounce.depfu.com/github.com/acdlite">@acdlite</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34376">#34376</a>)</li>
<li>Fix a crash when submitting forms with Client Actions (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33055">#33055</a>)</li>
<li>Hide/unhide the content of dehydrated suspense boundaries if they
resuspend (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32900">#32900</a>)</li>
<li>Avoid stack overflow on wide trees during Hot Reload (<a
href="https://bounce.depfu.com/github.com/sophiebits">@sophiebits</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34145">#34145</a>)</li>
<li>Improve Owner and Component stacks in various places (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>,
<a href="https://bounce.depfu.com/github.com/eps1lon">@eps1lon</a>: <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33629">#33629</a>,
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33724">#33724</a>,
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32735">#32735</a>,
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33723">#33723</a>)</li>
<li>Add <code class="notranslate">cacheSignal</code> (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33557">#33557</a>)</li>
</ul>
<h3 dir="auto">React DOM</h3>
<ul dir="auto">
<li>Block on Suspensey Fonts during reveal of server-side-rendered
content (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33342">#33342</a>)</li>
<li>Use underscore instead of <code class="notranslate">:</code> for IDs
generated by <code class="notranslate">useId</code> (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>,
<a href="https://bounce.depfu.com/github.com/eps1lon">@eps1lon</a>: <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32001">#32001</a>,
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33342">#33342</a><a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33099">#33099</a>,
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33422">#33422</a>)</li>
<li>Stop warning when ARIA 1.3 attributes are used (<a
href="https://bounce.depfu.com/github.com/Abdul-Omira">@Abdul-Omira</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34264">#34264</a>)</li>
<li>Allow <code class="notranslate">nonce</code> to be used on hoistable
styles (<a
href="https://bounce.depfu.com/github.com/Andarist">@Andarist</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32461">#32461</a>)</li>
<li>Warn for using a React owned node as a Container if it also has text
content (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32774">#32774</a>)</li>
<li>s/HTML/text for for error messages if text hydration mismatches (<a
href="https://bounce.depfu.com/github.com/rickhanlonii">@rickhanlonii</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32763">#32763</a>)</li>
<li>Fix a bug with <code class="notranslate">React.use</code> inside
<code class="notranslate">React.lazy</code>-ed Component (<a
href="https://bounce.depfu.com/github.com/hi-ogawa">@hi-ogawa</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33941">#33941</a>)</li>
<li>Enable the <code class="notranslate">progressiveChunkSize</code>
option for server-side-rendering APIs (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33027">#33027</a>)</li>
<li>Fix a bug with deeply nested Suspense inside Suspense fallback when
server-side-rendering (<a
href="https://bounce.depfu.com/github.com/gnoff">@gnoff</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33467">#33467</a>)</li>
<li>Avoid hanging when suspending after aborting while rendering (<a
href="https://bounce.depfu.com/github.com/gnoff">@gnoff</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34192">#34192</a>)</li>
<li>Add Node Web Streams to server-side-rendering APIs for Node.js (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33475">#33475</a>)</li>
</ul>
<h3 dir="auto">React Server Components</h3>
<ul dir="auto">
<li>Preload <code class="notranslate"><img></code> and <code
class="notranslate"><link></code> using hints before they're
rendered (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34604">#34604</a>)</li>
<li>Log error if production elements are rendered during development (<a
href="https://bounce.depfu.com/github.com/eps1lon">@eps1lon</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34189">#34189</a>)</li>
<li>Fix a bug when returning a Temporary reference (e.g. a Client
Reference) from Server Functions (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34084">#34084</a>,
<a href="https://bounce.depfu.com/github.com/denk0403">@denk0403</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33761">#33761</a>)</li>
<li>Pass line/column to <code
class="notranslate">filterStackFrame</code> (<a
href="https://bounce.depfu.com/github.com/eps1lon">@eps1lon</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33707">#33707</a>)</li>
<li>Support Async Modules in Turbopack Server References (<a
href="https://bounce.depfu.com/github.com/lubieowoce">@lubieowoce</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34531">#34531</a>)</li>
<li>Add support for .mjs file extension in Webpack (<a
href="https://bounce.depfu.com/github.com/jennyscript">@jennyscript</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33028">#33028</a>)</li>
<li>Fix a wrong missing key warning (<a
href="https://bounce.depfu.com/github.com/unstubbable">@unstubbable</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34350">#34350</a>)</li>
<li>Make console log resolve in predictable order (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33665">#33665</a>)</li>
</ul>
<h3 dir="auto">React Reconciler</h3>
<ul dir="auto">
<li>
<a
href="https://bounce.depfu.com/github.com/facebook/react/blob/v19.2.0/packages/react-reconciler/src/ReactFiberReconciler.js#L255-L261">createContainer</a>
and <a
href="https://bounce.depfu.com/github.com/facebook/react/blob/v19.2.0/packages/react-reconciler/src/ReactFiberReconciler.js#L305-L312">createHydrationContainer</a>
had their parameter order adjusted after <code
class="notranslate">on*</code> handlers to account for upcoming
experimental APIs</li>
</ul>
<h2 dir="auto">eslint-plugin-react-hooks@6.1.0</h2>
<p dir="auto"><strong>Note:</strong> Version 6.0.0 was mistakenly
released and immediately deprecated and untagged on npm. This is the
first official 6.x major release and includes breaking changes.</p>
<ul dir="auto">
<li>
<strong>Breaking:</strong> Require Node.js 18 or newer. (<a
href="https://bounce.depfu.com/github.com/michaelfaith">@michaelfaith</a>
in <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32458">#32458</a>)</li>
<li>
<strong>Breaking:</strong> Flat config is now the default <code
class="notranslate">recommended</code> preset. Legacy config moved to
<code class="notranslate">recommended-legacy</code>. (<a
href="https://bounce.depfu.com/github.com/michaelfaith">@michaelfaith</a>
in <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32457">#32457</a>)</li>
<li>
<strong>New Violations:</strong> Disallow calling <code
class="notranslate">use</code> within try/catch blocks. (<a
href="https://bounce.depfu.com/github.com/poteto">@poteto</a> in <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34040">#34040</a>)</li>
<li>
<strong>New Violations:</strong> Disallow calling <code
class="notranslate">useEffectEvent</code> functions in arbitrary
closures. (<a
href="https://bounce.depfu.com/github.com/jbrown215">@jbrown215</a> in
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33544">#33544</a>)</li>
<li>Handle <code class="notranslate">React.useEffect</code> in addition
to <code class="notranslate">useEffect</code> in rules-of-hooks. (<a
href="https://bounce.depfu.com/github.com/Ayc0">@Ayc0</a> in <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34076">#34076</a>)</li>
<li>Added <code class="notranslate">react-hooks</code> settings config
option that to accept <code
class="notranslate">additionalEffectHooks</code> that are used across
exhaustive-deps and rules-of-hooks rules. (<a
href="https://bounce.depfu.com/github.com/jbrown215">@jbrown215</a>) in
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34497">#34497</a>
</li>
</ul></blockquote>
<p><em>Does any of this look wrong? <a
href="https://depfu.com/packages/npm/react/feedback">Please let us
know.</a></em></p>
</details>
<details>
<summary>Commits</summary>
<p><a
href="https://github.com/facebook/react/compare/02ef49580922f87180f32618b9d1c70b75b968b7...ae74234eae6ebd62f19190731278e20bc1c37d51">See
the full diff on Github</a>. The new version differs by more commits
than we can show here.</p>
</details>
#### ✳️ react-dom (19.1.1 → 19.2.0) ·
[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.0">19.2.0</a></h4>
<blockquote><p dir="auto">Below is a list of all new features, APIs, and
bug fixes.</p>
<p dir="auto">Read the <a
href="https://react.dev/blog/2025/10/01/react-19-2">React 19.2 release
post</a> for more information.</p>
<h2 dir="auto">New React Features</h2>
<ul dir="auto">
<li>
<a href="https://react.dev/reference/react/Activity"><code
class="notranslate"><Activity></code></a>: A new API to hide and
restore the UI and internal state of its children.</li>
<li>
<a href="https://react.dev/reference/react/useEffectEvent"><code
class="notranslate">useEffectEvent</code></a> is a React Hook that lets
you extract non-reactive logic into an <a
href="https://react.dev/learn/separating-events-from-effects#declaring-an-effect-event">Effect
Event</a>.</li>
<li>
<a href="https://react.dev/reference/react/cacheSignal"><code
class="notranslate">cacheSignal</code></a> (for RSCs) lets your know
when the <code class="notranslate">cache()</code> lifetime is over.</li>
<li>
<a
href="https://react.dev/reference/developer-tooling/react-performance-tracks">React
Performance tracks</a> appear on the Performance panel’s timeline in
your browser developer tools</li>
</ul>
<h2 dir="auto">New React DOM Features</h2>
<ul dir="auto">
<li>Added resume APIs for partial pre-rendering with Web Streams:
<ul dir="auto">
<li>
<a href="https://react.dev/reference/react-dom/server/resume"><code
class="notranslate">resume</code></a>: to resume a prerender to a
stream.</li>
<li>
<a
href="https://react.dev/reference/react-dom/static/resumeAndPrerender"><code
class="notranslate">resumeAndPrerender</code></a>: to resume a prerender
to HTML.</li>
</ul>
</li>
<li>Added resume APIs for partial pre-rendering with Node Streams:
<ul dir="auto">
<li>
<a
href="https://react.dev/reference/react-dom/server/resumeToPipeableStream"><code
class="notranslate">resumeToPipeableStream</code></a>: to resume a
prerender to a stream.</li>
<li>
<a
href="https://react.dev/reference/react-dom/static/resumeAndPrerenderToNodeStream"><code
class="notranslate">resumeAndPrerenderToNodeStream</code></a>: to resume
a prerender to HTML.</li>
</ul>
</li>
<li>Updated <a
href="https://react.dev/reference/react-dom/static/prerender"><code
class="notranslate">prerender</code></a> APIs to return a <code
class="notranslate">postponed</code> state that can be passed to the
<code class="notranslate">resume</code> APIs.</li>
</ul>
<h2 dir="auto">Notable changes</h2>
<ul dir="auto">
<li>React DOM now batches suspense boundary reveals, matching the
behavior of client side rendering. This change is especially noticeable
when animating the reveal of Suspense boundaries e.g. with the upcoming
<code class="notranslate"><ViewTransition></code> Component. React
will batch as much reveals as possible before the first paint while
trying to hit popular first-contentful paint metrics.</li>
<li>Add Node Web Streams (<code class="notranslate">prerender</code>,
<code class="notranslate">renderToReadableStream</code>) to
server-side-rendering APIs for Node.js</li>
<li>Use underscore instead of <code class="notranslate">:</code> IDs
generated by useId</li>
</ul>
<h2 dir="auto">All Changes</h2>
<h3 dir="auto">React</h3>
<ul dir="auto">
<li>
<code class="notranslate"><Activity /></code> was developed over
many years, starting before <code
class="notranslate">ClassComponent.setState</code> (<a
href="https://bounce.depfu.com/github.com/acdlite">@acdlite</a> <a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
and many others)</li>
<li>Stringify context as "SomeContext" instead of "SomeContext.Provider"
(<a href="https://bounce.depfu.com/github.com/kassens">@kassens</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33507">#33507</a>)</li>
<li>Include stack of cause of React instrumentation errors with <code
class="notranslate">%o</code> placeholder (<a
href="https://bounce.depfu.com/github.com/eps1lon">@eps1lon</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34198">#34198</a>)</li>
<li>Fix infinite <code class="notranslate">useDeferredValue</code> loop
in popstate event (<a
href="https://bounce.depfu.com/github.com/acdlite">@acdlite</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32821">#32821</a>)</li>
<li>Fix a bug when an initial value was passed to <code
class="notranslate">useDeferredValue</code> (<a
href="https://bounce.depfu.com/github.com/acdlite">@acdlite</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34376">#34376</a>)</li>
<li>Fix a crash when submitting forms with Client Actions (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33055">#33055</a>)</li>
<li>Hide/unhide the content of dehydrated suspense boundaries if they
resuspend (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32900">#32900</a>)</li>
<li>Avoid stack overflow on wide trees during Hot Reload (<a
href="https://bounce.depfu.com/github.com/sophiebits">@sophiebits</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34145">#34145</a>)</li>
<li>Improve Owner and Component stacks in various places (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>,
<a href="https://bounce.depfu.com/github.com/eps1lon">@eps1lon</a>: <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33629">#33629</a>,
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33724">#33724</a>,
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32735">#32735</a>,
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33723">#33723</a>)</li>
<li>Add <code class="notranslate">cacheSignal</code> (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33557">#33557</a>)</li>
</ul>
<h3 dir="auto">React DOM</h3>
<ul dir="auto">
<li>Block on Suspensey Fonts during reveal of server-side-rendered
content (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33342">#33342</a>)</li>
<li>Use underscore instead of <code class="notranslate">:</code> for IDs
generated by <code class="notranslate">useId</code> (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>,
<a href="https://bounce.depfu.com/github.com/eps1lon">@eps1lon</a>: <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32001">#32001</a>,
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33342">#33342</a><a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33099">#33099</a>,
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33422">#33422</a>)</li>
<li>Stop warning when ARIA 1.3 attributes are used (<a
href="https://bounce.depfu.com/github.com/Abdul-Omira">@Abdul-Omira</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34264">#34264</a>)</li>
<li>Allow <code class="notranslate">nonce</code> to be used on hoistable
styles (<a
href="https://bounce.depfu.com/github.com/Andarist">@Andarist</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32461">#32461</a>)</li>
<li>Warn for using a React owned node as a Container if it also has text
content (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32774">#32774</a>)</li>
<li>s/HTML/text for for error messages if text hydration mismatches (<a
href="https://bounce.depfu.com/github.com/rickhanlonii">@rickhanlonii</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32763">#32763</a>)</li>
<li>Fix a bug with <code class="notranslate">React.use</code> inside
<code class="notranslate">React.lazy</code>-ed Component (<a
href="https://bounce.depfu.com/github.com/hi-ogawa">@hi-ogawa</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33941">#33941</a>)</li>
<li>Enable the <code class="notranslate">progressiveChunkSize</code>
option for server-side-rendering APIs (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33027">#33027</a>)</li>
<li>Fix a bug with deeply nested Suspense inside Suspense fallback when
server-side-rendering (<a
href="https://bounce.depfu.com/github.com/gnoff">@gnoff</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33467">#33467</a>)</li>
<li>Avoid hanging when suspending after aborting while rendering (<a
href="https://bounce.depfu.com/github.com/gnoff">@gnoff</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34192">#34192</a>)</li>
<li>Add Node Web Streams to server-side-rendering APIs for Node.js (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33475">#33475</a>)</li>
</ul>
<h3 dir="auto">React Server Components</h3>
<ul dir="auto">
<li>Preload <code class="notranslate"><img></code> and <code
class="notranslate"><link></code> using hints before they're
rendered (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34604">#34604</a>)</li>
<li>Log error if production elements are rendered during development (<a
href="https://bounce.depfu.com/github.com/eps1lon">@eps1lon</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34189">#34189</a>)</li>
<li>Fix a bug when returning a Temporary reference (e.g. a Client
Reference) from Server Functions (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34084">#34084</a>,
<a href="https://bounce.depfu.com/github.com/denk0403">@denk0403</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33761">#33761</a>)</li>
<li>Pass line/column to <code
class="notranslate">filterStackFrame</code> (<a
href="https://bounce.depfu.com/github.com/eps1lon">@eps1lon</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33707">#33707</a>)</li>
<li>Support Async Modules in Turbopack Server References (<a
href="https://bounce.depfu.com/github.com/lubieowoce">@lubieowoce</a> <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34531">#34531</a>)</li>
<li>Add support for .mjs file extension in Webpack (<a
href="https://bounce.depfu.com/github.com/jennyscript">@jennyscript</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33028">#33028</a>)</li>
<li>Fix a wrong missing key warning (<a
href="https://bounce.depfu.com/github.com/unstubbable">@unstubbable</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34350">#34350</a>)</li>
<li>Make console log resolve in predictable order (<a
href="https://bounce.depfu.com/github.com/sebmarkbage">@sebmarkbage</a>
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33665">#33665</a>)</li>
</ul>
<h3 dir="auto">React Reconciler</h3>
<ul dir="auto">
<li>
<a
href="https://bounce.depfu.com/github.com/facebook/react/blob/v19.2.0/packages/react-reconciler/src/ReactFiberReconciler.js#L255-L261">createContainer</a>
and <a
href="https://bounce.depfu.com/github.com/facebook/react/blob/v19.2.0/packages/react-reconciler/src/ReactFiberReconciler.js#L305-L312">createHydrationContainer</a>
had their parameter order adjusted after <code
class="notranslate">on*</code> handlers to account for upcoming
experimental APIs</li>
</ul>
<h2 dir="auto">eslint-plugin-react-hooks@6.1.0</h2>
<p dir="auto"><strong>Note:</strong> Version 6.0.0 was mistakenly
released and immediately deprecated and untagged on npm. This is the
first official 6.x major release and includes breaking changes.</p>
<ul dir="auto">
<li>
<strong>Breaking:</strong> Require Node.js 18 or newer. (<a
href="https://bounce.depfu.com/github.com/michaelfaith">@michaelfaith</a>
in <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32458">#32458</a>)</li>
<li>
<strong>Breaking:</strong> Flat config is now the default <code
class="notranslate">recommended</code> preset. Legacy config moved to
<code class="notranslate">recommended-legacy</code>. (<a
href="https://bounce.depfu.com/github.com/michaelfaith">@michaelfaith</a>
in <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/32457">#32457</a>)</li>
<li>
<strong>New Violations:</strong> Disallow calling <code
class="notranslate">use</code> within try/catch blocks. (<a
href="https://bounce.depfu.com/github.com/poteto">@poteto</a> in <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34040">#34040</a>)</li>
<li>
<strong>New Violations:</strong> Disallow calling <code
class="notranslate">useEffectEvent</code> functions in arbitrary
closures. (<a
href="https://bounce.depfu.com/github.com/jbrown215">@jbrown215</a> in
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/33544">#33544</a>)</li>
<li>Handle <code class="notranslate">React.useEffect</code> in addition
to <code class="notranslate">useEffect</code> in rules-of-hooks. (<a
href="https://bounce.depfu.com/github.com/Ayc0">@Ayc0</a> in <a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34076">#34076</a>)</li>
<li>Added <code class="notranslate">react-hooks</code> settings config
option that to accept <code
class="notranslate">additionalEffectHooks</code> that are used across
exhaustive-deps and rules-of-hooks rules. (<a
href="https://bounce.depfu.com/github.com/jbrown215">@jbrown215</a>) in
<a
href="https://bounce.depfu.com/github.com/facebook/react/pull/34497">#34497</a>
</li>
</ul></blockquote>
<p><em>Does any of this look wrong? <a
href="https://depfu.com/packages/npm/react-dom/feedback">Please let us
know.</a></em></p>
</details>
<details>
<summary>Commits</summary>
<p><a
href="https://github.com/facebook/react/compare/02ef49580922f87180f32618b9d1c70b75b968b7...ae74234eae6ebd62f19190731278e20bc1c37d51">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>
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2025-10-09 14:33:23 -04:00
|
|
|
scheduler@0.27.0: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
schema-utils@4.3.3:
|
|
|
|
|
dependencies:
|
|
|
|
|
'@types/json-schema': 7.0.15
|
2026-05-22 16:57:46 +02:00
|
|
|
ajv: 8.20.0
|
|
|
|
|
ajv-formats: 2.1.1(ajv@8.20.0)
|
|
|
|
|
ajv-keywords: 5.1.0(ajv@8.20.0)
|
2026-02-18 11:58:49 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
semver@7.8.5: {}
|
2026-06-19 13:11:16 +02:00
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
sharp@0.34.5:
|
|
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@img/colour': 1.1.0
|
2025-11-20 10:54:23 -05:00
|
|
|
detect-libc: 2.1.2
|
2026-08-04 13:55:03 +02:00
|
|
|
semver: 7.8.5
|
2024-11-26 18:31:12 +01:00
|
|
|
optionalDependencies:
|
2025-11-20 10:54:23 -05:00
|
|
|
'@img/sharp-darwin-arm64': 0.34.5
|
|
|
|
|
'@img/sharp-darwin-x64': 0.34.5
|
|
|
|
|
'@img/sharp-libvips-darwin-arm64': 1.2.4
|
|
|
|
|
'@img/sharp-libvips-darwin-x64': 1.2.4
|
|
|
|
|
'@img/sharp-libvips-linux-arm': 1.2.4
|
|
|
|
|
'@img/sharp-libvips-linux-arm64': 1.2.4
|
|
|
|
|
'@img/sharp-libvips-linux-ppc64': 1.2.4
|
|
|
|
|
'@img/sharp-libvips-linux-riscv64': 1.2.4
|
|
|
|
|
'@img/sharp-libvips-linux-s390x': 1.2.4
|
|
|
|
|
'@img/sharp-libvips-linux-x64': 1.2.4
|
|
|
|
|
'@img/sharp-libvips-linuxmusl-arm64': 1.2.4
|
|
|
|
|
'@img/sharp-libvips-linuxmusl-x64': 1.2.4
|
|
|
|
|
'@img/sharp-linux-arm': 0.34.5
|
|
|
|
|
'@img/sharp-linux-arm64': 0.34.5
|
|
|
|
|
'@img/sharp-linux-ppc64': 0.34.5
|
|
|
|
|
'@img/sharp-linux-riscv64': 0.34.5
|
|
|
|
|
'@img/sharp-linux-s390x': 0.34.5
|
|
|
|
|
'@img/sharp-linux-x64': 0.34.5
|
|
|
|
|
'@img/sharp-linuxmusl-arm64': 0.34.5
|
|
|
|
|
'@img/sharp-linuxmusl-x64': 0.34.5
|
|
|
|
|
'@img/sharp-wasm32': 0.34.5
|
|
|
|
|
'@img/sharp-win32-arm64': 0.34.5
|
|
|
|
|
'@img/sharp-win32-ia32': 0.34.5
|
|
|
|
|
'@img/sharp-win32-x64': 0.34.5
|
2024-11-26 18:31:12 +01:00
|
|
|
optional: true
|
|
|
|
|
|
2025-11-20 10:54:23 -05:00
|
|
|
siginfo@2.0.0: {}
|
|
|
|
|
|
|
|
|
|
signal-exit@4.1.0: {}
|
2024-11-26 18:31:12 +01:00
|
|
|
|
2024-09-18 16:45:43 +02:00
|
|
|
slash@5.1.0: {}
|
|
|
|
|
|
2024-10-03 11:15:18 +02:00
|
|
|
source-map-js@1.2.1: {}
|
|
|
|
|
|
2024-09-04 10:09:24 +02:00
|
|
|
source-map-support@0.5.21:
|
|
|
|
|
dependencies:
|
|
|
|
|
buffer-from: 1.1.2
|
|
|
|
|
source-map: 0.6.1
|
|
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
source-map@0.6.1: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2025-11-19 18:18:45 -05:00
|
|
|
source-map@0.7.6: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
stackback@0.0.2: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
std-env@4.1.0: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
std-env@4.2.0: {}
|
|
|
|
|
|
2026-06-09 10:44:01 +00:00
|
|
|
styled-jsx@5.1.6(react@19.2.7):
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
|
|
|
|
client-only: 0.0.1
|
2026-06-09 10:44:01 +00:00
|
|
|
react: 19.2.7
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
sucrase@3.35.1:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@jridgewell/gen-mapping': 0.3.13
|
2024-03-05 14:23:26 +01:00
|
|
|
commander: 4.1.1
|
|
|
|
|
lines-and-columns: 1.2.4
|
|
|
|
|
mz: 2.7.0
|
2026-05-22 16:57:46 +02:00
|
|
|
pirates: 4.0.7
|
|
|
|
|
tinyglobby: 0.2.16
|
2024-03-05 14:23:26 +01:00
|
|
|
ts-interface-checker: 0.1.13
|
|
|
|
|
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
supports-color@8.1.1:
|
|
|
|
|
dependencies:
|
|
|
|
|
has-flag: 4.0.0
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
supports-preserve-symlinks-flag@1.0.0: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2025-12-26 12:36:51 -05:00
|
|
|
tagged-tag@1.0.0: {}
|
|
|
|
|
|
2026-06-25 19:14:10 +02:00
|
|
|
tailwindcss@3.4.19(yaml@2.9.0):
|
2024-10-24 11:00:25 -04:00
|
|
|
dependencies:
|
|
|
|
|
'@alloc/quick-lru': 5.2.0
|
|
|
|
|
arg: 5.0.2
|
|
|
|
|
chokidar: 3.6.0
|
|
|
|
|
didyoumean: 1.2.2
|
|
|
|
|
dlv: 1.1.3
|
2025-01-13 11:11:35 +01:00
|
|
|
fast-glob: 3.3.3
|
2024-10-24 11:00:25 -04:00
|
|
|
glob-parent: 6.0.2
|
|
|
|
|
is-glob: 4.0.3
|
2026-05-22 16:57:46 +02:00
|
|
|
jiti: 1.21.7
|
|
|
|
|
lilconfig: 3.1.3
|
|
|
|
|
micromatch: 4.0.8
|
2024-10-24 11:00:25 -04:00
|
|
|
normalize-path: 3.0.0
|
|
|
|
|
object-hash: 3.0.0
|
|
|
|
|
picocolors: 1.1.1
|
2026-08-04 13:55:03 +02:00
|
|
|
postcss: 8.5.16
|
|
|
|
|
postcss-import: 15.1.0(postcss@8.5.16)
|
|
|
|
|
postcss-js: 4.1.0(postcss@8.5.16)
|
|
|
|
|
postcss-load-config: 6.0.1(jiti@1.21.7)(postcss@8.5.16)(yaml@2.9.0)
|
|
|
|
|
postcss-nested: 6.2.0(postcss@8.5.16)
|
2024-10-24 11:00:25 -04:00
|
|
|
postcss-selector-parser: 6.1.2
|
2026-05-22 16:57:46 +02:00
|
|
|
resolve: 1.22.12
|
|
|
|
|
sucrase: 3.35.1
|
2024-10-24 11:00:25 -04:00
|
|
|
transitivePeerDependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
- tsx
|
|
|
|
|
- yaml
|
2024-10-24 11:00:25 -04:00
|
|
|
|
Update enhanced-resolve 5.20.1 → 5.21.0 (minor) (#19998)
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="https://depfu.com/packages/npm/enhanced-resolve/feedback">Please
let us know.</a></em></p>
</details>
<details>
<summary>Commits</summary>
<p><a
href="https://github.com/webpack/enhanced-resolve/compare/ebc67d38969e8abe6789a51968380fa721fea778...35035ca158f1c8ada86fcf1653f319cbce669200">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>
2026-05-01 11:29:19 +00:00
|
|
|
tapable@2.3.3: {}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
terser@5.48.0:
|
2024-09-04 10:09:24 +02:00
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@jridgewell/source-map': 0.3.11
|
2026-04-24 21:21:12 +02:00
|
|
|
acorn: 8.16.0
|
2024-09-04 10:09:24 +02:00
|
|
|
commander: 2.20.3
|
|
|
|
|
source-map-support: 0.5.21
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
thenify-all@1.6.0:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
|
|
|
|
thenify: 3.3.1
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
thenify@3.3.1:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
|
|
|
|
any-promise: 1.3.0
|
|
|
|
|
|
2025-03-03 13:22:51 +01:00
|
|
|
tiny-jsonc@1.0.2: {}
|
Add integration test setup and tests for the Vite integration (#14089)
This PR adds a new root `/integrations` folder that will be the home of
integration tests. The idea of these tests is to use Tailwind in various
setups just like our users would (by only using the publishable npm
builds).
To avoid issues with concurrent tests making changes to the file system,
to make it very easy to test through a range of versions, and to avoid
changing configuration objects over and over in test runs, we decided to
inline the scaffolding completely into the test file and have no
examples checked into the repo.
Here's an example of how this can look like for a simple Vite test:
```ts
test('works with production builds', {
fs: {
'package.json': json`
{
"type": "module",
"dependencies": {
"@tailwindcss/vite": "workspace:^",
"tailwindcss": "workspace:^"
},
"devDependencies": {
"vite": "^5.3.5"
}
}
`,
'vite.config.ts': ts`
import tailwindcss from '@tailwindcss/vite'
import { defineConfig } from 'vite'
export default defineConfig({
build: { cssMinify: false },
plugins: [tailwindcss()],
})
`,
'index.html': html`
<head>
<link rel="stylesheet" href="./src/index.css">
</head>
<body>
<div class="underline m-2">Hello, world!</div>
</body>
`,
'src/index.css': css`
@import 'tailwindcss/theme' reference;
@import 'tailwindcss/utilities';
`,
},
},
async ({ fs, exec }) => {
await exec('pnpm vite build')
expect.assertions(2)
for (let [path, content] of await fs.glob('dist/**/*.css')) {
expect(path).toMatch(/\.css$/)
expect(stripTailwindComment(content)).toMatchInlineSnapshot(
`
".m-2 {
margin: var(--spacing-2, .5rem);
}
.underline {
text-decoration-line: underline;
}"
`,
)
}
},
)
```
By defining all dependencies this way, we never have to worry about
which fixtures are checked in and can more easily describe changes to
the setup.
For ergonomics, we've also added the [`embed` prettier
plugin](https://github.com/Sec-ant/prettier-plugin-embed). This will
mean that files inlined in the `fs` setup are properly indented. No
extra work needed!
If you're using VS Code, I can also recommend the [Language
Literals](https://marketplace.visualstudio.com/items?itemName=sissel.language-literals)
extension so that syntax highlighting also _just works_.
A neat feature of inlining the scaffolding like this is to make it very
simple to test through a variety of versions. For example, here's how we
can set up a test against Vite 5 and Vite 4:
```js
;['^4.5.3', '^5.3.5'].forEach(viteVersion => {
test(`works with production builds for Vite ${viteVersion}`, {
fs: {
'package.json': json`
{
"type": "module",
"devDependencies": {
"vite": "${viteVersion}"
}
}
`,
async () => {
// Do something
},
)
})
```
## Philosophy
Before we dive into the specifics, I want to clearly state the design
considerations we have chosen for this new test suite:
- All file mutations should be done in temp folders, nothing should ever
mess with your working directory
- Windows as a first-class citizen
- Have a clean and simple API that describes the test setup only using
public APIs
- Focus on reliability (make sure cleanup scripts work and are tolerant
to various error scenarios)
- If a user reports an issue with a specific configuration, we want to
be able to reproduce them with integration tests, no matter how obscure
the setup (this means the test need to be in control of most of the
variables)
- Tests should be reasonably fast (obviously this depends on the
integration. If we use a slow build tool, we can't magically speed it
up, but our overhead should be minimal).
## How it works
The current implementation provides a custom `test` helper function
that, when used, sets up the environment according to the configuration.
It'll create a new temporary directory and create all files, ensuring
things like proper `\r\n` line endings on Windows.
We do have to patch the `package.json` specifically, since we can not
use public versions of the tailwindcss packages as we want to be able to
test against a development build. To make this happen, every `pnpm
build` run now creates tarballs of the npm modules (that contain only
the files that would also in the published build). We then patch the
`package.json` to rewrite `workspace:^` versions to link to those
tarballs. We found this to work reliably on Windows and macOS as well as
being fast enough to not cause any issues. Furthermore we also decided
to use `pnpm` as the version manager for integration tests because of
it's global module cache (so installing `vite` is fast as soon as you
installed it once).
The test function will receive a few utilities that it can use to more
easily interact with the temp dir. One example is a `fs.glob` function
that you can use to easily find files in eventual `dist/` directories or
helpers around `spawn` and `exec` that make sure that processes are
cleaned up correctly.
Because we use tarballs from our build dependencies, working on changes
requires a workflow where you run `pnpm build` before running `pnpm
test:integrations`. However it also means we can run clients like our
CLI client with no additional overhead—just install the dependency like
any user would and set up your test cases this way.
## Test plan
This PR also includes two Vite specific integration tests: One testing a
static build (`pnpm vite build`) and one a dev mode build (`pnpm vite
dev`) that also makes changes to the file system and asserts that the
resources properly update.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-08-02 11:50:49 +02:00
|
|
|
|
2024-08-09 16:12:24 +02:00
|
|
|
tinybench@2.9.0: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
tinyclip@0.1.15: {}
|
2026-04-24 21:21:12 +02:00
|
|
|
|
2025-02-03 11:20:51 +01:00
|
|
|
tinyexec@0.3.2: {}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
tinyexec@1.1.2: {}
|
2025-06-24 18:31:17 +02:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
tinyglobby@0.2.16:
|
|
|
|
|
dependencies:
|
|
|
|
|
fdir: 6.5.0(picomatch@4.0.4)
|
|
|
|
|
picomatch: 4.0.4
|
|
|
|
|
|
2026-07-02 11:45:49 +02:00
|
|
|
tinyglobby@0.2.17:
|
|
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
fdir: 6.5.0(picomatch@4.0.5)
|
|
|
|
|
picomatch: 4.0.5
|
2026-07-02 11:45:49 +02:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
tinyrainbow@3.1.0: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
to-regex-range@5.0.1:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
|
|
|
|
is-number: 7.0.0
|
|
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
tree-kill@1.2.2: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
tree-sitter-javascript@0.23.1(tree-sitter@0.25.1):
|
2024-10-14 17:45:36 +02:00
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
node-addon-api: 8.7.0
|
|
|
|
|
node-gyp-build: 4.8.4
|
2024-11-18 10:23:22 +01:00
|
|
|
optionalDependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
tree-sitter: 0.25.1
|
2024-11-18 10:23:22 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
tree-sitter-typescript@0.23.2(tree-sitter@0.25.1):
|
2024-11-18 10:23:22 +01:00
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
node-addon-api: 8.7.0
|
|
|
|
|
node-gyp-build: 4.8.4
|
2026-08-04 13:55:03 +02:00
|
|
|
tree-sitter-javascript: 0.23.1(tree-sitter@0.25.1)
|
2024-11-18 10:23:22 +01:00
|
|
|
optionalDependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
tree-sitter: 0.25.1
|
2024-10-14 17:45:36 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
tree-sitter@0.25.1:
|
2024-10-14 17:45:36 +02:00
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
node-addon-api: 8.7.0
|
2025-01-10 10:26:48 +01:00
|
|
|
node-gyp-build: 4.8.4
|
2024-10-14 17:45:36 +02:00
|
|
|
|
2024-05-24 15:07:44 +02:00
|
|
|
ts-interface-checker@0.1.13: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2025-09-19 17:08:41 +02:00
|
|
|
tslib@2.8.1: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
tsup@8.5.1(jiti@2.7.0)(postcss@8.5.25)(typescript@5.9.3)(yaml@2.9.0):
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
bundle-require: 5.1.0(esbuild@0.27.7)
|
2024-03-05 14:23:26 +01:00
|
|
|
cac: 6.7.14
|
2025-02-03 11:20:51 +01:00
|
|
|
chokidar: 4.0.3
|
2026-05-22 16:57:46 +02:00
|
|
|
consola: 3.4.2
|
2025-11-19 18:18:45 -05:00
|
|
|
debug: 4.4.3
|
2026-05-22 16:57:46 +02:00
|
|
|
esbuild: 0.27.7
|
2025-05-29 13:38:00 -04:00
|
|
|
fix-dts-default-cjs-exports: 1.0.1
|
2024-03-05 14:23:26 +01:00
|
|
|
joycon: 3.1.1
|
2024-10-24 11:25:50 +02:00
|
|
|
picocolors: 1.1.1
|
2026-08-04 13:55:03 +02:00
|
|
|
postcss-load-config: 6.0.1(jiti@2.7.0)(postcss@8.5.25)(yaml@2.9.0)
|
2024-03-05 14:23:26 +01:00
|
|
|
resolve-from: 5.0.0
|
2026-05-22 16:57:46 +02:00
|
|
|
rollup: 4.60.4
|
2025-11-19 18:18:45 -05:00
|
|
|
source-map: 0.7.6
|
2026-05-22 16:57:46 +02:00
|
|
|
sucrase: 3.35.1
|
2025-02-03 11:20:51 +01:00
|
|
|
tinyexec: 0.3.2
|
2026-05-22 16:57:46 +02:00
|
|
|
tinyglobby: 0.2.16
|
2024-03-05 14:23:26 +01:00
|
|
|
tree-kill: 1.2.2
|
2024-05-24 15:07:44 +02:00
|
|
|
optionalDependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
postcss: 8.5.25
|
2026-04-24 21:21:12 +02:00
|
|
|
typescript: 5.9.3
|
2024-03-05 14:23:26 +01:00
|
|
|
transitivePeerDependencies:
|
2024-08-02 10:33:14 +02:00
|
|
|
- jiti
|
2024-03-05 14:23:26 +01:00
|
|
|
- supports-color
|
2024-08-02 10:33:14 +02:00
|
|
|
- tsx
|
|
|
|
|
- yaml
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
turbo@2.10.8:
|
2024-03-05 14:23:26 +01:00
|
|
|
optionalDependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@turbo/darwin-64': 2.10.8
|
|
|
|
|
'@turbo/darwin-arm64': 2.10.8
|
|
|
|
|
'@turbo/linux-64': 2.10.8
|
|
|
|
|
'@turbo/linux-arm64': 2.10.8
|
|
|
|
|
'@turbo/windows-64': 2.10.8
|
|
|
|
|
'@turbo/windows-arm64': 2.10.8
|
2024-05-24 15:07:44 +02:00
|
|
|
|
2025-04-11 17:19:55 +02:00
|
|
|
typanion@3.14.0: {}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
type-fest@5.6.0:
|
2025-12-26 12:36:51 -05:00
|
|
|
dependencies:
|
|
|
|
|
tagged-tag: 1.0.0
|
Add integration test setup and tests for the Vite integration (#14089)
This PR adds a new root `/integrations` folder that will be the home of
integration tests. The idea of these tests is to use Tailwind in various
setups just like our users would (by only using the publishable npm
builds).
To avoid issues with concurrent tests making changes to the file system,
to make it very easy to test through a range of versions, and to avoid
changing configuration objects over and over in test runs, we decided to
inline the scaffolding completely into the test file and have no
examples checked into the repo.
Here's an example of how this can look like for a simple Vite test:
```ts
test('works with production builds', {
fs: {
'package.json': json`
{
"type": "module",
"dependencies": {
"@tailwindcss/vite": "workspace:^",
"tailwindcss": "workspace:^"
},
"devDependencies": {
"vite": "^5.3.5"
}
}
`,
'vite.config.ts': ts`
import tailwindcss from '@tailwindcss/vite'
import { defineConfig } from 'vite'
export default defineConfig({
build: { cssMinify: false },
plugins: [tailwindcss()],
})
`,
'index.html': html`
<head>
<link rel="stylesheet" href="./src/index.css">
</head>
<body>
<div class="underline m-2">Hello, world!</div>
</body>
`,
'src/index.css': css`
@import 'tailwindcss/theme' reference;
@import 'tailwindcss/utilities';
`,
},
},
async ({ fs, exec }) => {
await exec('pnpm vite build')
expect.assertions(2)
for (let [path, content] of await fs.glob('dist/**/*.css')) {
expect(path).toMatch(/\.css$/)
expect(stripTailwindComment(content)).toMatchInlineSnapshot(
`
".m-2 {
margin: var(--spacing-2, .5rem);
}
.underline {
text-decoration-line: underline;
}"
`,
)
}
},
)
```
By defining all dependencies this way, we never have to worry about
which fixtures are checked in and can more easily describe changes to
the setup.
For ergonomics, we've also added the [`embed` prettier
plugin](https://github.com/Sec-ant/prettier-plugin-embed). This will
mean that files inlined in the `fs` setup are properly indented. No
extra work needed!
If you're using VS Code, I can also recommend the [Language
Literals](https://marketplace.visualstudio.com/items?itemName=sissel.language-literals)
extension so that syntax highlighting also _just works_.
A neat feature of inlining the scaffolding like this is to make it very
simple to test through a variety of versions. For example, here's how we
can set up a test against Vite 5 and Vite 4:
```js
;['^4.5.3', '^5.3.5'].forEach(viteVersion => {
test(`works with production builds for Vite ${viteVersion}`, {
fs: {
'package.json': json`
{
"type": "module",
"devDependencies": {
"vite": "${viteVersion}"
}
}
`,
async () => {
// Do something
},
)
})
```
## Philosophy
Before we dive into the specifics, I want to clearly state the design
considerations we have chosen for this new test suite:
- All file mutations should be done in temp folders, nothing should ever
mess with your working directory
- Windows as a first-class citizen
- Have a clean and simple API that describes the test setup only using
public APIs
- Focus on reliability (make sure cleanup scripts work and are tolerant
to various error scenarios)
- If a user reports an issue with a specific configuration, we want to
be able to reproduce them with integration tests, no matter how obscure
the setup (this means the test need to be in control of most of the
variables)
- Tests should be reasonably fast (obviously this depends on the
integration. If we use a slow build tool, we can't magically speed it
up, but our overhead should be minimal).
## How it works
The current implementation provides a custom `test` helper function
that, when used, sets up the environment according to the configuration.
It'll create a new temporary directory and create all files, ensuring
things like proper `\r\n` line endings on Windows.
We do have to patch the `package.json` specifically, since we can not
use public versions of the tailwindcss packages as we want to be able to
test against a development build. To make this happen, every `pnpm
build` run now creates tarballs of the npm modules (that contain only
the files that would also in the published build). We then patch the
`package.json` to rewrite `workspace:^` versions to link to those
tarballs. We found this to work reliably on Windows and macOS as well as
being fast enough to not cause any issues. Furthermore we also decided
to use `pnpm` as the version manager for integration tests because of
it's global module cache (so installing `vite` is fast as soon as you
installed it once).
The test function will receive a few utilities that it can use to more
easily interact with the temp dir. One example is a `fs.glob` function
that you can use to easily find files in eventual `dist/` directories or
helpers around `spawn` and `exec` that make sure that processes are
cleaned up correctly.
Because we use tarballs from our build dependencies, working on changes
requires a workflow where you run `pnpm build` before running `pnpm
test:integrations`. However it also means we can run clients like our
CLI client with no additional overhead—just install the dependency like
any user would and set up your test cases this way.
## Test plan
This PR also includes two Vite specific integration tests: One testing a
static build (`pnpm vite build`) and one a dev mode build (`pnpm vite
dev`) that also makes changes to the file system and asserts that the
resources properly update.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-08-02 11:50:49 +02:00
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
typescript@5.9.3: {}
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-04-23 12:51:20 +02:00
|
|
|
typescript@6.0.3: {}
|
2024-10-24 11:00:25 -04:00
|
|
|
|
2026-05-07 12:43:28 +00:00
|
|
|
ufo@1.6.4: {}
|
|
|
|
|
|
2025-01-07 09:57:34 -05:00
|
|
|
uncrypto@0.1.3: {}
|
|
|
|
|
|
2025-06-24 18:31:17 +02:00
|
|
|
undici-types@6.21.0: {}
|
|
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
undici-types@7.24.6: {}
|
|
|
|
|
|
2026-04-24 21:21:12 +02:00
|
|
|
unicorn-magic@0.4.0: {}
|
2024-09-18 16:45:43 +02:00
|
|
|
|
2026-05-22 16:57:46 +02:00
|
|
|
universal-user-agent@7.0.3: {}
|
2025-04-11 17:19:55 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
untun@0.2.2: {}
|
2025-01-07 09:57:34 -05:00
|
|
|
|
2026-04-23 12:51:20 +02:00
|
|
|
update-browserslist-db@1.2.3(browserslist@4.28.2):
|
|
|
|
|
dependencies:
|
|
|
|
|
browserslist: 4.28.2
|
|
|
|
|
escalade: 3.2.0
|
|
|
|
|
picocolors: 1.1.1
|
|
|
|
|
|
2026-05-07 12:43:28 +00:00
|
|
|
uqr@0.1.3: {}
|
2025-01-07 09:57:34 -05:00
|
|
|
|
Add CSS codemods for migrating `@layer utilities` (#14455)
This PR adds CSS codemods for migrating existing `@layer utilities` to
`@utility` directives.
This PR has the ability to migrate the following cases:
---
The most basic case is when you want to migrate a simple class to a
utility directive.
Input:
```css
@layer utilities {
.foo {
color: red;
}
.bar {
color: blue;
}
}
```
Output:
```css
@utility foo {
color: red;
}
@utility bar {
color: blue;
}
```
You'll notice that the class `foo` will be used as the utility name, the
declarations (and the rest of the body of the rule) will become the body
of the `@utility` definition.
---
In v3, every class in a selector will become a utility. To correctly
migrate this to `@utility` directives, we have to register each class in
the selector and generate `n` utilities.
We can use nesting syntax, and replace the current class with `&` to
ensure that the final result behaves the same.
Input:
```css
@layer utilities {
.foo .bar .baz {
color: red;
}
}
```
Output:
```css
@utility foo {
& .bar .baz {
color: red;
}
}
@utility bar {
.foo & .baz {
color: red;
}
}
@utility .baz {
.foo .bar & {
color: red;
}
}
```
In this case, it could be that you know that some of them will never be
used as a utility (e.g.: `hover:bar`), but then you can safely remove
them.
---
Even classes inside of `:has(…)` will become a utility. The only
exception to the rule is that we don't do it for `:not(…)`.
Input:
```css
@layer utilities {
.foo .bar:not(.qux):has(.baz) {
display: none;
}
}
```
Output:
```css
@utility foo {
& .bar:not(.qux):has(.baz) {
display: none;
}
}
@utility bar {
.foo &:not(.qux):has(.baz) {
display: none;
}
}
@utility baz {
.foo .bar:not(.qux):has(&) {
display: none;
}
}
```
Notice that there is no `@utility qux` because it was used inside of
`:not(…)`.
---
When classes are nested inside at-rules, then these classes will also
become utilities. However, the `@utility <name>` will be at the top and
the at-rules will live inside of it. If there are multiple classes
inside a shared at-rule, then the at-rule will be duplicated for each
class.
Let's look at an example to make it more clear:
Input:
```css
@layer utilities {
@media (min-width: 640px) {
.foo {
color: red;
}
.bar {
color: blue;
}
@media (min-width: 1024px) {
.baz {
color: green;
}
@media (min-width: 1280px) {
.qux {
color: yellow;
}
}
}
}
}
```
Output:
```css
@utility foo {
@media (min-width: 640px) {
color: red;
}
}
@utility bar {
@media (min-width: 640px) {
color: blue;
}
}
@utility baz {
@media (min-width: 640px) {
@media (min-width: 1024px) {
color: green;
}
}
}
@utility qux {
@media (min-width: 640px) {
@media (min-width: 1024px) {
@media (min-width: 1280px) {
color: yellow;
}
}
}
}
```
---
When classes result in multiple `@utility` directives with the same
name, then the definitions will be merged together.
Input:
```css
@layer utilities {
.no-scrollbar::-webkit-scrollbar {
display: none;
}
.no-scrollbar {
-ms-overflow-style: none;
scrollbar-width: none;
}
}
```
Intermediate representation:
```css
@utility no-scrollbar {
&::-webkit-scrollbar {
display: none;
}
}
@utility no-scrollbar {
-ms-overflow-style: none;
scrollbar-width: none;
}
```
Output:
```css
@utility no-scrollbar {
&::-webkit-scrollbar {
display: none;
}
-ms-overflow-style: none;
scrollbar-width: none
}
```
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-09-24 18:17:09 +02:00
|
|
|
util-deprecate@1.0.2: {}
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
vite@8.2.0(@types/node@22.20.1)(esbuild@0.27.7)(jiti@2.7.0)(terser@5.48.0)(yaml@2.9.0):
|
2025-11-21 00:16:20 +01:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss: 1.33.0(patch_hash=1d4a8800d60d13d42887b88b3a86576df4b451670308145fb432ec8abbf40930)
|
|
|
|
|
picomatch: 4.0.5
|
|
|
|
|
postcss: 8.5.25
|
|
|
|
|
rolldown: 1.2.1
|
2026-07-02 11:45:49 +02:00
|
|
|
tinyglobby: 0.2.17
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
optionalDependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@types/node': 22.20.1
|
2026-05-22 16:57:46 +02:00
|
|
|
esbuild: 0.27.7
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
fsevents: 2.3.3
|
2026-05-13 12:02:13 +02:00
|
|
|
jiti: 2.7.0
|
2026-05-22 16:57:46 +02:00
|
|
|
terser: 5.48.0
|
2026-06-25 19:14:10 +02:00
|
|
|
yaml: 2.9.0
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
vite@8.2.0(@types/node@25.9.1)(esbuild@0.27.7)(jiti@2.7.0)(terser@5.48.0)(yaml@2.9.0):
|
2026-05-22 16:57:46 +02:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
lightningcss: 1.33.0(patch_hash=1d4a8800d60d13d42887b88b3a86576df4b451670308145fb432ec8abbf40930)
|
|
|
|
|
picomatch: 4.0.5
|
|
|
|
|
postcss: 8.5.25
|
|
|
|
|
rolldown: 1.2.1
|
2026-07-02 11:45:49 +02:00
|
|
|
tinyglobby: 0.2.17
|
2026-05-22 16:57:46 +02:00
|
|
|
optionalDependencies:
|
|
|
|
|
'@types/node': 25.9.1
|
|
|
|
|
esbuild: 0.27.7
|
|
|
|
|
fsevents: 2.3.3
|
|
|
|
|
jiti: 2.7.0
|
|
|
|
|
terser: 5.48.0
|
2026-06-25 19:14:10 +02:00
|
|
|
yaml: 2.9.0
|
2026-05-22 16:57:46 +02:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
vitest@4.1.10(@types/node@22.20.1)(vite@8.2.0(@types/node@22.20.1)(esbuild@0.27.7)(jiti@2.7.0)(terser@5.48.0)(yaml@2.9.0)):
|
2026-04-24 21:21:12 +02:00
|
|
|
dependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@vitest/expect': 4.1.10
|
|
|
|
|
'@vitest/mocker': 4.1.10(vite@8.2.0(@types/node@22.20.1)(esbuild@0.27.7)(jiti@2.7.0)(terser@5.48.0)(yaml@2.9.0))
|
|
|
|
|
'@vitest/pretty-format': 4.1.10
|
|
|
|
|
'@vitest/runner': 4.1.10
|
|
|
|
|
'@vitest/snapshot': 4.1.10
|
|
|
|
|
'@vitest/spy': 4.1.10
|
|
|
|
|
'@vitest/utils': 4.1.10
|
2026-05-22 16:57:46 +02:00
|
|
|
es-module-lexer: 2.1.0
|
2026-04-24 21:21:12 +02:00
|
|
|
expect-type: 1.3.0
|
2025-10-31 07:34:21 -04:00
|
|
|
magic-string: 0.30.21
|
Bump dependencies (#19608)
This PR bumps a bunch of dependencies. This also moves a few
dependencies that we use in multiple packages to the pnpm catalog.
Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546,
#19545, #19609, #19581, #19620, #19619
- #19603
- #19604
- #19576
- #19575
- #19573
- #19565
- #19547
- #19546
- #19545
- #19609
- #19581
- https://github.com/tailwindlabs/tailwindcss/pull/19620
- #19620
- #19619
## Test Plan
All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
|
|
|
obug: 2.1.1
|
2025-11-21 00:16:20 +01:00
|
|
|
pathe: 2.0.3
|
2026-05-21 17:58:55 +02:00
|
|
|
picomatch: 4.0.4
|
2026-04-24 21:21:12 +02:00
|
|
|
std-env: 4.1.0
|
2024-08-09 16:12:24 +02:00
|
|
|
tinybench: 2.9.0
|
2026-05-22 16:57:46 +02:00
|
|
|
tinyexec: 1.1.2
|
2026-08-04 13:55:03 +02:00
|
|
|
tinyglobby: 0.2.17
|
2026-04-24 21:21:12 +02:00
|
|
|
tinyrainbow: 3.1.0
|
2026-08-04 13:55:03 +02:00
|
|
|
vite: 8.2.0(@types/node@22.20.1)(esbuild@0.27.7)(jiti@2.7.0)(terser@5.48.0)(yaml@2.9.0)
|
2024-08-02 10:33:14 +02:00
|
|
|
why-is-node-running: 2.3.0
|
2024-05-24 15:07:44 +02:00
|
|
|
optionalDependencies:
|
2026-08-04 13:55:03 +02:00
|
|
|
'@types/node': 22.20.1
|
2024-03-05 14:23:26 +01:00
|
|
|
transitivePeerDependencies:
|
2025-11-21 00:16:20 +01:00
|
|
|
- msw
|
2024-03-05 14:23:26 +01:00
|
|
|
|
2026-07-02 11:45:49 +02:00
|
|
|
watchpack@2.5.2:
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
dependencies:
|
|
|
|
|
graceful-fs: 4.2.11
|
|
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
webpack-sources@3.5.1: {}
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
|
2026-08-04 13:55:03 +02:00
|
|
|
webpack@5.109.2(esbuild@0.27.7)(postcss@8.5.25):
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
dependencies:
|
2026-05-22 16:57:46 +02:00
|
|
|
'@types/estree': 1.0.9
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
'@types/json-schema': 7.0.15
|
|
|
|
|
'@webassemblyjs/ast': 1.14.1
|
|
|
|
|
'@webassemblyjs/wasm-edit': 1.14.1
|
|
|
|
|
'@webassemblyjs/wasm-parser': 1.14.1
|
2026-04-24 21:21:12 +02:00
|
|
|
acorn: 8.16.0
|
|
|
|
|
browserslist: 4.28.2
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
chrome-trace-event: 1.0.4
|
2026-08-04 13:55:03 +02:00
|
|
|
enhanced-resolve: 5.24.5
|
2026-05-21 17:58:55 +02:00
|
|
|
es-module-lexer: 2.1.0
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
eslint-scope: 5.1.1
|
|
|
|
|
events: 3.3.0
|
|
|
|
|
graceful-fs: 4.2.11
|
2026-04-24 21:21:12 +02:00
|
|
|
mime-db: 1.54.0
|
2026-08-04 13:55:03 +02:00
|
|
|
minimizer-webpack-plugin: 5.6.1(esbuild@0.27.7)(postcss@8.5.25)(webpack@5.109.2(esbuild@0.27.7)(postcss@8.5.25))
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
neo-async: 2.6.2
|
|
|
|
|
schema-utils: 4.3.3
|
2026-05-21 17:58:55 +02:00
|
|
|
tapable: 2.3.3
|
2026-07-02 11:45:49 +02:00
|
|
|
watchpack: 2.5.2
|
2026-08-04 13:55:03 +02:00
|
|
|
webpack-sources: 3.5.1
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
transitivePeerDependencies:
|
2026-05-21 17:58:55 +02:00
|
|
|
- '@minify-html/node'
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
- '@swc/core'
|
2026-05-21 17:58:55 +02:00
|
|
|
- '@swc/css'
|
|
|
|
|
- '@swc/html'
|
|
|
|
|
- clean-css
|
|
|
|
|
- cssnano
|
|
|
|
|
- csso
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
- esbuild
|
2026-05-21 17:58:55 +02:00
|
|
|
- html-minifier-terser
|
|
|
|
|
- lightningcss
|
|
|
|
|
- postcss
|
Add @tailwindcss/webpack loader for Tailwind CSS v4 (#19610)
## Summary
This PR adds a new `@tailwindcss/webpack` package that provides a
dedicated webpack loader for Tailwind CSS v4. This loader works with
both standard webpack and Turbopack's webpack loader compatibility
layer.
### Why a dedicated loader?
The current webpack integration uses `postcss-loader` +
`@tailwindcss/postcss`. While this works, a dedicated loader:
- **Eliminates PostCSS as a middleman** - works directly with CSS
strings (no AST conversions)
- **Simpler and more efficient** - follows the same pattern as
`@tailwindcss/vite`
- **Better for Turbopack** - gives direct control over dependency
reporting via webpack's loader API
### How it works
The loader mirrors the Vite plugin's approach:
1. Uses `compile()` from `@tailwindcss/node` to parse CSS and resolve
`@apply` directives
2. Uses `Scanner` from `@tailwindcss/oxide` to scan content files for
utility candidates
3. Reports dependencies via `this.addDependency()` and
`this.addContextDependency()`
4. Optionally optimizes output with Lightning CSS
### Usage
```javascript
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader',
'@tailwindcss/webpack', // No PostCSS needed!
],
},
],
},
}
```
### Options
- `base` - The base directory to scan for class candidates (defaults to
`process.cwd()`)
- `optimize` - Whether to optimize/minify the output CSS (defaults to
`true` in production)
### Files added
- `packages/@tailwindcss-webpack/` - New package
- `src/index.ts` - Main loader implementation
- `src/index.cts` - CommonJS entry point for webpack compatibility
- `package.json`, `tsconfig.json`, `tsup.config.ts`, `README.md`
- `integrations/webpack/loader.test.ts` - Integration tests
- `integrations/utils.ts` - Added webpack override for transitive
dependencies
### Test plan
- [x] Build test - verifies basic compilation
- [x] Watch test - verifies HMR when adding new Tailwind classes
- [x] `@apply` test - verifies `@apply` directives work correctly
- [x] Optimization test - verifies minification works
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-01-29 15:16:31 +01:00
|
|
|
- uglify-js
|
|
|
|
|
|
2024-08-02 10:33:14 +02:00
|
|
|
why-is-node-running@2.3.0:
|
2024-03-05 14:23:26 +01:00
|
|
|
dependencies:
|
|
|
|
|
siginfo: 2.0.0
|
|
|
|
|
stackback: 0.0.2
|
2026-06-25 19:14:10 +02:00
|
|
|
|
|
|
|
|
yaml@2.9.0: {}
|