Turbopack: stale browserslist-rs data causes all SWC compat transforms to be enabled, panicking on ** operator

[mhdsdt]

Link to the code that reproduces this issue

https://github.com/mhdsdt/turbopack-bigint-exponentiation-repro

To Reproduce

1. Clone: git clone https://github.com/mhdsdt/turbopack-bigint-exponentiation-repro
2. npm install --force
3. npm run dev (runs next dev --turbopack)
4. Open http://localhost:3000 -- 500 error with Rust panic

The reproduction is a single page with an async function using the ** operator and a standard browserslist (>0.2%, not dead, not op_mini all) in package.json. No external dependencies beyond Next.js and React.

npm run dev:webpack works fine.

Current vs. Expected behavior

Current: Turbopack panics:

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

Expected: The page should compile successfully. The ** operator is standard ES2016, async is standard ES2017, and every browser in the >0.2%, not dead list supports both natively.

Root cause (traced through source code):

There is a caniuse-lite data version mismatch between the JS and Rust sides of the Turbopack pipeline:

1. Next.js resolves the browserslist on the JS side using an up-to-date caniuse-lite (knows Chrome 146, Firefox 149, etc.), then sends the resolved browser strings to Turbopack (hot-reloader-turbopack.ts:280)
2. Turbopack re-resolves them using browserslist-rs v0.19.0 (published July 2025, only knows up to ~Chrome 141) with ignore_unknown_versions: true, so unknown versions are silently dropped, returning an empty distribution list
3. Versions::parse_versions([]) returns all-None fields
4. is_any_target() returns true (all None = "unknown target")
5. When is_any_target is true, every SWC compat transform is enabled, including async-to-generator and the ES2015 generator transform
6. async-to-generator converts the async function into a generator
7. The generator transform encounters ** and panics at todo!("right-associative binary expression")

Why this only affects Turbopack (not webpack on canary):

SWC PR #11457 (merged Jan 2026) added an unknown_version flag to preset_env: when a browserslist query returns empty results, it assumes a modern browser and skips all transforms. Webpack benefits from this because SWC's targets_to_versions correctly sets unknown_version: true on empty results.

Turbopack bypasses this fix. It pre-resolves the browserslist in Rust (environment.rs:96-97), then passes already-parsed versions via Targets::Versions(versions) (transform/mod.rs:206), which always sets unknown_version: false in targets_to_versions. The unknown_version guard never fires.

Chrome version boundary test:

Browserslist	Result	Why
No browserslist	OK	Uses hardcoded defaults (chrome 111, edge 111, firefox 111, safari 16.4)
chrome 141	OK	Known to browserslist-rs 0.19.0
chrome 142	Panic	Unknown to browserslist-rs, silently dropped, is_any_target = true
firefox 130	OK	Known
firefox 148	Panic	Unknown
>0.2%, not dead	Panic	Resolves to Chrome 142+, Firefox 147+, etc.
>1%	OK	Happens to resolve to only known versions

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.3.0
  Available memory (MB): 24576
  Available CPU cores: 10
Binaries:
  Node: 20.20.0
  npm: 10.8.2
  Yarn: 1.22.22
  pnpm: 10.24.0
Relevant Packages:
  next: 16.2.1-canary.13
  eslint-config-next: N/A
  react: 19.2.4
  react-dom: 19.2.4
  typescript: 5.9.3
Next.js Config:
  output: N/A

Which area(s) are affected?

Turbopack, SWC

Which stage(s) are affected?

next dev (local), next build (local)

Additional context

This will affect more and more projects over time as browsers release new versions that browserslist-rs 0.19.0 doesn't know about. Any project with a standard browserslist (>0.2% is the Create React App default) will eventually hit this.

In real-world projects, the panic typically manifests through node_modules packages that contain async functions with the ** operator, since Turbopack transpiles node_modules (unlike webpack). Known affected packages include permissionless, @noble/curves, and @walletconnect/utils.

Possible fixes:

1. Update browserslist-rs in Turbopack to match the JS-side caniuse-lite data
2. Detect when parse_versions returns all-None and set unknown_version: true in Turbopack's preset-env config, so the existing SWC fix (allow use global typescript, without install on local project #11457) applies
3. Pass the browserslist query string to SWC instead of pre-resolving it in Rust, so Turbopack uses the same code path as webpack

Key source locations:

• Browserslist query sent from JS to Rust: hot-reloader-turbopack.ts:280
• Turbopack re-resolves with ignore_unknown_versions: true: environment.rs:71
• Pre-parsed versions bypass unknown_version: transform/mod.rs:206
• is_any_target() (all-None = enable everything): preset_env_base/src/lib.rs:98
• All transforms enabled: swc_ecma_preset_env/src/lib.rs:756
• The todo!() panic: swc_ecma_compat_es2015/src/generator.rs:507
• SWC fix that helps webpack but not Turbopack: swc-project/swc#11457

Related: pimlicolabs/permissionless.js#499 (same error, reported on the wrong repo)

[Citoyen-du-monde]

This is a major blocker for our Turbopack adoption.

We maintain a Next.js 16 Pages Router app — a perpetuals DEX frontend with a deep web3/crypto dependency tree:

Package	Version
viem	^2.45
wagmi / @wagmi/core	^3.4 / ^3.3
permissionless	^0.3.4
ethers	^6.16
@privy-io/react-auth	^3.13
@walletconnect/*	2.21.8 (pinned)
@noble/curves / @noble/hashes	1.9.7 / 1.8.0 (pinned)
@scure/bip32 / @scure/bip39	1.7.0 / 1.6.0 (pinned)
@coral-xyz/anchor	^0.32.1
@solana/spl-token	^0.4.14

These libraries (and their transitive deps) ship modern syntax — exponentiation (**), optional chaining, nullish coalescing, etc. — that needs to be downleveled to match our browserslist:

"browserslist": {
  "production": [">0.2%", "not dead", "not op_mini all"]
}

With webpack this works fine — Babel/SWC processes node_modules through the browserslist pipeline and everything gets transpiled. With Turbopack, modern syntax inside dependencies is not run through the browserslist transpilation system (tracked in #83799). The result is untranspiled code hitting browsers that don't support it, causing runtime failures on page load.

We've been forced to keep --webpack on both our dev and build scripts as a workaround:

"dev": "next dev --experimental-https --webpack",
"build": "next build --webpack"

Our next.config.mjs also relies heavily on webpack-specific plugins (TerserPlugin, CompressionPlugin, CssMinimizerPlugin, ImageMinimizerPlugin, CopyWebpackPlugin) which adds to the migration friction — but the browserslist/transpilation gap is the core blocker. Even if we stripped all the custom webpack config, the untranspiled dependency code alone makes Turbopack unusable for us.

This is especially painful for web3 projects where the majority of your dependency graph is crypto/wallet libraries shipping ESNext, and transpilePackages doesn't help because the offending code is buried in transitive dependencies 3-4 levels deep.

[rwnbrx]

This is blocking us from migrating to Turbopack. We're building a product and our dependency tree is full of web3/crypto packages (permissionless, @noble/curves, @walletconnect) that all have async functions with the ** operator. We use the standard >0.2% browserslist and Turbopack just crashes on every page load. We've been stuck on webpack because of this.

[alitdev]

We’re facing the same issue as well, and we’re building in the crypto space.