[sokra]

Summary

Adds a compact Turbopack runtime path for modules whose exports are entirely forwarded from other modules. It replaces one generated wrapper getter per binding with a flat re-export description, while preserving live-binding semantics and source evaluation order.

This revision also makes the optimization generic for synthetic re-export facades, rather than leaving facade integration in the stacked export-mangling PR:

• synthetic facades use ExportRegistrationMode::Reexport;
• their explicit reference list supplies ordering because they have no source ImportMap;
• an evaluation-only locals reference can be represented as an empty group;
• references whose import is performed by the compact registration do not emit it twice;
• pruned references and merged evaluation-only references are omitted, because they deliberately produce no namespace binding and may have no module factory in the chunk;
• async modules and known export-cycle circuit breakers retain the general registration path.

The runtime now inspects source property descriptors. Constant exports reuse the source value, live exports reuse the exact receiver-independent Turbopack namespace getter, and dynamic/proxy/missing properties fall back to a wrapper getter. Destination descriptors remain enumerable, non-configurable, read-only ESM namespace properties; setters are never forwarded.

Output examples

A re-export-only module can suppress its redundant import and use a module-id group:

// before
var ns = __turbopack_context__.i("a.js")
__turbopack_context__.s(["a", () => ns.a, "b", () => ns.b])

// after
__turbopack_context__.S(["a.js", "a,a,b,b"])

Two source modules become groups separated by 0:

__turbopack_context__.S([
  "first.js", "a,a,b,b",
  0,
  "second.js", "c,c",
])

Encoding is selected independently per group. A comma-containing name uses explicit pairs while another group can remain packed:

__turbopack_context__.S([
  "first.js", "b", "b", "has,comma", "has,comma",
  0,
  "second.js", "c,c",
])

A synthetic facade includes its evaluation-only locals part as an empty group, then its forwarded bindings in reference order:

__turbopack_context__.S([
  "reexports.js <locals>",
  0,
  "x.js", "x,x",
  0,
  "y.js", "y,y",
])

Inside a scope-hoisted factory, imports are retained and existing namespace objects are used as heads because another logical module in the merged factory may read them:

var locals = __turbopack_context__.i("reexports.js <locals>")
var x = __turbopack_context__.i("x.js")
__turbopack_context__.S([locals, 0, x, "x,x"], facadeId)

A merged evaluation-only locals reference is omitted from that list: scope hoisting supplies only an in-factory ordering placeholder, not a namespace variable that S could read.

Runtime representation

For each forwarded property, S reads the source descriptor:

• data descriptor → capture the value with the runtime's value tag;
• getter descriptor → reuse that exact getter (Turbopack-generated namespace getters are receiver-independent);
• no usable own descriptor → use () => namespace[name] as a defensive fallback.

Tests pin constant primitives, frozen objects, function values, live updates, exact getter identity, receiver independence, destination descriptor flags, omitted setters, and the fallback path.

Verification

• cargo test -p turbopack-ecmascript -p turbopack-tests — 590 unit, 302 execution, 3 auxiliary, 131 snapshot tests passed on this layer
• Full stacked Turbopack: mangle exports behind an escaping namespace via the facade #97770 verification — 590 unit, 303 execution, 3 auxiliary, 131 snapshot tests passed
• cargo clippy -p turbopack-ecmascript -p turbopack-core -- -D warnings
• cargo fmt --all -- --check
• Runtime TypeScript check (pnpm check in turbopack-ecmascript-runtime/js)
• pnpm build-all
• Dedicated coverage for ordinary import/re-export ordering, transformed DUMMY_SP declarations, callable CommonJS namespaces, synthetic facade ordering, scope-hoisted retained imports, pruned and merged evaluation references, async fallback, and export-cycle circuit breakers

Incremental size on top of #98932

Scratch comparison only, as requested: #98617 stayed based on canary. Three apps were built with scope hoisting both disabled and enabled. Client reports raw and deterministic gzip (gzip -9 -n, sorted JS files); server reports raw only. Every row was repeated byte-for-byte.

benchmark	scope hoisting	client raw	client gzip	server raw	real S sites (client/server)
basic-app	off	+510 B	+214 B	−6,114 B	0 / 56
basic-app	on	+510 B	+164 B	+8,618 B	0 / 0
heavy-npm-deps (lodash + Mantine + Mermaid)	off	−2,268 B	−432 B	+4,680 B	3 / 8
heavy-npm-deps (lodash + Mantine + Mermaid)	on	+522 B	+191 B	+8,630 B	2 / 2
module-cost	off	+510 B	+263 B	+7,432 B	0 / 6
module-cost	on	+510 B	+265 B	+8,624 B	0 / 1

Aggregate raw movement across the six rows is +32,164 B. The shared helper is only amortized in configurations with many eligible facade calls; scope hoisting commonly resolves forwarded bindings to locals, leaving few calls while every runtime copy still carries the helper.

Descriptor reuse does not change generated module code or call-site counts. Compared with the same facade integration using wrapper getters, it adds 155 B client raw and 527 B per runtime copy (1,054 B server raw in these apps). Its purpose is avoiding per-binding wrapper allocation / access indirection where a source value or getter already exists, not reducing bundle bytes. The size result was reported before continuing, and descriptor work proceeded by explicit maintainer direction.

[github-actions]

Tests Passed

Commit: 99b6050

[lukesandberg]

this very much overlaps with #98603

which doesn't address this particular kind of re-export (but supporting it is a minor change)

if they did then this would become

var ns = e.i(...)
e.s(['foo', 0,ns.foo]

which is more compact than the original from the PR description.

(see #98898 which adds this optimization)

Of course the approach here is even more compact, but i do wonder how many re-exports survive in production

Can you measure impact on something like vercel-site? next-site?

[sokra]

Before:

var ns = e.i(123)
e.s(['bar', () => ns.foo])

#98603:

var ns = e.i(123)
e.s(['bar', 0, ns.foo])

#98932:

var ns = e.i(123)
e.s(['bar', ns.foo])

This PR:

e.S([123, 'bar,foo']

So there is still some optimization on top of #98603 and #98932.

[sokra]

It would be good to include some benchmark (bundle size) result in the PR description. Maybe bench/basic-app, heavy-npm-deps and module-cost.