Issue Station
Sign In
Tools hereToolbox

nextjs - 💡(How to fix) Fix Turbopack `next build` produces `require("jsdom-<hash>")` in server runtime causing `Cannot find module 'jsdom-<hash>'` in standalone/Docker [1 comments, 2 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#89037•Fetched 2026-04-08 02:03:26
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
elandbelandb
Participants
elandbelandbgithub-actions[bot]github-actions[bot]
Timeline (top)
labeled ×2closed ×1commented ×1issue_type_added ×1

When building a Next.js App Router app with Turbopack (next build --turbopack, or the default bundler in Next.js 16.1), the server output can reference an external dependency using a hashed internal module id (e.g. jsdom-4cccfac9827ebcfe) and then attempts to load it via Node.js require().

In a standalone/Docker runtime, this fails because the actual npm package name is jsdom, not jsdom-<hash>.

Workaround: force webpack for production builds: next build --webpack

1) Install dependency

npm i jsdom

2) Add a server route that imports jsdom

app/api/repro/route.ts

import { NextResponse } from "next/server";
import { JSDOM } from "jsdom";

export async function GET() {
  const dom = new JSDOM("<p>Hello</p>");
  return NextResponse.json({
    ok: true,
    text: dom.window.document.body.textContent,
  });
}

3) Enable standalone output

next.config.ts

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  output: "standalone",
};

export default nextConfig;

4) Build with Turbopack and run standalone output

next build --turbopack   # or `next build` in Next 16.1 where Turbopack is default
node .next/standalone/server.js

Then request:

  • GET /api/repro

Error Message

Error: Failed to load external module jsdom-<hash>: Error: Cannot find module 'jsdom-<hash>' Require stack:

  • .next/server/chunks/[root-of-the-server]__*.js
  • .next/server/chunks/[turbopack]_runtime.js
  • .next/server/app/api/repro/route.js ...

Root Cause

In a standalone/Docker runtime, this fails because the actual npm package name is jsdom, not jsdom-<hash>.

Fix Action

Fix / Workaround

Workaround: force webpack for production builds: next build --webpack

Notes / Workarounds

  • Adding jsdom to serverExternalPackages does not reliably resolve the issue when Turbopack is used, because the output may still reference jsdom-<hash>.
  • Workaround: build with webpack:

Code Example

npm i jsdom

---

import { NextResponse } from "next/server";
import { JSDOM } from "jsdom";

export async function GET() {
  const dom = new JSDOM("<p>Hello</p>");
  return NextResponse.json({
    ok: true,
    text: dom.window.document.body.textContent,
  });
}

---

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  output: "standalone",
};

export default nextConfig;

---

next build --turbopack   # or `next build` in Next 16.1 where Turbopack is default
node .next/standalone/server.js

---

Error: Failed to load external module jsdom-<hash>: Error: Cannot find module 'jsdom-<hash>'
Require stack:
- .next/server/chunks/[root-of-the-server]__*.js
- .next/server/chunks/[turbopack]_runtime.js
- .next/server/app/api/repro/route.js
...

---

require("jsdom-4cccfac9827ebcfe");

---

### Environment

- **Next.js**: 16.1.4 (also observed on 16.1.x)
- **Bundler**: Turbopack (production build)
- **Output mode**: `output: "standalone"`
- **Node.js**: 22.x
- **Runtime**: standalone server (reproduced in Docker/production image runtime)

---

next build --webpack
RAW_BUFFERClick to expand / collapse

Link to the code that reproduces this issue

none

To Reproduce

Summary

When building a Next.js App Router app with Turbopack (next build --turbopack, or the default bundler in Next.js 16.1), the server output can reference an external dependency using a hashed internal module id (e.g. jsdom-4cccfac9827ebcfe) and then attempts to load it via Node.js require().

In a standalone/Docker runtime, this fails because the actual npm package name is jsdom, not jsdom-<hash>.

Workaround: force webpack for production builds: next build --webpack

1) Install dependency

npm i jsdom

2) Add a server route that imports jsdom

app/api/repro/route.ts

import { NextResponse } from "next/server";
import { JSDOM } from "jsdom";

export async function GET() {
  const dom = new JSDOM("<p>Hello</p>");
  return NextResponse.json({
    ok: true,
    text: dom.window.document.body.textContent,
  });
}

3) Enable standalone output

next.config.ts

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  output: "standalone",
};

export default nextConfig;

4) Build with Turbopack and run standalone output

next build --turbopack   # or `next build` in Next 16.1 where Turbopack is default
node .next/standalone/server.js

Then request:

  • GET /api/repro

Current vs. Expected behavior

Actual Behavior

The server crashes at runtime:

Error: Failed to load external module jsdom-<hash>: Error: Cannot find module 'jsdom-<hash>'
Require stack:
- .next/server/chunks/[root-of-the-server]__*.js
- .next/server/chunks/[turbopack]_runtime.js
- .next/server/app/api/repro/route.js
...

In the generated output, the server bundle contains a statement like:

require("jsdom-4cccfac9827ebcfe");

Expected Behavior

  • The runtime should load the real package name: require("jsdom"), or
  • Turbopack should correctly bundle/trace the dependency so it’s available at runtime.

No hashed internal module ids should leak into Node.js require() calls.

Provide environment information

### Environment

- **Next.js**: 16.1.4 (also observed on 16.1.x)
- **Bundler**: Turbopack (production build)
- **Output mode**: `output: "standalone"`
- **Node.js**: 22.x
- **Runtime**: standalone server (reproduced in Docker/production image runtime)

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

Turbopack

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

next build (local)

Additional context

Notes / Workarounds

  • Adding jsdom to serverExternalPackages does not reliably resolve the issue when Turbopack is used, because the output may still reference jsdom-<hash>.
  • Workaround: build with webpack:
next build --webpack

This avoids generating require("jsdom-<hash>") in the server output and runs correctly in standalone/Docker.

extent analysis

TL;DR

The most likely fix is to use the provided workaround and build with Webpack instead of Turbopack by running next build --webpack.

Guidance

  • Identify if you are using Turbopack as the bundler in your Next.js project, especially if you are on Next.js version 16.1 or later where Turbopack is the default.
  • Verify if your project has external dependencies like jsdom that are being referenced with hashed internal module IDs.
  • Apply the workaround by building your project with Webpack using the command next build --webpack to avoid the issue of hashed module IDs leaking into Node.js require() calls.
  • Consider adding external dependencies to serverExternalPackages in your next.config.ts file, although this may not reliably resolve the issue with Turbopack.

Example

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

Notes

This solution assumes that the issue is specifically related to the use of Turbopack as the bundler in Next.js version 16.1 or later. The provided workaround may not be necessary if the project is using an earlier version of Next.js or a different bundler.

Recommendation

Apply the workaround by building with Webpack using next build --webpack, as this avoids the generation of require("jsdom-<hash>") in the server output and allows the project to run correctly in standalone/Docker environments.

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#dependency error#configuration error#environment variable#network issue

Still need to ship something?

×6

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

Back to top recommendations

TRENDING