Turbopack silently downlevels to ES5 and expands \p{...} above its compat data

[ejc3]

When the oldest browser in an app's resolved browserslist is newer than every version in
Turbopack's bundled compat data, next build emits the client bundle as ES5 and
expands \p{...} property escapes into bracketed character classes. No warning appears in the
build output.

The expansion is the part that breaks working code.

Which queries break

Measured on 16.3.3, which starts downlevelling at chrome 142. Only browserslist varied.

browserslist	resolves to	oldest	\p{Script=Han}	class	chunk bytes
chrome 141	chrome 141	141	kept	kept	566,057
chrome >= 123	chrome 151 down to chrome 123	123	kept	kept	566,057
chrome >= 150	chrome 151, chrome 150	150	expanded	ES5	608,683
last 2 Chrome versions	chrome 151, chrome 150	150	expanded	ES5	608,683
last 1 Chrome version	chrome 151	151	expanded	ES5	608,683
chrome 200	falls back to MODERN_BROWSERSLIST_TARGET	111	kept	kept	566,057
(no key)	falls back to MODERN_BROWSERSLIST_TARGET	111	kept	kept	566,057

The oldest resolved browser decides, not the newest. chrome >= 123 is safe although it
resolves up to 151.

chrome 200 is safe for an unrelated reason. browserslist throws Unknown version 200 of chrome, getSupportedBrowsers() catches it with a bare catch {}
(next/dist/build/get-supported-browsers.js), and you get MODERN_BROWSERSLIST_TARGET. So
chrome 999 reproduces nothing.

A raw last N versions resolves to ie 11, bb 7, op_mini all, so its ES5 output is expected
and is not a repro of this.

Boundary by release

	starts downlevelling at	last 1 Chrome version resolves to	affected
next@16.3.3	chrome 142	chrome 151	yes, today
next@16.4.0-canary.10	chrome 154	chrome 151	yes, at a pinned chrome 154

On canary, chrome 141 through chrome 153 are kept at 566,060 bytes and chrome 154 expands
to 607,866. last 1 Chrome version resolves to 151 there, so it starts breaking three Chrome
releases from now with no change on the app's part. On 16.3.3 it already resolves into the
range that breaks.

Canary fails the same way at the first Chrome version past its own data, which is the case for
fixing the fallback rather than relying on the data staying ahead of Chrome.

Reproduction

app/page.tsx:

'use client';

const CJK = /\p{Script=Han}/u;

class Probe {
  readonly hit: boolean;
  constructor(sample: string) {
    this.hit = CJK.test(sample);
  }
}

export default function Page() {
  return <p>{`source=${CJK.source} hit=${String(new Probe('漢').hit)}`}</p>;
}

Add a default app/layout.tsx, a tsconfig.json, an empty next.config.ts, and set
"browserslist": ["last 1 Chrome version"].

Checks that give false negatives

Both of these report success while the bug is present:

• grep -c 'class ' across all chunks. The keyword survives in framework chunks whatever
  happened to the app's own code.
• Grepping for _classCallCheck. SWC inlines the guard instead of calling a named helper.

Selecting "the page's chunk" is also unreliable; two chunks match source= here, at 991 and
112,594 bytes. Scan the whole directory:

rm -rf .next
node ./node_modules/next/dist/bin/next build

grep -rlq 'Script=Han' .next/static/chunks/ && echo "property escape KEPT"
grep -rlq '2E80'       .next/static/chunks/ && echo "property escape EXPANDED"
grep -rlq 'Cannot call a class as a function' .next/static/chunks/ && echo "class DOWNLEVELED"

cat .next/static/chunks/*.js | wc -c

The build that produced the 608,683-byte row above says nothing about the target:

▲ Next.js 16.3.3 (Turbopack)
✓ Running next.config.ts took 26ms

  Creating an optimized production build ...
✓ Compiled successfully in 3.0s
  Running TypeScript ...
  Finished TypeScript in 294ms ...
✓ Generating static pages using 4 workers (3/3) in 366ms

The emitted page chunk, with both symptoms:

i=RegExp("[\\u2E80-\\u2E99\\u2E9B-\\u2EF3\\u2F00-\\u2FD5\\u3005\\u3007...]","u"),
e=function u(t){ ... throw TypeError("Cannot call a class as a function"); ... }

Both symptoms flip at the same boundary on both releases. I would look at the target fallback
before treating the regex and class transforms as separate bugs. getSupportedBrowsers() passes
the requested version through as the browserslistQuery project option, so the wrong behaviour
looks like it is downstream of that handoff rather than in it.

Why the expansion breaks code

On 16.3.3 the ES5 downlevel costs 42,626 bytes on this page, 566,057 to 608,683. On one real
application, deleting "browserslist": ["last 1 Chrome version"] cut client JS from 12,029,915
to 10,820,082 bytes, so the downlevelled bundle was 11 percent larger.

The expansion changes meaning rather than size. Libraries splice the fragment into a larger
class, which brackets of its own make malformed. @excalidraw/excalidraw does this:

Regex.class = (...r) => new RegExp(`[${r.map(x => x.source).join('')}]`, 'u');

const CJK = {
  CHAR: /\p{Script=Han}\p{Script=Hiragana}\p{Script=Katakana}\p{Script=Hangul}｀＇/u,
};

The compositions throw, including the one inside its own getLineBreakRegex fallback catch,
so the library's own fallback cannot catch it:

Uncaught (in promise) SyntaxError: Invalid regular expression: Lone quantifier brackets

It throws the first time a line wraps.

Expected

1. Treat a target newer than the bundled compat data as at least as capable as the newest
   version in that data. Today such a target gets the most conservative output Turbopack can
   produce, which is the opposite of what the query asked for.
2. Failing that, warn. The build output above says nothing, and the symptom, a bundle 11
   percent larger or a regex that throws the first time a line wraps, is a long way from the
   cause.
3. Separately: expansion should not apply for targets with native property-escape support
   (Chrome 64+, Safari 11.1+, Firefox 78+), all far below anything configured here.

If you take a fix, please put it in 16.3.x as well. That is the release where
last 1 Chrome version already resolves into the range that breaks.

The workaround meanwhile is to delete the browserslist key, which falls back to
MODERN_BROWSERSLIST_TARGET (chrome 111, edge 111, firefox 111, safari 16.4), below both
boundaries.

Environment

• next@16.3.3 and next@16.4.0-canary.10, Turbopack, Node 22.16.0, Linux x64,
  caniuse-lite 1.0.30001810.
• 16.4.0-canary.0 does not reproduce at chrome 147, so the boundary differs between the 16.3.3
  tag and canary.0. I did not identify what moved it.
• 16.4.0-canary.10 is the newest canary I tested.
• Every row is a fresh build with .next removed first.
• Also present with output: 'standalone', productionBrowserSourceMaps: true, and a
  non-default turbopack.root.