fix(turbopack): handle unresolvable browserslist via Targets::Query

[mhdsdt]

Fixes #92091

What?

When a project has a browserslist like >0.2%, not dead (the CRA default), Turbopack panics with not yet implemented: right-associative binary expression on any code that uses async + ** together.

Why?

Next.js resolves the browserslist on the JS side using an up-to-date caniuse-lite (which knows about Chrome 146, Firefox 149, etc.), then sends the resolved browser strings to Turbopack. Turbopack re-resolves them using browserslist-rs v0.19.0, which only knows up to about Chrome 141. Unknown versions are silently dropped because of ignore_unknown_versions: true in environment.rs.

With all versions dropped, Versions::parse_versions returns all-None fields. SWC's preset_env then sees is_any_target() == true and short-circuits its caniuse to "transform every feature", which includes async-to-generator and the ES2015 generator transform — and that transform has a todo!() for the ** operator at generator.rs:507.

SWC already handles this case for the raw browserslist path via the unknown_version flag added in swc-project/swc#11457. But Turbopack bypasses that flag because it passes pre-resolved Targets::Versions(versions) directly, and targets_to_versions always sets unknown_version: false on that variant.

How?

When versions.is_any_target() is true and a browserslist query string is available on the Environment, re-route through Targets::Query(Query::Single(query)) instead of Targets::Versions(empty). SWC's own resolver runs the query, observes the empty result, and sets unknown_version: true — the documented "modern browser, supports everything" semantics from swc#11457.

The user's experimental.swcEnvOptions (mode, coreJs, include, exclude, shippedProposals, forceAllTransforms, debug, loose) continue to flow through to SWC's Config unchanged, so SWC remains the source of truth for how those options interact with unknown_version.

Test plan

• New snapshot test swc_transforms/preset_env_unknown_browserslist covers an explicit chrome 99999 query. Without the fix it panics on the same todo!(); with the fix the async function ... return 10n ** 18n is preserved verbatim in the chunk output.
• Verified against the reproduction project: rebuilt the SWC binary against this branch, ran next dev --turbopack, page renders with status 200, and the emitted chunk contains the original async function compute() { return 10n ** 18n; } with no transforms applied.
• cargo check, cargo fmt --check, cargo clippy --all-targets -- -D warnings, and the full turbopack-tests snapshot suite all clean.

[nextjs-bot]

Allow CI Workflow Run

• approve CI run for commit: 06e8a3683135eb8f67e80e5c63ea60f20127a671

Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer

[nextjs-bot]

Allow CI Workflow Run

• approve CI run for commit: 051eed3

Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer

[codspeed-hq]

Merging this PR will not alter performance

✅ 8 untouched benchmarks
⏩ 12 skipped benchmarks¹

---

_{Comparing mhdsdt:fix/turbopack-browserslist-unknown-versions (06e8a36) with canary (e9597e6)}

Footnotes

1. 12 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[mhdsdt]

@afurm Good call, added that in the second commit. There's now a snapshot test under preset_env_unknown_browserslist that uses chrome 99999 as the target and has async + ** in the input. It verifies both are preserved in the output without downleveling. All 3 preset_env snapshot tests pass.

[mischnic]

This looks good, but you'll need to rebase this onto canary, #92272 was merged in the meantime

[mhdsdt]

This looks good, but you'll need to rebase this onto canary, #92272 was merged in the meantime

Rebased onto canary. The changes in #92272 touched the same match arm, so I wrapped the new preset-env config parsing inside the else branch of our is_any_target() guard so the guard runs first.

Verified locally: cargo check, fmt, clippy all clean. All 3 preset_env snapshot tests pass. Also rebuilt the SWC binary against the rebased branch and confirmed the reproduction project still renders without the panic.

[mischnic]

Now, experimental.swcEnvOptions would get ignored though if you specify too new versions here. It should still respect options like coreJs, mode and include.

[mhdsdt]

Now, experimental.swcEnvOptions would get ignored though if you specify too new versions here. It should still respect options like coreJs, mode and include.

Good point, thanks. Reworked the fix so we don't skip preset-env anymore. When is_any_target() is true we now route through Targets::Query with the original browserslist string, which lets SWC's own resolver set unknown_version: true for the empty result (the same path from swc-project/swc#11457).

All of experimental.swcEnvOptions (mode, coreJs, include, exclude, etc.) flows through to SWC's Config unchanged, so SWC stays in charge of how those options interact with unknown_version.

New version is pushed and the title/description are updated to match. Verified locally with cargo check, fmt, clippy, the full snapshot suite, and against the reproduction project (page renders with the async function ... 10n ** 18n preserved verbatim in the chunk).