Issue Station
Sign In
Tools hereToolbox

nextjs - ✅(Solved) Fix Turbopack generates external module references with hashes that don't match installed packages when node_modules structure differs [5 pull requests, 19 comments, 12 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
vercel/next.js#87737•Fetched 2026-04-08 02:06:18
View on GitHub
Comments
19
Participants
12
Timeline
78
Reactions
17
Author
yWilliamLimayWilliamLima
Participants
arolariuarolariuavens19avens19flodevflodevhasankhurshid29hasankhurshid29jitendra-bhandurejitendra-bhandurekarlismelderis-mckinseykarlismelderis-mckinseymischnicmischnicmsheakoskimsheakoskiparalinparalinpascual-cano-allhumanpascual-cano-allhumantaletskitaletskiyWilliamLimayWilliamLima
Timeline (top)
subscribed ×35commented ×19mentioned ×9cross-referenced ×7

Error Message

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

Root Cause

  1. 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

Fix Action

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.

PR fix notes

PR #687: chore: migrate from webpack to turbopack

Description (problem / solution / changelog)

Summary fixes #685

Changed files

  • apps/data-norge/next.config.js (modified, +9/-40)
  • apps/data-norge/project.json (modified, +1/-2)

PR #7064: fix(next): correction de l'erreur empêchant next de fonctionner en v16.1

Description (problem / solution / changelog)

Links to https://github.com/vercel/next.js/issues/87686 Links to https://github.com/vercel/next.js/issues/87737

Changed files

  • .npmrc (modified, +15/-0)
  • packages/code-du-travail-frontend/cypress/integration/light/outils/brut-net.spec.ts (modified, +29/-53)
  • packages/code-du-travail-frontend/next.config.mjs (modified, +6/-2)
  • packages/code-du-travail-frontend/package.json (modified, +2/-4)
  • pnpm-lock.yaml (modified, +322/-304)

PR #88: fix: Webpack ビルドでの Application Insights SDK 初期化エラーを修正

Description (problem / solution / changelog)

Summary

  • applicationinsights は CJS モジュールのため、Webpack の動的 import() では .default が undefined になる問題を修正
  • Turbopack/Webpack 両方に対応する .default ?? module フォールバックパターンを適用
  • defaultClient の TypeScript 型推論が never になる問題を型アサーションで解決

Background

前コミット (5bfffa4) で Turbopack の外部モジュールハッシュバグ (vercel/next.js#87737) を回避するため next build --webpack に変更したところ、instrumentation.ts での appInsights.default.setup() 呼び出しが undefined エラーで失敗するようになった。

Test plan

  • Webpack ビルド (next build --webpack) が成功すること
  • デプロイ後、ログストリームで [AppInsights] SDK initialized successfully が表示されること
  • [AppInsights] Failed to initialize SDK エラーが出ないこと

🤖 Generated with Claude Code

Changed files

  • apps/web/instrumentation.ts (modified, +11/-6)

PR #2193: Update append-hash-for-server-only-packages.mts

Description (problem / solution / changelog)

https://github.com/vercel/next.js/issues/87737

Changed files

  • agents-manage-ui/scripts/append-hash-for-server-only-packages.mts (modified, +22/-5)

PR #987: Fix: Pin Next.js to 16.0.10 to prevent Turbopack hashed module bug

Description (problem / solution / changelog)

Problem

Next.js 16.1.0+ introduced a regression in Turbopack where external module references are generated with content-based hashes (e.g., better-sqlite3-90e2652d1716b047 instead of better-sqlite3). These hashed module names don't exist in node_modules, causing runtime failures in:

  • Electron standalone builds
  • Standalone output deployed to different environments
  • CI/CD pipelines where build and runtime node_modules structures differ

The version was previously specified as "^16.0.10", allowing npm to resolve to 16.2.x and triggering the bug.

Solution

Pinned Next.js and eslint-config-next to exact version 16.0.10 (removed ^ prefix):

PackageBeforeAfter
next"^16.0.10""16.0.10"
eslint-config-next"^16.0.10""16.0.10"

The lockfile was regenerated, downgrading all @next/* packages from 16.2.2 back to 16.0.10.

Also removed a duplicate Material Symbols @import from globals.css — the font is already loaded via <link> in layout.tsx.

References

Changed files

  • package-lock.json (modified, +51/-212)
  • package.json (modified, +2/-2)
  • src/app/globals.css (modified, +0/-1)

Code Example

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

---

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

---

**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

---

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

export default nextConfig;

---

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

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.

extent analysis

TL;DR

Using the --webpack flag in the build script resolves the issue, but to keep using Turbopack, consider adjusting the node_modules structure consistency across environments.

Guidance

  • Verify that the issue is indeed caused by the difference in node_modules structure between build and runtime environments by checking the hashes generated by Turbopack.
  • Consider using a consistent node_modules structure across environments, potentially by using a different package manager or adjusting the CI/CD pipeline to preserve the node_modules structure.
  • If using pnpm, explore options to disable symlink/hoisting behavior to maintain a consistent node_modules structure.
  • Test the application with the --webpack flag to confirm that it resolves the issue, and then explore alternatives to maintain Turbopack usage.

Example

No code snippet is provided as the issue is more related to the build and deployment process rather than a specific code block.

Notes

The provided workaround using the --webpack flag defeats the purpose of using Turbopack, so exploring alternatives to maintain a consistent node_modules structure is crucial. The issue seems to be specific to the combination of Next.js 16, Turbopack, and pnpm.

Recommendation

Apply workaround: Use the --webpack flag in the build script as a temporary solution until a more permanent fix is found that allows the use of Turbopack without the hashing issue. This is because the --webpack flag has been confirmed to resolve the issue, even though it's not the ideal long-term solution.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#installation#API versioning#request timeout

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING