nextjs - 💡(How to fix) Fix Turbopack: WASM fetch URLs break on Vercel due to double-encoded ?dpl= deployment suffix [1 comments, 2 participants]

Link to the code that reproduces this issue

Any Next.js 16.2 app deployed to Vercel that imports a WASM module (e.g. via @sovereign-sdk/universal-wallet-wasm which does import * as wasm from "./wallet_wasm_bg.wasm").

To Reproduce

1. Create a Next.js 16.2 app that depends on a package using ESM WASM imports
2. Configure turbopack.rules with "*.wasm": { type: "wasm" }
3. Deploy to Vercel
4. Open browser console

Current vs. Expected behavior

Expected: WASM file loads successfully from /_next/static/chunks/05667dwwroz~t.wasm?dpl=dpl_xxx

Actual: Browser requests /_next/static/chunks/05667dwwroz~t.wasm%3Fdpl%3Ddpl_xxx?dpl=dpl_xxx which returns 404.

The ?dpl=dpl_xxx query string gets URL-encoded as part of the filename path (%3F and %3D), then appended again as a proper query parameter.

Root cause

In the Turbopack runtime (turbopack-*.js), the q() function constructs asset URLs:

let r = (self.TURBOPACK_ASSET_SUFFIX ?? document?.currentScript?.getAttribute?.("src")?.replace(/^(.*(?=\?)|^.*$)/, "")) || "";

function q(e) {
  return `${t}${e.split("/").map(e => encodeURIComponent(e)).join("/")}${r}`;
}

The suffix r captures ?dpl=dpl_xxx from the script tag's src attribute. When loadWebAssembly calls fetch(q(r)), it passes the WASM chunk name through encodeURIComponent, which correctly encodes the path segments. But the WASM chunk name itself doesn't contain the suffix — it's appended by ${r} at the end.

The problem is that for JS/CSS chunks loaded via <script> and <link> tags, the browser handles the URL correctly. But for WASM loaded via fetch(q(path)), the encodeURIComponent on path segments combined with the suffix produces a malformed URL.

Specifically, the WASM path goes through encodeURIComponent which is fine, but the constructed URL ends up as:

/_next/static/chunks/05667dwwroz~t.wasm?dpl=dpl_xxx

which then gets the suffix appended again, or the path itself somehow includes the encoded suffix.

Workaround

Use next build --webpack instead of Turbopack for production builds and configure webpack with asyncWebAssembly: true.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin 25.2.0

Binaries:
  Node: 24.12.0
  npm: 11.4.0
  Yarn: N/A
  pnpm: 10.10.0

Relevant Packages:
  next: 16.2.1
  react: 19.2.1
  react-dom: 19.2.1
  typescript: 5.9.3

Which area(s) are affected? (Select all that apply)

Turbopack

Which stage(s) are affected? (Select all that apply)

next build (default)

Additional context

• The WASM file is correctly emitted to .next/static/chunks/ during build
• The file serves correctly when accessed directly (without the double-encoded suffix)
• This only manifests on Vercel deployments that use the ?dpl= deployment suffix
• pnpm dev (Turbopack dev server) works fine since there's no deployment suffix