-
Notifications
You must be signed in to change notification settings - Fork 182
fix: detect Turbopack builds and set TURBOPACK env accordingly #1056
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
fix: detect Turbopack builds and set TURBOPACK env accordingly #1056
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'
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be great to add an e2e test got that (i.e. identify something that is failing without this patch)
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.