build(deps-dev): bump @opennextjs/cloudflare from 1.19.11 to 1.20.3

[dependabot]

Bumps @opennextjs/cloudflare from 1.19.11 to 1.20.3.

Release notes

Sourced from @​opennextjs/cloudflare's releases.

@​opennextjs/cloudflare@​1.20.3

Patch Changes

• #1361 8c31fbc Thanks @​vicb! - chore: bump @opennextjs/aws to 4.1.1

  See details at https://github.com/opennextjs/opennextjs-aws/releases/tag/v4.1.1

• #1359 65e4487 Thanks @​vicb! - chore: bump the Next.js peer dependency to 15.5.24 / 16.3.3

• #1359 65e4487 Thanks @​vicb! - fix: patch the Turbopack wasm helpers that Next.js 16.3 emits in the chunks

  Until Next.js 16.2 the Turbopack wasm loaders were named loadWebAssembly and loadWebAssemblyModule functions living in [turbopack]_runtime.js, which the adapter rewrote to resolve the chunk through a static import(). Next.js 16.3 emits them on demand in the chunks instead ([turbopack-wasm]/node/loadWasm.ts), so the existing patch silently stopped matching and WebAssembly.compileStreaming - which workerd does not implement - survived into the Worker.

  Every wasm backed import then threw TypeError: WebAssembly.compileStreaming is not a function at runtime, most visibly breaking Prisma with the workerd client runtime.

  The chunks emitted by Turbopack are now patched as well, for both the server and the Node.js middleware bundles.

• #1309 56dfacc Thanks @​ScienHAC! - feature: support Node.js middleware (proxy.ts)

  Next.js 16 replaces middleware.ts with proxy.ts which always runs on the Node.js runtime.

  The Node.js middleware is now bundled into a Workers compatible middleware/handler.mjs: the OpenNext config manifests are inlined at build time (as for the edge middleware) and the middleware compiled by Next.js is statically bundled instead of being loaded from the filesystem at runtime (workerd can not access the filesystem nor load modules at runtime).

  The support is experimental and requires the nodejs_compat compatibility flag.

• #1359 65e4487 Thanks @​vicb! - fix: do not load the instrumentation hook from the Node.js middleware bundle

  Next.js 16.3 registers the instrumentation hook from the middleware itself when the middleware does not run on the edge runtime, by dynamically requiring .next/server/instrumentation.js. workerd does not support dynamic requires so every request handled by the Node.js middleware (proxy.ts) failed with Dynamic require of ".next/server/instrumentation.js" is not supported.

  The guard Next.js uses (process.env.NEXT_RUNTIME !== "edge") is inlined by Next.js when it compiles the middleware, so it can not be eliminated when the middleware is re-bundled. The loader is stubbed out instead, which matches the edge runtime behaviour: the server function - which shares the isolate - keeps registering the hook.

@​opennextjs/cloudflare@​1.20.2

Patch Changes

• #1312 38ea40b Thanks @​james-elicx! - fix: handle encoded middleware and cache paths safely

... (truncated)

Changelog

Sourced from @​opennextjs/cloudflare's changelog.

1.20.3

Patch Changes

• #1361 8c31fbc Thanks @​vicb! - chore: bump @opennextjs/aws to 4.1.1

  See details at https://github.com/opennextjs/opennextjs-aws/releases/tag/v4.1.1

• #1359 65e4487 Thanks @​vicb! - chore: bump the Next.js peer dependency to 15.5.24 / 16.3.3

• #1359 65e4487 Thanks @​vicb! - fix: patch the Turbopack wasm helpers that Next.js 16.3 emits in the chunks

  Until Next.js 16.2 the Turbopack wasm loaders were named loadWebAssembly and loadWebAssemblyModule functions living in [turbopack]_runtime.js, which the adapter rewrote to resolve the chunk through a static import(). Next.js 16.3 emits them on demand in the chunks instead ([turbopack-wasm]/node/loadWasm.ts), so the existing patch silently stopped matching and WebAssembly.compileStreaming - which workerd does not implement - survived into the Worker.

  Every wasm backed import then threw TypeError: WebAssembly.compileStreaming is not a function at runtime, most visibly breaking Prisma with the workerd client runtime.

  The chunks emitted by Turbopack are now patched as well, for both the server and the Node.js middleware bundles.

• #1309 56dfacc Thanks @​ScienHAC! - feature: support Node.js middleware (proxy.ts)

  Next.js 16 replaces middleware.ts with proxy.ts which always runs on the Node.js runtime.

  The Node.js middleware is now bundled into a Workers compatible middleware/handler.mjs: the OpenNext config manifests are inlined at build time (as for the edge middleware) and the middleware compiled by Next.js is statically bundled instead of being loaded from the filesystem at runtime (workerd can not access the filesystem nor load modules at runtime).

  The support is experimental and requires the nodejs_compat compatibility flag.

• #1359 65e4487 Thanks @​vicb! - fix: do not load the instrumentation hook from the Node.js middleware bundle

  Next.js 16.3 registers the instrumentation hook from the middleware itself when the middleware does not run on the edge runtime, by dynamically requiring .next/server/instrumentation.js. workerd does not support dynamic requires so every request handled by the Node.js middleware (proxy.ts) failed with Dynamic require of ".next/server/instrumentation.js" is not supported.

  The guard Next.js uses (process.env.NEXT_RUNTIME !== "edge") is inlined by Next.js when it compiles the middleware, so it can not be eliminated when the middleware is re-bundled. The loader is stubbed out instead, which matches the edge runtime behaviour: the server function - which shares the isolate - keeps registering the hook.

1.20.2

Patch Changes

... (truncated)

Commits

• 9c3b797 Version Packages (#1358)
• 65e4487 chore: bump Next.js to 15.5.24 and 16.3.3 (#1359)
• 8c31fbc bump @opennextjs/aws to 4.1.1 (#1361)
• 56dfacc feat: support Node.js middleware (proxy.ts) (#1309)
• da4b7fc Version Packages (#1307)
• 38ea40b fix: upgrade OpenNext AWS encoded path handling (#1312)
• 766eee9 chore: bump Next.js to 15.5.21 and 16.2.11 (#1313)
• 97ef330 fix: normalize Windows paths in Turbopack runtime patch (#1306)
• 1a70b33 Version Packages (#1298)
• 780a21c fix: disable compression for worker version requests (#1297)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)