FFMpeg Wasm lib not loading with turbopack dev enabled.

[eashish93]

Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/7mqmx8

To Reproduce

1. Run the application using next dev with --turbopack flag enabled.
2. Check the browser preview. If library loaded, that will print "ffmpeg Loaded" else will print "ffmpeg not loaded" (for debug purpose only).

Current vs. Expected behavior

Current Behaviour

• FFMpeg lib not loading with --turbopack flag enabled

Expected Behaviour

• Should work with that flag also. Happening with other wasm lib too - imagemagick wasm etc.

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
  Available memory (MB): 4102
  Available CPU cores: 2
Binaries:
  Node: 20.9.0
  npm: 9.8.1
  Yarn: 1.22.19
  pnpm: 8.10.2
Relevant Packages:
  next: 15.0.2 // Latest available version is detected (15.0.2).
  eslint-config-next: 14.2.1
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.4.5
Next.js Config:
  output: N/A

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

Turbopack

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

next dev (local)

Additional context

I've tested this with next 15.0.2 release with --turbopack flag enabled and it's not working with that. Without that flag library loading perfectly fine, even with earlier next.js versions.

[wesbos]

Reasoning behind this is that ffmpeg uses webworkers to load everything: https://github.com/ffmpegwasm/ffmpeg.wasm/blob/main/packages/ffmpeg/src/classes.ts#L186

new Worker is not supported yet in turbopack, but is planned: vercel/turborepo#3643 (comment)

[JesseKoldewijn]

Yeah I believe this should be fixed soon(ish) as @wesbos described. Yeah, there are some alternative work-around but I don't think they give you enough benefit for the hassle. Only possible option would be to postpone the usage of turbopack in your project until said issue has been resolved upstream.

Alternatively you could try what happens when you bundle the effected code into an external package and exclude this from the turbopack flow (think about an external package inside same repo and use ie turbo repo + pnpm workspaces for better DX)

[timneutkens]

new Worker is not supported yet in turbopack, but is planned: vercel/turborepo#3643 (comment)

We actually landed support for new Worker in between that comment and now 😄

The problem with this dependency is that it's using new Worker(variable, import.meta.url) there is no way a bundler (any bundler) can bundle this correctly given that variable isn't known at compile time. Seems they added some hack in the library specifically for webpack: https://github.com/ffmpegwasm/ffmpeg.wasm/blob/main/packages/ffmpeg/src/classes.ts#L197-L199 and webpack somehow ignored the "too dynamic" new Worker. The library should be updated to:

 new Worker(new URL(classWorkerURL), {
  type: "module",
}) :

Given that import.meta.url wouldn't be available anyway, maybe should be location.href or similar.