Skip to content

fix: resolve ESM-only serverExternalPackages in Node.js middleware - #3561

Open
adamhake wants to merge 2 commits into
opennextjs:mainfrom
adamhake:fix/node-middleware-esm-externals
Open

fix: resolve ESM-only serverExternalPackages in Node.js middleware#3561
adamhake wants to merge 2 commits into
opennextjs:mainfrom
adamhake:fix/node-middleware-esm-externals

Conversation

@adamhake

Copy link
Copy Markdown

Description

Node.js middleware (proxy.ts / runtime: 'nodejs') is served as a Deno edge function. CJS serverExternalPackages work through the virtual require() registry, but ESM-only packages are loaded with import() of a bare specifier (hashed under Turbopack). Deno's eszip cannot evaluate that dynamic import, so the handler never becomes a function and matched routes return HTTP 500 nextHandler is not a function.

This change:

  1. Materializes ESM-only externals from the middleware NFT graph as real files
  2. Statically imports them so they are in the eszip
  3. Maps both the package name (webpack) and the Turbopack hashed specifier onto that namespace
  4. Patches Turbopack's externalImport to use the table instead of import(id)
  5. Emits import_map on the internal edge-functions manifest (supported by edge-bundler deploy_config)

Documentation

No doc change in this PR. Netlify's Node.js middleware limitations currently list only C++ addons and filesystem; ESM externals should be called out if maintainers want that.

Tests

Added fixture middleware-node-esm-externals (nanoid in serverExternalPackages) and an integration test that asserts:

  • an import_map.json is generated
  • /protected returns 200 with x-request-id from nanoid()
npm run build
node tests/prepare.mjs middleware-node-esm-externals
npx vitest run --project integration tests/integration/middleware.test.ts -t "ESM-only"

Minimal standalone repro: https://github.com/adamhake/netlify-node-middleware-esm-repro

Relevant links

Fixes #3560

Node.js middleware runs as a Deno edge function. CJS externals work via the
virtual require() registry, but ESM-only packages are loaded with import()
of a bare specifier (hashed under Turbopack). Deno's eszip cannot evaluate
that dynamic import, which surfaced as HTTP 500 "nextHandler is not a function".

Materialize those packages as real ESM files, statically import them, map both
the package name and the Turbopack hashed specifier onto the namespace, and
patch Turbopack's externalImport to use that table. Also emit an import_map
on the internal edge-functions manifest so the bundler can include the files.

Fixes opennextjs#3560
@adamhake
adamhake requested a review from a team as a code owner August 21, 2026 00:59
Satisfy unicorn/better-regex, no-plusplus, consistent-function-scoping,
and explicit-length-check on the Node middleware ESM path.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Node.js middleware 500s with ESM-only serverExternalPackages (nextHandler is not a function)

1 participant