Turbopack generates invalid bundle when using browserslist with latest caniuse-lite

[KentoMoriwaki]

Link to the code that reproduces this issue

https://github.com/KentoMoriwaki/turbopack-caniuse-repro

To Reproduce

Clone https://github.com/KentoMoriwaki/turbopack-caniuse-repro and follow README.md

Current vs. Expected behavior

Currently it produces broken bundle. It is expected to produce correct bundle.

before

// with caniuse-lite@1.0.30001753

function comment(value, root, parent, siblings) {
    return (0, __TURBOPACK__imported__module__$5b$project$5d2f$node_modules$2f2e$pnpm$2f$stylis$40$4$2e$3$2e$2$2f$node_modules$2f$stylis$2f$src$2f$Tokenizer$2e$js__$5b$client$5d$__$28$ecmascript$29$__["node"])(value, root, parent, __TURBOPACK__imported__module__$5b$project$5d2f$node_modules$2f2e$pnpm$2f$stylis$40$4$2e$3$2e$2$2f$node_modules$2f$stylis$2f$src$2f$Enum$2e$js__$5b$client$5d$__$28$ecmascript$29$__["COMMENT"], (0, __TURBOPACK__imported__module__$5b$project$5d2f$node_modules$2f2e$pnpm$2f$stylis$40$4$2e$3$2e$2$2f$node_modules$2f$stylis$2f$src$2f$Utility$2e$js__$5b$client$5d$__$28$ecmascript$29$__["from"])((0, __TURBOPACK__imported__module__$5b$project$5d2f$node_modules$2f2e$pnpm$2f$stylis$40$4$2e$3$2e$2$2f$node_modules$2f$stylis$2f$src$2f$Tokenizer$2e$js__$5b$client$5d$__$28$ecmascript$29$__["char"])()), (0, __TURBOPACK__imported__module__$5b$project$5d2f$node_modules$2f2e$pnpm$2f$stylis$40$4$2e$3$2e$2$2f$node_modules$2f$stylis$2f$src$2f$Utility$2e$js__$5b$client$5d$__$28$ecmascript$29$__["substr"])(value, 2, -2), 0, siblings);
}

after

// with caniuse-lite@1.0.30001754

function comment(value, root, parent, siblings) {
    return (0, __TURBOPACK__imported__module__$5b$project$5d2f$node_modules$2f2e$pnpm$2f$stylis$40$4$2e$3$2e$2$2f$node_modules$2f$stylis$2f$src$2f$Tokenizer$2e$js__$5b$client$5d$__$28$ecmascript$29$__["node"])(value, root, parent, __TURBOPACK__imported__module__$5b$project$5d2f$node_modules$2f2e$pnpm$2f$stylis$40$4$2e$3$2e$2$2f$node_modules$2f$stylis$2f$src$2f$Enum$2e$js__$5b$client$5d$__$28$ecmascript$29$__["COMMENT"], (0, __TURBOPACK__imported__module__$5b$project$5d2f$node_modules$2f2e$pnpm$2f$stylis$40$4$2e$3$2e$2$2f$node_modules$2f$stylis$2f$src$2f$Utility$2e$js__$5b$client$5d$__$28$ecmascript$29$__["from"])(char()), (0, __TURBOPACK__imported__module__$5b$project$5d2f$node_modules$2f2e$pnpm$2f$stylis$40$4$2e$3$2e$2$2f$node_modules$2f$stylis$2f$src$2f$Utility$2e$js__$5b$client$5d$__$28$ecmascript$29$__["substr"])(value, 2, -2), 0, siblings);
}

This may be a bit noisy, but if we extract the diff, we can see that the char() function, which is defined in the stylist module, is not being resolved correctly, resulting in an undefined error for char().

- __TURBOPACK__imported__module__$5b$project$5d2f$node_modules$2f2e$pnpm$2f$stylis$40$4$2e$3$2e$2$2f$node_modules$2f$stylis$2f$src$2f$Tokenizer$2e$js__$5b$client$5d$__$28$ecmascript$29$__["char"])()
+ char()

It is unclear why this is happening, but it started occurring when the caniuse-lite version was bumped to 1.0.30001754.
Even if we try to skip the stylis where this error occurs, similar errors occur in other places, so it seems that there is some kind of bug in turbopack.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.6.0: Wed Oct 15 21:12:44 PDT 2025; root:xnu-11417.140.69.703.14~1/RELEASE_ARM64_T8112
  Available memory (MB): 24576
  Available CPU cores: 8
Binaries:
  Node: 22.10.0
  npm: 10.9.0
  Yarn: N/A
  pnpm: 9.15.3
Relevant Packages:
  next: 16.0.2 // Latest available version is detected (16.0.2).
  eslint-config-next: N/A
  react: 19.2.0
  react-dom: 19.2.0
  typescript: 5.9.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

SWC, Turbopack, Pages Router, Module Resolution

Which stage(s) are affected? (Select all that apply)

next dev (local)

Additional context

The above error disappears with the following changes

• Remove browserslist field from package.json
• Or downgrade caniuse-lite to 1.0.30001753 or earlier

I'm not sure that this is an error of turbopack or SWC. But I think something about bundling or compiling is wrong in some conditions.

[mischnic]

This is specific to char, as it was a reserved word until ES3:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical_grammar#future_reserved_words

With chrome 142 it breaks, and with chrome 141 it works fine.
This is why upgrading caniuse makes a difference: with the old version, last 1 chrome version translates to 140, but with the new version, it's 142.

[KentoMoriwaki]

@mischnic There were other places that failed with “boolean” as well, so your explanation clicks for me. Thank you.

Is this the expected behavior? Using future reserved words as module variables would end up breaking. It had worked until now, so if Turbopack doesn’t plan to handle this on its side, should I understand that packages need to introduce breaking changes?

One more thing: is this Turbopack behavior, or SWC behavior?

[mischnic]

No, it should work. Not sure yet if it's an swc bug, or if it's Turbopack misusing the swc API.

[kdy1]

Investigation

swc_ecma_transforms_base does not check for reserved symbols at all.

So resolver and hygiene has nothing to do with this issue

[kdy1]

Well, this was not a bug of SWC. I'll look at turbopack source code

[kdy1]

One of my changes fixed it, but let me narrow it down