"next dev --turbo" fails in WASM with error (`turbo.createProject` is not supported by the wasm bindings)

theshadowagent commented 2 months ago

Link to the code that reproduces this issue

https://stackblitz.com/edit/stackblitz-starters-yew3c9

To Reproduce

Start next dev server with Turbopack (next dev --turbo) in WASM (e.g. using webcontainers.io)

The dev command fails with error


~/projects/stackblitz-starters-yew3c9
❯ npm install

added 10 packages, and changed 6 packages in 34s

144 packages are looking for funding run npm fund for details

~/projects/stackblitz-starters-yew3c9 34s ❯ npx next dev --turbo ▲ Next.js 15.0.0-canary.171 (turbo)

Local: http://localhost:3000

✓ Starting... Downloading swc package @next/swc-wasm-nodejs... to /home/.cache/next-swc Error: turbo.createProject is not supported by the wasm bindings. at Object.createProject (/home/projects/stackblitz-starters-yew3c9/node_modules/next/dist/build/swc/index.js:808:31) at createHotReloaderTurbopack (/home/projects/stackblitz-starters-yew3c9/node_modules/next/dist/server/dev/hot-reloader-turbopack.js:121:42) at async startWatcher (/home/projects/stackblitz-starters-yew3c9/node_modules/next/dist/server/lib/router-utils/setup-dev-bundler.js:164:38) at async setupDevBundler (/home/projects/stackblitz-starters-yew3c9/node_modules/next/dist/server/lib/router-utils/setup-dev-bundler.js:814:20) at async Span.traceAsyncFn (/home/projects/stackblitz-starters-yew3c9/node_modules/next/dist/trace/trace.js:157:20) at async initialize (/home/projects/stackblitz-starters-yew3c9/node_modules/next/dist/server/lib/router-server.js:87:30) at async Server.eval (/home/projects/stackblitz-starters-yew3c9/node_modules/next/dist/server/lib/start-server.js:266:36)

Current vs. Expected behavior

I expected next dev --turbo to work in WASM mode so I could have fast hot reloading, but it throws this error

Provide environment information

❯ npx next info

Operating System:
  Platform: linux
  Arch: x64
  Version: Ubuntu 20.04.0 LTS
  Available memory (MB): NaN
  Available CPU cores: 8
Binaries:
  Node: 18.20.3
  npm: 10.2.3
  Yarn: 1.22.19
  pnpm: 8.15.6
Relevant Packages:
  next: 15.0.0-canary.171 // Latest available version is detected (15.0.0-canary.171).
  eslint-config-next: 13.5.1
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.2.2
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 tested my reproduction against "15.0.0-canary.171" (latest canary release), and "14.2.13" (latest stable release). On stable it outputs a different error: TypeError: bindings.turbo.createProject is not a function.

I found the code that throws this: https://github.com/vercel/next.js/blob/3ed9f4b3f4d1f8b431ff04d4e6a45a949680a31f/packages/next/src/build/swc/index.ts#L1063

Is wasm bindings support planned for turbopack anytime soon? Was very bummed to see this, since it considerably slows down next.js in browser IDEs.

samcx commented 2 months ago

@theshadowagent Thank you for submitting an issue!

I was not able to this.

CleanShot 2024-09-30 at 23 28 47@2x

abhi12299 commented 2 months ago

the link provided works fine - no WASM errors on stackblitz

theshadowagent commented 2 months ago

@samcx @abhi12299 Here's an update on how to reproduce:

Open the Stackblitz link I provided & stop the existing terminal command using Ctrl+C. The issue is that Stackblitz runs next dev without --turbo flag by default (specifically, it runs npm install && npx next dev)
Manually run npm install && npm run dev which runs the next dev --turbo command and fails

Apologies for confusing you here – I couldn't find a way to change the default run command in Stackblitz

Thanks for the swift response!

theshadowagent commented 2 months ago

Also wanted to add about why it's important for me: My default next14 + shadcn + tailwind project takes ~60 seconds to boot in Webcontainers without --turbo flag, and 83% of the time is spent on the compile step, which I suspect takes so long due to using Webpack instead of Turbopack.

timneutkens commented 2 months ago

Turbopack does not have a WebAssembly build currently so I'm not expecting it to work on Stackblitz right now.

It's not unexpected that running in Stackblitz is slower than locally because it will have to download the WebAssembly binary and then use that instead of using the native bindings.

theshadowagent commented 2 months ago

@timneutkens thanks, I understand. Is WebAssembly build for Turbopack on the roadmap somewhere, or should I switch to server environment?

On WebAssembly binary: I've managed to reduce the time by 2x via adding @next/swc-wasm-nodejs to my package.json, but that only worked with next@13.5.1. next@14.2.14 still downloads the binary (at least according to console) even if it's present in package.json.

Still, compile step takes about 10s, so WebAssembly build for Turbopack would be amazing. See bolt.new for why it might be important

timneutkens commented 2 months ago

We're currently focused on making sure that as many people as possible get the benefits of Turbopack, which means prioritizing development / builds with the native binding, after Turbopack development and build are stable we can investigate WebAssembly builds, though it's not straightforward to add this because of the premise of the compiler, which includes file watching, disk access (read/write) etc.

theshadowagent commented 2 months ago

Got it, makes total sense! I think I'll switch to server VMs for now. I'm curious if this release helps to progress on this: https://deno.com/blog/rusty-v8-stabilized

illegitimate-egg commented 1 month ago

Bumping this, except for me rather than not working on stackblitz it doesn't work on my FreeBSD laptop

vercel / next.js