next.js
next.js copied to clipboard
Published
2 weeks ago
•
vercel
vercel
Regression in Next.js 15.4.0-canary.105 causes Turbo production builds to crash in certain scenarios
Link to the code that reproduces this issue
https://github.com/user-attachments/files/21824657/zod-repro.zip
To Reproduce
npm i
npm run build
Current vs. Expected behavior
Using Turbopack:
wojciech.maj@MacBook-Pro zod-repro % npm i
added 61 packages, and audited 62 packages in 4s
27 packages are looking for funding
run `npm fund` for details
found 0 vulnerabilities
wojciech.maj@MacBook-Pro zod-repro % node --run build
▲ Next.js 15.4.6 (Turbopack)
- Experiments (use with caution):
⨯ turbopackMinify
Creating an optimized production build ...
✓ Finished writing to disk in 85ms
✓ Compiled successfully in 905ms
✓ Linting and checking validity of types
Collecting page data ..ReferenceError: Cannot access 'ZodEnum' before initialization
at Module._enum (.next/server/chunks/[root-of-the-server]__35f2e931._.js:25340:5)
at Module.<anonymous> (.next/server/chunks/[root-of-the-server]__35f2e931._.js:25830:67)
at instantiateModule (.next/server/chunks/[turbopack]_runtime.js:630:23)
at getOrInstantiateModuleFromParent (.next/server/chunks/[turbopack]_runtime.js:681:12)
at esmImport (.next/server/chunks/[turbopack]_runtime.js:162:20)
at Module.<anonymous> (.next/server/chunks/[root-of-the-server]__35f2e931._.js:18701:68)
at instantiateModule (.next/server/chunks/[turbopack]_runtime.js:630:23)
at getOrInstantiateModuleFromParent (.next/server/chunks/[turbopack]_runtime.js:681:12)
at esmImport (.next/server/chunks/[turbopack]_runtime.js:162:20)
at Module.<anonymous> (.next/server/chunks/[root-of-the-server]__35f2e931._.js:24427:68)
⚠ Support for Turbopack builds is experimental. We don't recommend deploying mission-critical applications to production.
- Turbopack currently always builds production source maps for the browser. This will include project source code if deployed to production.
- It is expected that your bundle size might be different from `next build` with webpack. This will be improved as we work towards stability.
- This build is without disk caching; subsequent builds will become faster when disk caching becomes available.
- When comparing output to webpack builds, make sure to first clear the Next.js cache by deleting the `.next` directory.
Provide feedback for Turbopack builds at https://github.com/vercel/next.js/discussions/77721
> Build error occurred
[Error: Failed to collect page data for /api/foo] { type: 'Error' }
Using Webpack:
wojciech.maj@MacBook-Pro zod-repro % node --run build
▲ Next.js 15.4.6
- Experiments (use with caution):
⨯ turbopackMinify
Creating an optimized production build ...
✓ Compiled successfully in 0ms
✓ Linting and checking validity of types
✓ Collecting page data
✓ Generating static pages (6/6)
✓ Collecting build traces
✓ Finalizing page optimization
Route (app) Size First Load JS
┌ ○ / 133 B 99.7 kB
├ ○ /_not-found 989 B 101 kB
├ ƒ /api/bar 133 B 99.7 kB
└ ƒ /api/foo 133 B 99.7 kB
+ First Load JS shared by all 99.6 kB
├ chunks/4bd1b696-cf72ae8a39fa05aa.js 54.1 kB
├ chunks/964-7a34cadcb7695cec.js 43.5 kB
└ other shared chunks (total) 1.88 kB
○ (Static) prerendered as static content
ƒ (Dynamic) server-rendered on demand
Provide environment information
Operating System:
Platform: darwin
Arch: arm64
Version: Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:29 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6000
Available memory (MB): 65536
Available CPU cores: 10
Binaries:
Node: 24.3.0
npm: 11.5.1
Yarn: 4.9.1
pnpm: 10.12.1
Relevant Packages:
next: 15.4.6 // Latest available version is detected (15.4.6).
eslint-config-next: N/A
react: 19.1.1
react-dom: 19.1.1
typescript: 5.9.2
Next.js Config:
output: N/A
Which area(s) are affected? (Select all that apply)
Turbopack
Which stage(s) are affected? (Select all that apply)
next build (local)
Additional context
- Probably happens across the entire Next.js v15.4 stable line:
- doesn't work on 15.4.0-canary.105, 15.4.0-canary.130, 15.4.1 (15.4.0 was skipped) and 15.4.6.
- works on 15.4.0-canary.104 and below.
- Probably happens across the entire Zod v4 line:
- doesn't work on 4.0.2 and 4.0.17.
That's a great reproduction. It's indeed a Turbopack bug.
You can use nextConfig.experimental.turbopackScopeHoisting = false to workaround it by disabling the faulty optimization until this is fixed https://github.com/vercel/next.js/pull/82827
We have a similar issue, related to zod and https://github.com/vercel/next.js/issues/83352:
Error: Failed to load chunk server/chunks/ssr/_a7bcfa8a._.js from runtime for chunk server/app/_not-found/page.js
at loadRuntimeChunkPath (../../dist/apps/my-frontend/.next/server/chunks/ssr/[turbopack]_runtime.js:636:15)
at loadRuntimeChunk (../../dist/apps/my-frontend/.next/server/chunks/ssr/[turbopack]_runtime.js:605:9)
at Object.c (../../dist/apps/my-frontend/.next/server/chunks/ssr/[turbopack]_runtime.js:766:25)
at Object.<anonymous> (../../dist/apps/my-frontend/.next/server/app/_not-found/page.js:10:3) {
[cause]: SyntaxError: Identifier 'r' has already been declared
at <unknown> (../../dist/apps/my-frontend/.next/server/chunks/ssr/_a7bcfa8a._.js:20)
}
Error: Failed to load chunk server/chunks/ssr/_a7bcfa8a._.js from runtime for chunk server/app/page.js
at loadRuntimeChunkPath (../../dist/apps/my-frontend/.next/server/chunks/ssr/[turbopack]_runtime.js:636:15)
at loadRuntimeChunk (../../dist/apps/my-frontend/.next/server/chunks/ssr/[turbopack]_runtime.js:605:9)
at Object.c (../../dist/apps/my-frontend/.next/server/chunks/ssr/[turbopack]_runtime.js:766:25)
at Object.<anonymous> (../../dist/apps/my-frontend/.next/server/app/page.js:11:3) {
[cause]: SyntaxError: Identifier 'r' has already been declared
at <unknown> (../../dist/apps/my-frontend/.next/server/chunks/ssr/_a7bcfa8a._.js:20)
}
> Build error occurred
Error: Failed to collect page data for /_not-found
at ignore-listed frames {
type: 'Error'
}
Looked at the file, and the line contains zod code.
Worked around by adding zod to serverExternalPackages in next.config.js, but feels scary.
We have 14 apps in an NX monorepo, using output: "standalone", all very similar, and only one was failing.
