Niklas Mischkulnig

Turbopack: switch from immutable token to path prefix (#92164)

Turbopack: support targeting even older browsers (#91563) https://github.com/yowainwright/es-check/issues/403 - [x] Emit the arrow function conditionally if the target is new enough

Turbopack: properly set NODE_ENV for SWC plugins (#92579) ### What? Closes https://github.com/vercel/next.js/pull/92650 Closes https://github.com/vercel/next.js/issues/92547 When Turbopack runs SWC transform plugins, it passes a `TransformPluginMetadataContext` that includes the current `NODE_ENV`. Previously this value was hardcoded to `"development"` regardless of the actual build mode, causing SWC plugins to misbehave during production builds. ### Why? `SwcPluginMetadataContext` is used by SWC plugins (e.g. `babel-plugin-styled-components`, `@swc/plugin-emotion`) to conditionally produce development vs. production output — for instance, injecting display names and data attributes only in development. With `NODE_ENV` always set to `"development"`, plugins could never produce their optimised production output, resulting in larger bundles and missing minification in `next build`. Fixes https://github.com/vercel/next.js/issues/92547 ### How? `NODE_ENV` is now derived from the `process.env.NODE_ENV` compile-time define that is already part of `CompileTimeInfo` (the same source of truth used for dead-code elimination). The resolution happens in `EcmascriptModuleAsset::parse()` via a new shared helper `node_env_from_compile_time_info()` in `parse.rs`, and the value is stored on `TransformContext` so every `CustomTransformer` implementation can read it from `ctx.node_env` without needing access to the broader compilation context. Key design decisions: - **`TransformContext`** is the right place: it is the per-file context passed to every `CustomTransformer::transform()` call, so storing `node_env` there follows the existing pattern and avoids coupling the plugin struct to the build mode. - **Webpack analysis path**: `compile_time_info` is now threaded through `webpack_runtime()`, `module_references()`, and the webpack reference structs (`WebpackModuleAsset`, `WebpackChunkAssetReference`, `WebpackEntryAssetReference`, `WebpackRuntimeAssetReference`) so that webpack-bundled files with SWC plugin transforms also receive the correct `NODE_ENV`. - **`segment_config.rs`**: passes a placeholder but includes a comment explaining it is irrelevant since `EcmascriptInputTransforms::empty()` means no transforms run. <!-- NEXT_JS_LLM_PR -->

Turboopack: put import attributes behind a pointer, 23% faster analyze (#91347) The JS analyze microbenchmark got 23% faster: Only a tiny fraction of imports have annotations, be it `import ... with {...}` or `require(/*webpackIgnore: true*/...)`, so a `Option<Pointer<Struct>>` mkes sense here. ``` canary: references/jsonwebtoken.js/full time: [63.250 ms 63.918 ms 64.752 ms] change: [-5.2380% -3.0074% -0.8753%] (p = 0.01 < 0.05) Change within noise threshold. Found 12 outliers among 100 measurements (12.00%) 5 (5.00%) high mild 7 (7.00%) high severe now: references/jsonwebtoken.js/full time: [49.070 ms 49.166 ms 49.273 ms] change: [-24.097% -23.079% -22.237%] (p = 0.00 < 0.05) Performance has improved. Found 6 outliers among 100 measurements (6.00%) 3 (3.00%) high mild 3 (3.00%) high severe ```` This came up in https://github.com/vercel/next.js/pull/91278#issuecomment-4058275943, which added another (tiny) field to ImportAttributes. But it caused a 6% regression in the microbenchmark anyway.

Turbopack: iter_reachable_modules (#93315) Add `iter_reachable_modules` and `iter_reachable_nodes`. They actually respect unused references

Include deployment id in `cacheHandlers` keys (#93453) How was this ever working for dev? In that case, `buildId = "development"` and so it always uses the same cache key

Turbopack: move get_inner_asset into ecmascript module (#93191) `resolve_origin.get_inner_asset` showed up in Luke's statistics at a very high place. But in reality, there are only 1-3 modules per page that have any inner assets (the templates, and the edge wrapper modules). `resolve_origin.get_inner_asset` is in the hottest hot path (resolving references), so let's simply move this logic into the EcmascriptModuleAsset itself. Behavioral differences to before: - only works with static ESM `import`s, dynamic `import()`, `require`, `require.resolve`. But these are the only places that currently use it anyway. ``` 0d9738112f mischnic/remove-get-inner-asset pnpm next build --experimental-build-mode=compile 353.40s user 52.96s system 748% cpu 54.265 total pnpm next build --experimental-build-mode=compile 349.42s user 53.84s system 744% cpu 54.198 total pnpm next build --experimental-build-mode=compile 352.42s user 54.46s system 741% cpu 54.874 total 3cb77c844b canary pnpm next build --experimental-build-mode=compile 367.91s user 58.06s system 726% cpu 58.672 total pnpm next build --experimental-build-mode=compile 362.97s user 57.68s system 746% cpu 56.379 total pnpm next build --experimental-build-mode=compile 364.59s user 57.01s system 724% cpu 58.167 total ```

Lint against `.context(format!(...))` (#91122) There are unfortunately a few false-positives, because this isn't aware of type information of course.

Turbopack: compute exports without full analysis (#92823) We don't actually need the full analysis to compute exports. This can break some task cycles, and might theoretically improve task latency. The CPU time appears to be marginally higher (but not statistically significant), but no impact on overall build time: ``` * c4fdcc2651 - (14 hours ago) compute exports before final_read_hint() - Niklas Mischkulnig (origin/mischnic/get-exports-without-analyze, mischnic/get-exports-without-analyze) pnpm next build --experimental-build-mode=compile 378.10s user 58.28s system 760% cpu 57.411 total pnpm next build --experimental-build-mode=compile 383.64s user 60.32s system 738% cpu 1:00.10 total pnpm next build --experimental-build-mode=compile 378.70s user 55.65s system 718% cpu 1:00.41 total * 8ddc1cdbdd - (38 minutes ago) Use OIDC for CodSpeed (#93059) - Niklas Mischkulnig (origin/canary, origin/HEAD, canary) pnpm next build --experimental-build-mode=compile 376.95s user 58.30s system 755% cpu 57.597 total pnpm next build --experimental-build-mode=compile 375.85s user 61.75s system 738% cpu 59.230 total pnpm next build --experimental-build-mode=compile 377.75s user 63.00s system 729% cpu 1:00.39 total ```

Turbopack: `require(/* turbopackChunkingType: parallel */` (#91278) 1. Add the CJS version of `import ... with {"turbopack-chunking-type: "parallel"` 2. Allow `shared` as a chunking type 3. Improve error message for invalid values: <img width="718" height="455" alt="Bildschirmfoto 2026-03-13 um 15 07 06" src="https://github.com/user-attachments/assets/bc1efb43-4cc1-4885-b253-49c1e58b3add" />

Turbopack: rename CSS module structs for clarity (#91304)

Turbopack: pull in updated vercel/nft tests (#91651)

Add nextConfig.instrumentationClientInject (#93785) This allows injecting client bootstrap code using only next.config.js (without writing to any user source files).

Turbopack: expose hashes of source files to adapters (#93539) - [x] fix tests - [ ] add experimental flag and only enable in adapter? or is this cheap enough to just always do? - [x] disable for webpack Closes PACK-6541 For https://github.com/nextjs/adapter-vercel/pull/24 Newer version of https://github.com/vercel/next.js/pull/89534 - Add a hashes mapping to the NFT file - Forward that information to the adapter via `assetsHashes` for functions Basically zero-cost: ``` commit ad728b15a6431a6372eea3d3d766b328569811b4 (HEAD -> mischnic/server-paths-manifest-2, origin/mischnic/server-paths-manifest-2) pnpm next build 351.22s user, 51.55s system, 811% cpu, 49.654 total pnpm next build 354.52s user, 53.39s system, 837% cpu, 48.706 total pnpm next build 344.02s user, 63.62s system, 749% cpu, 54.368 total pnpm next build 353.74s user, 54.25s system, 833% cpu, 48.970 total commit 04294cb47a6d67adf73c8b6f196ed6a2ddcb2b0e (origin/canary, origin/HEAD) pnpm next build 344.24s user, 53.88s system, 798% cpu, 49.845 total pnpm next build 340.89s user, 52.40s system, 784% cpu, 50.138 total pnpm next build 347.26s user, 51.91s system, 802% cpu, 49.741 total pnpm next build 347.04s user, 52.65s system, 803% cpu, 49.764 total ```

Turbopack: refactor ESM codegen generation (#92777) Move more logic out of the `ModuleReferencesVisitor`, so that we can remove it at some point.

Turbopack: unify ModuleGraph constructors (#93203) We have options and variable length lists. Why do we need a separate function for every combination?

Turbopack: don't generate next-server.js.nft.json with adapters (#93684) Adapters don't read these files. Also added a snapshot test similar to the existing ones to not regress on function size

Turbopack: accept ChunkGroup in entry_chunk_group (#90821) Now all of the chunking context functions accept `ChunkGroup` The names are bad, but `entry_chunk_group` and `ChunkGroup::Entry` have nothing to do with each other: - `entry_chunk_group` means: it's a standalone file where `node path/to/chunk.js` will execute it - `ChunkGroup::Entry` = it's the top-level chunk group For example a `evaluated_chunk_group(ChunkGroup::Entry)` is also fine

Turbopack: move assignment_scopes computation into ImportMap (#92835) I'm moving all of the export-related logic into `EvalContext` (and thus `ImportMap`) so that `VarGraph` is only needed for computing the references, and not the exports. The change in the snapshots is ```diff -*anonymous function 170* (const after eval) = (...) => [file] +*anonymous function 170* = (...) => [file] ``` which is fine, since computing the "is reassigned" data for something that isn't actually a variable was non-sensical anyway.

Fix syntax contexts in server action transform (#91210) ``` let x: Ident = IdentName::new(name, span).into(); ``` should never be done. It uses `SyntaxContext::default()` for the Ident. So from swc's perspective, you are referring to a different variable than you think. When constructing an `Ident`, you should usually always provide a SyntaxContext. I think this would pose a problem in Webpack because it serializes it into a code string again, but for Turbopack these SyntaxContext are important.