Link to the code that reproduces this issue

https://github.com/kyeb/turbopack-symlink-repro

To Reproduce

1. Clone the repo: git clone https://github.com/kyeb/turbopack-symlink-repro
2. Build the Docker image: docker build -t repro .
3. Run it: docker run -p 3000:3000 repro
4. Request the page: curl http://localhost:3000/
5. Observe HTTP 500 with Error: Cannot find module 'pino-28069d5257187539'

The Dockerfile simulates a standard monorepo multi-stage Docker build: the Next.js app is built at /workspace/app/ with node_modules hoisted to /workspace/, then .next and node_modules are copied to /app/ in the runtime stage (one level shallower).

Current vs. Expected behavior

Current: next build with Turbopack creates .next/node_modules/pino-28069d5257187539 as a relative symlink (../../../node_modules/pino) based on the build-time directory depth. When .next is copied to a shallower path in the runtime stage of a multi-stage Docker build, the symlink overshoots the filesystem root and breaks:

Builder:  /workspace/app/.next/node_modules/pino-<hash> -> ../../../node_modules/pino  ✅ resolves to /workspace/node_modules/pino
Runtime:  /app/.next/node_modules/pino-<hash> -> ../../../node_modules/pino            ❌ resolves to /../node_modules/pino

There is also a secondary issue: the server runtime emits require('pino-28069d5257187539') — a hashed module name that Node.js cannot resolve through standard module resolution, even if the symlink target were valid. This requires NODE_PATH=.next/node_modules as a workaround.

Expected: Symlinks in .next/node_modules/ should survive being copied to a different directory depth (e.g., use symlinks relative to .next itself, or copy the actual files). The hashed module names should also be resolvable without NODE_PATH.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.2.0
  Available memory (MB): 49152
  Available CPU cores: 12
Binaries:
  Node: 22.14.0
  npm: 11.4.1
  Yarn: N/A
  pnpm: 10.28.2
Relevant Packages:
  next: 16.1.6 // Latest available version is detected (16.1.6).
  eslint-config-next: N/A
  react: 19.2.4
  react-dom: 19.2.4
  typescript: 5.9.3
Next.js Config:
  output: N/A

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

Turbopack, Module Resolution, Output

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

next build (local), next start (local)

Additional context

This affects any monorepo using serverExternalPackages with a multi-stage Docker build where .next is copied to a different directory depth than where it was built. This is a common pattern with pnpm workspaces where node_modules is hoisted to the workspace root.

Workaround: Rewrite symlinks in the runtime Dockerfile stage and set NODE_PATH:

RUN find .next/node_modules -type l | while read link; do       target=$(readlink "$link" | sed 's|^\.\./||');       ln -sf "$target" "$link";     done
ENV NODE_PATH=/app/.next/node_modules

The repro repository is 8 files — a minimal Next.js app with pino in serverExternalPackages and a multi-stage Dockerfile that demonstrates the breakage. See the README for full details and a diagram.