Loading .wasm files as assets with Turbopack

[raimondlume]

Summary

I want to import a static .wasm file from a library as an asset,
for example import riveWASMResource from '@rive-app/canvas-lite/rive.wasm';

I could achieve that before with a standard webpack rule:

config.module.rules.push({
      test: /\.wasm$/i,
      type: 'asset',
    });

How can I do the same with Turbopack? Couldn't find any resources or examples regarding this.

Additional information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.1.0: Thu Oct 10 21:00:32 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T6030
  Available memory (MB): 18432
  Available CPU cores: 11
Binaries:
  Node: 22.11.0
  npm: 10.9.0
  Yarn: N/A
  pnpm: 9.14.4
Relevant Packages:
  next: 15.1.6 // Latest available version is detected (15.1.6).
  eslint-config-next: N/A
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.7.2

Example

No response

[sunnypatell]

Turbopack doesn’t currently support custom WebAssembly (.wasm) handling via Webpack-like rules, but you can still import .wasm files using a manual fetch-based approach.

1. Why Your Webpack Rule No Longer Works

• Turbopack does not expose Webpack-like config.module.rules.
• .wasm files aren’t treated as assets automatically in Turbopack like they were in Webpack.

2. Workaround: Load .wasm as a Static Asset

Since Turbopack serves static assets from /public, move the .wasm file to /public and load it manually.

✅ Step 1: Place .wasm in /public

Move your .wasm file to public/rive.wasm.

✅ Step 2: Load It Dynamically

Modify your import logic to fetch the .wasm file instead of bundling it:

async function loadWasm() {
  const response = await fetch('/rive.wasm');
  const buffer = await response.arrayBuffer();
  return WebAssembly.instantiate(buffer);
}

loadWasm().then(({ instance }) => {
  console.log('WASM Loaded:', instance);
});

3. Alternative: Use a WASM Loader with Next.js

If you must import .wasm like before, use a package like @wasm-tool/wasm-pack-plugin:

npm install @wasm-tool/wasm-pack-plugin

Then load the WASM module dynamically:

import init from '@rive-app/canvas-lite/rive_wasm';

async function loadWasm() {
  await init();
}
loadWasm();

⚠ This may not be fully compatible with Turbopack yet.

Conclusion

✔ Move .wasm files to /public and fetch them manually to ensure compatibility.
✔ Turbopack does not allow direct .wasm imports like Webpack.
✔ Future Next.js updates may improve WASM support, but for now, use dynamic loading

[RampantDespair]

Catastrophic news D: especially since NextJS just made TurboPack the default as of 16.0.0

[jdgamble555]

wasm-pack-plugin is 7 years old and only works with Webpack.

You can't use a url import for NextJS edge functions. How do you import Wasm otherwise?

J

[mic34]

Turbopack doesn’t expose Webpack-style rules for .wasm → you can’t just re-use type: 'asset' there. Instead use one of a few practical workarounds (copy to public, serve via a Next API route, or copy-at-build with a script). I’ll show working code for each approach and note caveats.

Why your webpack rule stops working

Turbopack doesn’t honour config.module.rules the way Webpack did, and it doesn’t currently treat .wasm files automatically as emitted static assets. That’s why the old webpack type: 'asset' trick no longer works.

Options & concrete recipes

1) Easiest / most robust — copy the .wasm from the package into public/ (prebuild or postinstall), then fetch() it at runtime

This is the simplest approach and works with Turbopack immediately.

scripts/copy-wasm.js

// Node script that copies the wasm file from the npm package into public/
const fs = require('fs');
const path = require('path');

try {
  // resolve the wasm file inside the package:
  const src = require.resolve('@rive-app/canvas-lite/rive.wasm');
  const destDir = path.join(process.cwd(), 'public', 'wasm');
  const dest = path.join(destDir, 'rive.wasm');

  fs.mkdirSync(destDir, { recursive: true });
  fs.copyFileSync(src, dest);
  console.log('Copied', src, '→', dest);
} catch (err) {
  console.error('Failed to copy wasm:', err);
  process.exit(1);
}

package.json

{
  "scripts": {
    "postinstall": "node ./scripts/copy-wasm.js",
    "prebuild": "node ./scripts/copy-wasm.js",
    "build": "next build"
  }
}

Client loader (React client component / plain JS)

