Skip to content

fix(turbopack): use NODE_ENV for SWC plugins#92650

Closed
foxtrotglobal wants to merge 1 commit into
vercel:canaryfrom
foxtrotglobal:fix/issue-92547
Closed

fix(turbopack): use NODE_ENV for SWC plugins#92650
foxtrotglobal wants to merge 1 commit into
vercel:canaryfrom
foxtrotglobal:fix/issue-92547

Conversation

@foxtrotglobal
Copy link
Copy Markdown

Replaces hardcoded "development" with process.env.NODE_ENV or fallback.

Fixes #92547

@nextjs-bot nextjs-bot added the Turbopack Related to Turbopack with Next.js. label Apr 11, 2026
@nextjs-bot
Copy link
Copy Markdown
Contributor

Allow CI Workflow Run

  • approve CI run for commit: 80ec6d9

Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer

mischnic added a commit that referenced this pull request Apr 15, 2026
### What?

Closes #92650
Closes #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 #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 -->
@github-actions github-actions Bot locked as resolved and limited conversation to collaborators Apr 30, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

locked Turbopack Related to Turbopack with Next.js.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Turbopack passes "development" to SWC plugins during next build

2 participants