fix: detect Turbopack builds and set TURBOPACK env accordingly#1056
fix: detect Turbopack builds and set TURBOPACK env accordingly#1056relsunkaev wants to merge 1 commit intoopennextjs:mainfrom
Conversation
|
commit: |
When building with Turbopack (default in Next.js 16), the standalone output only includes *-turbo.runtime.prod.js files, not the webpack variants. The previous behavior of unconditionally setting TURBOPACK=false caused runtime errors because module.compiled.js would try to load non-existent runtime files. This change: - Detects Turbopack builds by checking if only turbo runtime files exist in the traced files - Sets TURBOPACK=true for Turbopack builds so the correct runtime is loaded - Keeps TURBOPACK=false for Webpack builds (existing behavior) Fixes runtime error: Cannot find module 'next/dist/compiled/next-server/pages.runtime.prod.js'
relsunkaev
force-pushed
the
fix/turbopack-runtime-detection
branch
from
8e8a97e to
91dbdd3
Compare
|
@vicb Not sure what's going on with the workflow not passing but this fixed our Next 16 Turbopack deploys. Currently running this as a pnpm patch. |
| '${value}' | ||
| `; | ||
|
|
||
| function isTurbopackBuild(tracedFiles: string[]): boolean { |
There was a problem hiding this comment.
it would be nice to extract this into an helper
- so that it can be re-used across different files
- and ultimately moved to Next.js
We use this check in the cloudflare adapter
| patchCode: createPatchCode(envVarRuleCreator("NODE_ENV", '"production"')), | ||
| }, | ||
| // This patch will set `TURBOPACK` env to false to avoid loading turbopack related deps at runtime | ||
| // Turbopack builds only include *-turbo.runtime.prod.js files, so we detect and set accordingly |
There was a problem hiding this comment.
nit: I don't think we really care about how we detect a turbopack build in this comment?
Maybe revert to the inlined version of the code and remove the comment altogether when you add the helper?
vicb
left a comment
vicb
left a comment
There was a problem hiding this comment.
It would be great to add an e2e test got that (i.e. identify something that is failing without this patch)
|
This was addressed via #1087 |
2 participants
Summary
Fixes runtime errors when deploying Next.js 16 apps built with Turbopack to AWS Lambda.
Problem
When building with Turbopack (default in Next.js 16), the standalone output only includes
*-turbo.runtime.prod.jsfiles (e.g.,pages-turbo.runtime.prod.js), not the webpack variants (pages.runtime.prod.js).The previous behavior unconditionally set
TURBOPACK=falseinmodule.compiled.js, which caused it to try loading non-existent runtime files at runtime:Solution
This PR detects whether the build was done with Turbopack by checking the traced files:
*-turbo.runtime.prod.jsfiles exist → Turbopack build → setTURBOPACK=trueTURBOPACK=falseTesting
Tested with a Next.js 16.0.7 app built with Turbopack and deployed to AWS Lambda via SST. Before the fix: 502 errors. After the fix: 200 OK.