Describe the bug
Building on Windows with @opennextjs/cloudflare@1.20.1 and Next.js 16.2.10 (Turbopack) produces a worker where every route returns 500 with:
⨯ TypeError: components.ComponentMod.handler is not a function
(Symptom looks like #1258 / the 1.19 boot issue, but this one is Windows-specific and still present on 1.20.1.)
Root cause
In dist/cli/build/patches/plugins/turbopack.js, the traced file paths use Windows backslashes (...\.next\server\chunks\...), but the filters compare against forward-slash literals:
getInlinableChunks: file.includes(".next/server/chunks/") → matches nothing on Windows
discoverBareExternalImports: f.includes(".next/server/chunks/") → same
- the
case path rewrite chunk.replace(/.*\/\.next\//, "") also assumes /
As a result the generated requireChunk() switch is empty:
function requireChunk(chunkPath) {
switch(chunkPath) {
default:
throw new Error(`Not found ${chunkPath}`);
}
}
so loading any page module throws ChunkLoadError: Failed to load chunk server/chunks/ssr/..., which surfaces as the ComponentMod.handler TypeError at request time.
Workaround / suggested fix
Normalizing the paths at the top of patchTurbopackRuntime.patchCode fixes it (verified — the switch then contains all 58 chunks and the deployed worker serves all routes):
patchCode: async ({ code, tracedFiles, filePath }) => {
tracedFiles = tracedFiles.map((f) => f.replace(/\/g, "/"));
filePath = filePath.replace(/\/g, "/");
// ...unchanged
A more general fix would be to normalize separators wherever tracedFiles are filtered/rewritten in this plugin.
Steps to reproduce
- On Windows,
create-next-app (App Router, Next 16.x, default Turbopack build) with any page + route handler
opennextjs-cloudflare build && opennextjs-cloudflare deploy
- Open any route → 500;
wrangler tail shows the TypeError above
- Inspect
.open-next/server-functions/default/.next/server/chunks/ssr/[turbopack]_runtime.js → requireChunk switch has zero cases
Environment
- OS: Windows 11 (build run in PowerShell/Git Bash, not WSL)
- @opennextjs/cloudflare: 1.20.1 (@opennextjs/aws 4.0.2)
- Next.js: 16.2.10 (Turbopack build)
- wrangler: 4.97.0, Node.js: 24.15.0
Describe the bug
Building on Windows with
@opennextjs/cloudflare@1.20.1and Next.js 16.2.10 (Turbopack) produces a worker where every route returns 500 with:(Symptom looks like #1258 / the 1.19 boot issue, but this one is Windows-specific and still present on 1.20.1.)
Root cause
In
dist/cli/build/patches/plugins/turbopack.js, the traced file paths use Windows backslashes (...\.next\server\chunks\...), but the filters compare against forward-slash literals:getInlinableChunks:file.includes(".next/server/chunks/")→ matches nothing on WindowsdiscoverBareExternalImports:f.includes(".next/server/chunks/")→ samecasepath rewritechunk.replace(/.*\/\.next\//, "")also assumes/As a result the generated
requireChunk()switch is empty:so loading any page module throws
ChunkLoadError: Failed to load chunk server/chunks/ssr/..., which surfaces as theComponentMod.handlerTypeError at request time.Workaround / suggested fix
Normalizing the paths at the top of
patchTurbopackRuntime.patchCodefixes it (verified — the switch then contains all 58 chunks and the deployed worker serves all routes):A more general fix would be to normalize separators wherever tracedFiles are filtered/rewritten in this plugin.
Steps to reproduce
create-next-app(App Router, Next 16.x, default Turbopack build) with any page + route handleropennextjs-cloudflare build && opennextjs-cloudflare deploywrangler tailshows the TypeError above.open-next/server-functions/default/.next/server/chunks/ssr/[turbopack]_runtime.js→requireChunkswitch has zero casesEnvironment