Fix "type: module" in project dir when using standalone or adapters#93612
Merged
Conversation
Contributor
Tests PassedCommit: fc75186 |
Member
|
Turbopack lists it in the NFT files, not sure about Webpack though |
mischnic
reviewed
May 8, 2026
Comment on lines
+1860
to
+1866
| // Standalone already picks this up via `next-server.js.nft.json` | ||
| // (nft traces it as `./package.json`), but per-page nft files do | ||
| // not include it. The adapter codepath (`handleBuildComplete`) | ||
| // builds each page's `assets` from `requiredServerFiles` plus | ||
| // the per-page trace, so without listing it here the boundary | ||
| // is missing from adapter outputs and Node walks up to the | ||
| // user's `"type": "module"` package.json at runtime. |
mischnic
approved these changes
May 8, 2026
Contributor
Stats from current PR✅ No significant changes detected📊 All Metrics📖 Metrics GlossaryDev Server Metrics:
Build Metrics:
Change Thresholds:
⚡ Dev Server
📦 Dev Server (Webpack) (Legacy)📦 Dev Server (Webpack)
⚡ Production Builds
📦 Production Builds (Webpack) (Legacy)📦 Production Builds (Webpack)
📦 Bundle SizesBundle Sizes⚡ TurbopackClient Main Bundles
Server Middleware
Build DetailsBuild Manifests
📦 WebpackClient Main Bundles
Polyfills
Pages
Server Edge SSR
Middleware
Build DetailsBuild Manifests
Build Cache
🔄 Shared (bundler-independent)Runtimes
📎 Tarball URLCommit: fc75186 |
devin-ai-integration Bot
added a commit
to hexclave/hexclave
that referenced
this pull request
May 20, 2026
Workaround for vercel/next.js#91661 — Next.js 16.2 omits .next/package.json from the required-server-files manifest, so Vercel's serverless functions don't get the CJS boundary marker. Without it, Node.js resolves the project's "type": "module" and treats the compiled server bundles as ESM, breaking require() calls at runtime. This adds a postbuild script that patches the manifest to include the file, matching the upstream fix in vercel/next.js#93612 (only in canary as of 16.2.6). The previous approach of removing "type": "module" broke the codegen step which uses tsx/esbuild and needs ESM for top-level await support. Co-Authored-By: Konstantin Wohlwend <n2d4xc@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What?
Add
.next/package.json(the distDir commonjs boundary marker) to therequired-server-files.jsonmanifest.Why?
next buildwrites.next/package.jsonwith{"type": "commonjs"}so that everything in.next/**is loaded as CJS even when the user's projectpackage.jsonhas"type": "module". Without that file, Node walks up to the projectpackage.jsonwhen loading.next/server/**/*.jsand tries to evaluate the compiled server bundles as ESM, which fails at runtime.This file is necessary on disk in every server deployment artifact (the standalone bundle, every adapter Node function), but it was not declared in
required-server-files.json. As a result, adapters consumingrequiredServerFiles.filesdid not include the boundary file..next/package.jsonis conceptually a required server file: any deployment that wants to run.next/server/**/*.jscorrectly under a"type": "module"project must ship it. Declaring it in the manifest is the right place to express that contract once for every consumer.This error case would only happen if the project package.json gets included into the Node.js functions. For example when file tracing analysis (node-file-trace) decides it needs to include it (i.e. glob patterns or such).
How?
Add
'package.json'to therequiredServerFilesManifest.filesarray inpackages/next/src/build/index.ts. Every entry in that array is joined withconfig.distDir, so this resolves to.next/package.json.Both existing consumers pick it up automatically with no further changes:
packages/next/src/build/adapter/build-complete.tsiteratesrequiredServerFilesintosharedNodeAssets, which is merged into every Node function'soutput.assetsregardless of bundler. The Vercel adapter (and any other adapter) gets the file for free.copyTracedFilesinpackages/next/src/build/utils.tsiteratesrequiredServerFiles.filesand copies each entry into.next/standalone/<relative>, so the standalone output now contains.next/standalone/.next/package.json.Tests
test/production/required-server-files-package-boundary/— a focused, non-standalone test that builds a"type": "module"app and asserts:.next/package.jsonis{"type": "commonjs"}on disk.next/required-server-files.jsonlists.next/package.jsontest/production/standalone-mode/type-module/— extended with apages/dynamic.jsthat usesgetServerSideProps. The test now:.next/standalone/.next/package.jsonexists with{"type": "commonjs"}server.jsand fetches/dynamic, which forces Node to actually evaluate.next/server/pages/dynamic.jsat runtime — the exact code path the boundary file makes work