Better WASM fallback support for Turbopack

Feedback
,
1

Hi!

Just wanted to leave some feedback about Turbopack’s WASM fallback.

I was trying to run a Next.js project inside Ubuntu on Termux(Android). Since the native Turbopack bindings aren’t available there, Next.js falls back to the WASM bindings, which is expected.

However, it immediately fails with:

 ✓ Starting... 
Skipping creating a lockfile at /root/Mail/.next/dev/lock because we're using WASM bindings
Error: \`turbo.createProject\` is not supported by the wasm bindings.

I know this isn’t a supported environment right now, so I’m not reporting this as a bug.

I’m just hoping WASM support can become more complete in the future. I don’t expect native-level performance—I just think it’d be nice if Turbopack could still run in environments where native bindings aren’t an option.

Thanks for all the work on Next.js!

2

Hi Evan,

That sounds like a real limitation of the WASM fallback path rather than something wrong with your app.

The key part is:

Skipping creating a lockfile because we're using WASM bindings
Error: `turbo.createProject` is not supported by the wasm bindings

So Next is falling back to WASM because the native Turbopack/SWC binding is not available in that Termux environment, but the WASM binding does not implement everything Turbopack needs to start the dev server.

For now, the practical workaround is to explicitly use Webpack instead of Turbopack in that environment:

{
  "scripts": {
    "dev": "next dev --webpack",
    "build": "next build --webpack"
  }
}

Next’s install docs mention that Turbopack is the default now and Webpack can be forced with --webpack:

For the feature request itself, I’d include the exact Termux/Android version, CPU architecture, Node version, package manager, and Next.js version. That makes it easier for the Next/Turbopack team to separate “unsupported native platform” from “WASM fallback missing API surface.”

3

Thanks for the explanation.

One thing I’d like to emphasize is that my main goal isn’t just finding a workaround. Since Next.js 16 now relies heavily on Turbopack, I’m hoping to see either native Android ARM64 bindings for Turbopack/SWC or a more complete WASM fallback implementation in the future.

At the moment, forcing Webpack works around the issue, but it means Android/Termux users can’t take advantage of the default Turbopack experience. The error seems to indicate that the WASM fallback is missing APIs such as turbo.createProject, so improving WASM support would already make a big difference even before native Android support is available.

I’d be very excited to see official android-arm64 support or feature parity in the WASM bindings going forward.

4

Hi Evan,

That clarification makes sense. I’d frame this less as “please support my exact Termux setup” and more as “please avoid a dead-end fallback path.”

Right now the fallback gets far enough for Next.js to select the WASM bindings, but then Turbopack cannot actually start because a required API like turbo.createProject is missing. That is a confusing middle state: it looks like there is a fallback, but the fallback cannot run the default dev experience.

I think the feature request is strongest if it is split into two asks:

  1. Add native android-arm64 support for the Turbopack/SWC bindings, if Android/Termux is something the team wants to support.

  2. Improve the WASM fallback so it either supports the core APIs needed by next dev, or fails earlier with a clear message that Turbopack cannot run with WASM bindings in that environment.

I’d also include a minimal repro with:

Android version:
Termux version:
CPU architecture:
Node version:
Package manager + version:
Next.js version:
Command run:
Full error output:

Since next dev --webpack works, that helps show the app itself is not the issue. The gap is specifically native binding unavailable → WASM fallback selected → Turbopack API surface incomplete.