Unused (dev) dependencies cause standalone node_modules pollution

[ardokirsipuu]

Link to the code that reproduces this issue

https://github.com/ardokirsipuu/nextjs-standalone-node-modules

To Reproduce

1. clone the repo
2. run yarn
3. run yarn build
4. check the contents of .next\standalone\node_modules to find irrelevant (not needed for prod runtime) dependencies

Current vs. Expected behavior

Current behavior

When new (dev) dependencies are added, that are not used in the code, then the .next\standalone\node_modules folder is being polluted with additional files that are not needed for production runtime (e.g. esbuild, @esbuild/*, @rspack/* etc). See the screenshot below to see a diff of the file tree between before (HEAD~1) vs after (@nx/react is added):

Most of the tree on the left side shows new stuff being added (with a little twist of @swc/helpers actually being moved from the root to be under next/node_modules/@swc/helpers 👀).

Expected behavior

No unused files are added to .next\standalone\node_modules for unused dependencies.

Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Pro
  Available memory (MB): 65277
  Available CPU cores: 24
Binaries:
  Node: 22.14.0
  npm: 10.9.2
  Yarn: 4.8.1
  pnpm: N/A
Relevant Packages:
  next: 15.3.0-canary.26
  eslint-config-next: N/A
  react: 19.1.0
  react-dom: 19.1.0
  typescript: 5.8.2
Next.js Config:
  output: standalone

Which area(s) are affected? (Select all that apply)

Output

Which stage(s) are affected? (Select all that apply)

next build (local)

Additional context

Having next.config.ts with something like

  outputFileTracingExcludes: {
    "./**/*": [
      "node_modules/esbuild",
      "node_modules/@esbuild",
    ],
  },

would take care of these two excessive dependencies, but handling all those tens of dependencies manually like this would not be very feasible and would defeat the purpose of having the file tracing feature.

_NEXT-4533

[dansmachina]

This one is quite annoying and also impacting opennext: opennextjs/opennextjs-aws#242. The outputFileTracingExcludes helps a bit, but definitely not a very elegant solution...

[rtrembecky]

Comment for #77656

Confirming this is still happening in Next.js 16.2.3 with Turbopack as the default bundler — but I think I've found a concrete reason outputFileTracingExcludes in particular isn't working as a workaround in Turbopack mode.

Repro on our side

Monorepo (Nx + Bun workspaces) with apps/next-pwa and apps/mobile-expo. Web build's standalone output picks up ~470 packages from the mobile app's deps:

node_modules/@react-native-firebase/  (135 MB)
node_modules/@expo/                    (113 MB)
node_modules/eslint-config-next/       (112 MB)
node_modules/@config-plugins/          (70 MB)
node_modules/@react-native-google-signin/ (67 MB)
...

None of these are imported by web code. They land in _app.js.nft.json via Pages Router's shared trace and get copied to .next/standalone/ via copyTracedFiles.

outputFileTracingExcludes configured to remove them has no effect. After build, _app.js.nft.json still contains 19,699 @expo/ entries despite '../../node_modules/@expo/**' being in our exclude list.

Root cause for the Turbopack path specifically

In node_modules/next/dist/build/index.js:

// #region NFT
if (bundler !== _bundler.Bundler.Turbopack && !isGenerateMode && !buildTracesPromise) {
    buildTracesPromise = nextBuildSpan.traceChild('collect-build-traces').traceAsyncFn(()=>{
        const { collectBuildTraces } = require('./collect-build-traces');
        return collectBuildTraces({ ... });
    });
}

collectBuildTraces is only invoked when bundler !== Turbopack. The entire collect-build-traces.js module — which contains the apply-include-excludes loop that processes outputFileTracingIncludes and outputFileTracingExcludes and rewrites per-route nft.json files — is bypassed in Turbopack mode.

I verified this by patching the function body to write to a sentinel file on entry: with Turbopack it never writes, with Webpack (bunx next build --webpack) it does.

Turbopack's native NFT (Rust) reads outputFileTracingIncludes from config and applies it to the per-route nft.json files (we observed _app.js.nft.json grow from ~700KB → 47MB after adding closure globs as includes). But outputFileTracingExcludes has no observable effect on those files.

So the documented Node.js exclude logic is dead code for Turbopack users, and the Rust replacement is incomplete — at least for the per-route nft.json path that copyTracedFiles reads to populate .next/standalone/.

What works as a workaround

We had to keep a 250-line bash post-process step that recursively rm -rfs the unwanted packages from .next/standalone/next-pwa-app/node_modules/ after the build. This is identical in spirit to what OpenNext does (referenced in the comment above) and what every monorepo with this issue ends up doing.

Suggested fix scope

Either:

1. Make Turbopack's native NFT honor outputFileTracingExcludes for per-route nft.json (matches the Webpack path's behavior).
2. Wire the Node-side apply-include-excludes loop in collect-build-traces.js to run as a post-pass even in Turbopack mode.

Option (2) is probably trivial — just remove the Turbopack guard or replace it with a Turbopack-aware path that calls only the post-processing portion.

Happy to test a fix. The exact gate that needs revisiting is the one cited above (bundler !== Bundler.Turbopack).

---

Repro repo: monorepo with mobile-only deps in node_modules/ and a web app's standalone build. Same symptom in https://github.com/ardokirsipuu/nextjs-standalone-node-modules (the OP's repro).

Environment:

• Next.js 16.2.3 (also reproduces on 16.1.x)
• Turbopack (default), bundled @vercel/nft 0.27.1
• Bun monorepo, all deps hoisted to root node_modules/
• macOS arm64, Node 22