async function loadRiveWasm(importObject = {}) {
  const url = '/wasm/rive.wasm'; // where copy-wasm.js put it
  try {
    // preferred (fast) path when correct MIME is served:
    const res = await fetch(url);
    // instantiateStreaming is most efficient (but will error if MIME wrong)
    return await WebAssembly.instantiateStreaming(res, importObject);
  } catch (err) {
    // fallback: fetch bytes → instantiate
    const res = await fetch(url);
    const bytes = await res.arrayBuffer();
    return await WebAssembly.instantiate(bytes, importObject);
  }
}

Why this is good

• Works in dev + production under Turbopack.
• You keep the wasm next to other static assets and can control caching headers via your host.

References: this is the common Turbopack workaround recommended in the Next.js discussion; Vercel/Next also documents placing wasm in project root/public and fetching it.

2) Don’t copy: serve the wasm from an API route that reads it from node_modules

If you don’t want to copy files into public/, create an API route that reads the .wasm from the installed package and returns it with Content-Type: application/wasm. Client-side code fetch('/api/wasm/rive') and WebAssembly.instantiateStreaming(...) will then work (instantiateStreaming requires correct MIME type; fallback to .arrayBuffer() if needed).

Example (app router — app/api/wasm/route.ts)

import fs from 'fs';
import { NextResponse } from 'next/server';

export async function GET() {
  // resolve the wasm file inside node_modules
  const wasmPath = require.resolve('@rive-app/canvas-lite/rive.wasm');
  const buffer = await fs.promises.readFile(wasmPath);
  return new NextResponse(buffer, {
    status: 200,
    headers: {
      'Content-Type': 'application/wasm',
      'Cache-Control': 'public, max-age=31536000, immutable'
    }
  });
}

Client:

const res = await fetch('/api/wasm/rive');
try {
  const { instance } = await WebAssembly.instantiateStreaming(res, {/* imports */});
  // use instance.exports...
} catch (e) {
  // fallback if instantiateStreaming fails (MIME, etc.)
  const bytes = await res.arrayBuffer();
  const { instance } = await WebAssembly.instantiate(bytes, {/* imports */});
}

Why this is good

• Keeps wasm in the npm package; no file-copy step at install/build.
• Works with Turbopack because Next serves the API route.

Caveat

• Adds small runtime overhead (API route), but you can cache aggressively.

Reference: Vercel docs show examples of using wasm files via server-side code / API routes and that you can import or read wasm files from the project to use them in server/edge functions.

3) If you must keep the import-style API (like import x from '.../file.wasm') — not currently supported on Turbopack

People have tried to use webpack plugins/loaders (e.g. wasm-pack-plugin) but those are Webpack-only. Turbopack currently doesn’t support plugging in Webpack loaders/rules for .wasm assets (so the direct import → emitted URL flow won’t work today). The community recommends the copy-to-public or API-route routes as the practical options.

Tips & gotchas

• Use instantiateStreaming first, fallback to arrayBuffer — instantiateStreaming is faster but will throw if the server returns the wrong MIME type; the fallback is robust.
• For libraries that ship multiple wasm flavors (x86/arm) check the package for platform-specific names and copy the right one at install/build.
• If you deploy to Vercel you can rely on public/ or an API route — both are fine. Vercel also documents a ?module import used in server-side function contexts, but that is not a client-side Turbopack feature you can rely on to mimic Webpack's asset emission.
• Automate: put the copy script on postinstall and prebuild so CI and local dev stay in sync.

Recommendation (what I’d do)

Since you’re migrating from a Webpack rule, the fastest, least-surprising migration is to copy the .wasm into public/ at install/build (option 1) and keep the loader code that uses WebAssembly.instantiateStreaming with a fallback. If you prefer not to copy files, use option 2 (API route) to serve the package file directly. Both play nicely with Next 15 + Turbopack.

[jdgamble555]

Again, you must use import style in Vercel Edge functions (or Cloudflare, Deno, Bun, etc). fs etc is not supported and neither is fetch for wasm files (it is disabled for security).

So considering this is NextJS built by Vercel, you cannot use .wasm in middleware nor edge runtime.

J

[RampantDespair]

Thanks for the detailed explanations above, that all makes sense for plain .wasm assets.

However, how would you handle a wasm-bindgen-based module (e.g. one that ships index.js, index_bg.js, and index_bg.wasm, where index.js imports the wasm file with

import * as wasm from "./index_bg.wasm";
import { __wbg_set_wasm } from "./index_bg.js";
__wbg_set_wasm(wasm);