Turbopack scope-hoisting emits wrong variable reference when inlining pre-minified ESM modules

[rmachado-hema]

Summary

We hit an SSR crash on Next.js 16.3.3 (Turbopack) where a component's .map() call ends up referencing a destructured string parameter instead of a child component, causing React to try to render a plain string as an HTML tag (Error: Invalid tag: <some text>).

The root cause is in how Turbopack renames variables during scope-hoisting inside __turbopack_context__ callbacks. We couldn't build a small standalone reproduction — the bug only triggers when enough modules are concatenated into a single callback, which doesn't happen in a minimal project.

Environment

next: 16.3.3 (Turbopack)
react: 19.2.8
node: 24.19.0
platform: darwin arm64
output: 'standalone'
optimizePackageImports enabled for the affected package

The pattern

We use a private UI component library that ships pre-minified ESM (standard Rollup output). Three component files each export a function a(...) with short import aliases — a normal minification pattern:

• ComponentA — exports function a, a simple wrapper component
• ComponentB — exports function a, imports ComponentA as e, uses it internally
• ComponentC — exports function a, imports ComponentB as n, maps over a prop calling n

ComponentC looks roughly like this in the minified dist:

import { ComponentB as n } from "./component-b.js";
import { jsx as r, jsxs as i } from "react/jsx-runtime";

function a({ title: a, columns: o }) {
    return i("section", {
        children: [
            r("h2", { children: a }),
            r("div", {
                children: o.map((e) => r(n, { ...e }, e.key))
                //                      ^ `n` is ComponentB
            })
        ]
    });
}
export { a as ComponentC };

These are imported via a barrel index in a server component, with optimizePackageImports enabled.

What Turbopack produces

After next build, the server chunk contains a __turbopack_context__ callback where all three functions are inlined. Turbopack renames the three a exports to a, a1, a2:

function a({...}) { /* ComponentA */ }

function a1({...}) {
    // ComponentB — correctly calls `a` (ComponentA) ✅
    return jsx(a, { ... });
}

function a2({title:a, columns:b}) {
    //        ^^^^^^^^ shadows the module-scoped `a` (ComponentA)
    return jsxs("section", {
        children: [
            jsx("h2", { children: a }),
            jsx("div", {
                children: b.map(b => jsx(a, {...b}, b.key))
                //                      ^ ❌ should be `a1` (ComponentB)
                //                        but is `a` (now the title string)
            })
        ]
    });
}

The .map() emits jsx(a, ...) instead of jsx(a1, ...). Since {title: a} also shadows a in that function scope, a resolves to the title string at runtime, and React's SSR crashes trying to render it as an HTML tag.

Why we couldn't build a standalone repro

In a small project, Turbopack uses a flat module scope with distinct variable names and handles the renaming correctly. The __turbopack_context__ concatenation pattern — where the bug occurs — only triggers when there are enough application-level modules in the module graph.

Workaround

Wrapping the affected component in a 'use client' file prevents Turbopack from inlining it into the server chunk:

'use client';
import { ComponentC } from 'my-ui-lib';
export const ComponentCWrapper = ComponentC;

Our hypothesis

When Turbopack renames three function a exports to a, a1, a2 during scope-hoisting, it correctly updates the cross-reference in a1 (ComponentB → ComponentA). But it fails to update the reference in a2: the import alias n (ComponentB) should be rewritten to a1, but is rewritten to a instead. This may be a conflict between the import-alias renaming and the destructuring alias {title: a} within the same function body.

Possibly related issues:

• When using Next.js with Turbopack and SWC, errors occur during compression of third‑party library code. #86568