Turbopack generates external module references with hashes that don't match installed packages when node_modules structure differs

Link to the code that reproduces this issue

https://github.com/Aluisio/test-styled-components

To Reproduce

1. Create a Next.js 16.1.1+ project with OpenTelemetry instrumentation
2. Add instrumentation.ts file that imports @opentelemetry/auto-instrumentations-node
3. Build the project in a CI/CD environment (e.g., GitHub Actions) using pnpm install --frozen-lockfile followed by next build
4. Create a tar.gz archive excluding node_modules directory
5. Extract the tar.gz in a different environment
6. Run pnpm install to install dependencies
7. Run next start to start the production server

Current vs. Expected behavior

Expected Behavior

The application should start successfully, loading the instrumentation hook without errors.

Current Behavior

The application fails to start with the following error:

Error: An error occurred while loading instrumentation hook: Failed to load external module require-in-the-middle-a99415fa67232f7f: Error: Cannot find module 'require-in-the-middle-a99415fa67232f7f'
Require stack:
- /path/to/.next/server/chunks/[root-of-the-server]__39a9a9e1._.js
- /path/to/.next/server/chunks/[turbopack]_runtime.js
- /path/to/.next/server/instrumentation.js

The Turbopack bundler generates external module references with hashes (e.g., require-in-the-middle-a99415fa67232f7f) based on the node_modules structure during the build. When dependencies are reinstalled in a different environment, the node_modules structure may differ (especially with pnpm's symlink/hoisting behavior), causing the hash to not match the actual installed package.

Workaround

Using --webpack flag in the build script resolves the issue:

{
  "scripts": {
    "build": "next build --webpack"
  }
}

However, this defeats the purpose of using Turbopack as the default bundler in Next.js 16.

Provide environment information

**Operating System:**

- Platform: linux
- Arch: x64
- Version: Ubuntu (GitHub Actions runner)

**Binaries:**

- Node: 24.11.1
- pnpm: 10.25.0

**Relevant Packages:**

- next: 16.1.1
- react: 19.2.3
- react-dom: 19.2.3
- @opentelemetry/auto-instrumentations-node: 0.67.3
- require-in-the-middle: 8.0.1
- import-in-the-middle: 2.0.1

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

Output

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

Other (Deployed)

Additional context

Next.js Config:

/** @type {import('next').NextConfig} */
const nextConfig = {};

export default nextConfig;

Note: The issue occurs even with serverExternalPackages configured:

const nextConfig = {
  serverExternalPackages: [
    "require-in-the-middle",
    "import-in-the-middle",
    "@opentelemetry/auto-instrumentations-node",
    // ... other OpenTelemetry packages
  ],
};

Why this happens

1. Local development works: When building and running locally, the same node_modules structure is used for both build and runtime, so the hashes match.

2. CI/CD fails: The build is created with node_modules structure A (from CI environment), generating hashes based on that structure. When the tar.gz is extracted and dependencies are reinstalled locally, the node_modules structure may be different (structure B), causing hash mismatches.

3. Root cause: Turbopack generates external module references with content-based hashes that depend on the node_modules directory structure. This is problematic when:

   • Using pnpm (which uses symlinks and hoisting)
   • Building in one environment and running in another
   • Reinstalling dependencies after extracting a build artifact

Impact

This issue affects:

• Projects using OpenTelemetry instrumentation (common in production applications)
• CI/CD pipelines that build artifacts without node_modules and reinstall dependencies later
• Projects using pnpm as package manager
• Any project that needs to build in one environment and run in another

Testing

Tested against:

• Next.js 16.1.1 (current)
• Next.js 16.0.0 (same issue)
• Next.js 15.x with Webpack (works correctly)

The issue appears to be introduced when Turbopack became the default bundler for production builds in Next.js 16.

Start with the linked test-styled-components reproduction and follow the CI flow: pnpm install --frozen-lockfile, next build, archive without node_modules, reinstall, and next start. Inspect the generated .next/server/instrumentation.js and server chunks for the hashed external reference, comparing Turbopack with the documented --webpack workaround. Done means the extracted artifact starts successfully after dependencies are reinstalled.