Next.js Discord

Discord Forum

Turbopack panics with standard browserslist (>0.2%, not dead) due to stale browserslist-rs data

Unanswered
Pavement ant posted this in #help-forum
Open in Discord
Pavement antOP
We are trying to migrate from webpack to Turbopack but Turbopack crashes with a Rust panic when using a standard browserslist like >0.2%, not dead, not op_mini all.

Reproduction repo (zero dependencies, just Next.js + React): https://github.com/mhdsdt/turbopack-bigint-exponentiation-repro

The page is just this:
async function compute() {
  return 10n ** 18n;
}
export default function Home() {
  return <div>{typeof compute}</div>;
}


Error:
thread 'tokio-runtime-worker' panicked at
  swc_ecma_compat_es2015-42.0.0/src/generator.rs:507:21:
  not yet implemented: right-associative binary expression

We traced through the source code and found the root cause. The JS side of Next.js resolves the browserslist with up-to-date caniuse-lite data and sends strings like "chrome 146" to Turbopack. But Turbopack re-resolves them in Rust using browserslist-rs v0.19.0 which only knows up to Chrome 141. Unknown versions get silently dropped, the target list ends up empty, and SWC enables every compat transform. The ES2015 generator transform then hits the ** operator and panics because it has a todo!() for right-associative binary expressions.

SWC already fixed this for the webpack code path in PR #11457 (Jan 2026) but Turbopack bypasses that fix because it pre-resolves the browserslist in Rust and passes parsed versions directly.

Using --webpack works fine as a workaround.

Tested on 16.2.1-canary.13. Full root cause analysis with source code references in the issue: https://github.com/vercel/next.js/issues/92091

0 Replies