• refactor: always split runtime module first #9419 👈 (View in Graphite)
• test(rolldown): regression fixture for #9401 #9418
• main

How to use the Graphite Merge Queue

Add the label graphite: merge-when-ready to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

This stack of pull requests is managed by Graphite. Learn more about stacking.

Open in StackBlitz

npm i https://pkg.pr.new/rolldown/rolldown/@rolldown/browser@9419

npm i https://pkg.pr.new/rolldown/rolldown/@rolldown/debug@9419

npm i https://pkg.pr.new/rolldown/rolldown@9419

npm i https://pkg.pr.new/rolldown/rolldown/@rolldown/binding-android-arm64@9419

npm i https://pkg.pr.new/rolldown/rolldown/@rolldown/binding-darwin-arm64@9419

npm i https://pkg.pr.new/rolldown/rolldown/@rolldown/binding-darwin-x64@9419

npm i https://pkg.pr.new/rolldown/rolldown/@rolldown/binding-freebsd-x64@9419

npm i https://pkg.pr.new/rolldown/rolldown/@rolldown/binding-linux-arm-gnueabihf@9419

npm i https://pkg.pr.new/rolldown/rolldown/@rolldown/binding-linux-arm64-gnu@9419

npm i https://pkg.pr.new/rolldown/rolldown/@rolldown/binding-linux-arm64-musl@9419

npm i https://pkg.pr.new/rolldown/rolldown/@rolldown/binding-linux-ppc64-gnu@9419

npm i https://pkg.pr.new/rolldown/rolldown/@rolldown/binding-linux-s390x-gnu@9419

npm i https://pkg.pr.new/rolldown/rolldown/@rolldown/binding-linux-x64-gnu@9419

npm i https://pkg.pr.new/rolldown/rolldown/@rolldown/binding-linux-x64-musl@9419

npm i https://pkg.pr.new/rolldown/rolldown/@rolldown/binding-openharmony-arm64@9419

npm i https://pkg.pr.new/rolldown/rolldown/@rolldown/binding-wasm32-wasi@9419

npm i https://pkg.pr.new/rolldown/rolldown/@rolldown/binding-win32-arm64-msvc@9419

npm i https://pkg.pr.new/rolldown/rolldown/@rolldown/binding-win32-x64-msvc@9419

commit: 6b923db

✅ Deploy Preview for rolldown-rs ready!

Name	Link
🔨 Latest commit	35054a1
🔍 Latest deploy log	https://app.netlify.com/projects/rolldown-rs/deploys/6a2135dc1aeb160008b1b6f1
😎 Deploy Preview	https://deploy-preview-9419--rolldown-rs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

To edit notification comments on pull requests, go to your Netlify project configuration.

Merging this PR will not alter performance

✅ 4 untouched benchmarks
⏩ 10 skipped benchmarks¹

_{Comparing 05-16-refactor_always_split_runtime_module_first (24361d4) with main (696cad1)²}

Reviewed this PR — the standalone-first runtime placement is a good direction and the cycle/TLA reasoning holds up. I found one confirmed correctness regression (verified with a live A/B run) and two lower-priority items (reasoned from the code, but not rigorously verified). Details below.

🔴 Confirmed (verified): runtime merge ignores preserveEntrySignatures and leaks helper exports onto an entry chunk

try_merge_runtime_chunk can fold the runtime module into a user-defined entry chunk without consulting preserveEntrySignatures. When another chunk reads a helper from that entry cross-chunk, the helper symbols (__esmMin, __toESM, …) — plus internal symbols like init_lib — get published onto the entry's public export surface, changing its signature.

The facade / common-chunk merge path guards exactly this via can_merge_without_changing_entry_signature (chunk_optimizer.rs:816-818), but the runtime merge path has no such guard. Note also that find_single_runtime_bitset_host (chunk_optimizer.rs:1246-1272) does not require ChunkKind::Common, so it can select a user entry as the host; and runtime_merge_target_is_allowed (1289-1294) only rejects ManualCodeSplitting.

Minimal reproduction (verified)

Drop this in as crates/rolldown/tests/rolldown/issues/repro_sig/ and run
cargo test -p rolldown --test integration repro_sig -- --ignored:

_config.json

{
  "config": {
    "input": [
      { "name": "main", "import": "./main.js" },
      { "name": "lib", "import": "./lib.js" }
    ],
    "format": "cjs",
    "exports": "named",
    "strictExecutionOrder": true,
    "preserveEntrySignatures": "strict",
    "minifyInternalExports": false
  }
}

lib.js (entry — declared signature is { foo, bar })

export const foo = 'foo_value';
export const bar = 42;

main.js (second entry — imports lib's exports and independently pulls runtime helpers)

import assert from 'node:assert';
import { foo, bar } from './lib.js';
assert.strictEqual(foo, 'foo_value');
assert.strictEqual(bar, 42);
export { foo, bar };

Equivalent JS-API options: input: { main, lib }, output: { format: 'cjs', exports: 'named', preserveEntrySignatures: 'strict', minifyInternalExports: false } (+ experimental.strictExecutionOrder).

Observed result (A/B), with explicit preserveEntrySignatures: "strict"

I ran the identical fixture on this PR's HEAD (24361d4b) and on pre-PR main (645ed627):

pre-PR main — lib.js exports exactly its declared signature ✅ (runtime/helpers/init_lib are isolated in a separate lib2.js chunk):

Object.defineProperty(exports, Symbol.toStringTag, { value: "Module" });
const require_lib = require("./lib2.js");
require_lib.init_lib();
exports.bar = require_lib.bar;
exports.foo = require_lib.foo;

This PR — runtime merged into the strict entry; helpers + init_lib leak onto lib.js ❌:

Object.defineProperty(exports, Symbol.toStringTag, { value: "Module" });
// HIDDEN [\0rolldown/runtime.js]
//#region lib.js
var foo, bar;
var init_lib = __esmMin((() => { foo = "foo_value"; bar = 42; }));
//#endregion
init_lib();
exports.__esmMin = __esmMin;   // ← leaked
exports.__toESM = __toESM;     // ← leaked
exports.bar = bar;
exports.foo = foo;
Object.defineProperty(exports, "init_lib", { enumerable: true, get: () => init_lib }); // ← leaked

Why this matters beyond opt-in strict

This also reproduces under the default preserveEntrySignatures: "exports-only", which is strict for entries that have exports — and it's already visible in this PR's own committed snapshots, e.g. topics/exports/entry_esm_named_named/artifacts.snap and entry_esm_named_default/artifacts.snap, where the lib entry gained __esmMin/__toESM/init_lib exports vs main. So default-config multi-entry builds with CJS interop / reified namespaces are affected, not just explicit strict.

Suggested fix

Add a signature guard to the runtime merge target selection: reject a candidate that is a user entry with preserve_entry_signature != AllowExtension when the merge would re-export helpers (i.e. more than one runtime consumer). Equivalently, only allow merging the runtime into such an entry when it is the sole runtime consumer (helpers stay internal, which is already the safe single-consumer case). Chunk.preserve_entry_signature already exists, so the guard is cheap. (Worth also checking whether the facade-elimination interaction that pulls the lib body into the entry should respect the same guard.)

🟡 Two lower-priority items (NOT rigorously verified — reasoned from the code only)

1. Perf: the runtime-symbol scan now runs unconditionally and largely redundantly. try_merge_runtime_chunk(None) is now called on every code-split build (code_splitting.rs:970), and in collect_runtime_consumer_chunks the || chain evaluates the expensive chunk_references_runtime_symbol (per-symbol canonical_ref_resolving_namespace scan, chunk_optimizer.rs:1333-1363) before the cheaper dependencies.contains(&runtime_module_idx) (1318). Since patch_module_dependencies already populates dependencies with the runtime owner for these same referenced symbols, the scan looks redundant on this path. Likely a cheap win to reorder those || operands (or gate the scan). I have not benchmarked this, and the existing CodSpeed presets are all single-entry so they don't exercise it — would be good to add a multi-entry/dynamic-import bench.

2. Test coverage: 3 chunking-form Rollup samples moved from passing → skipped. entry-point-without-own-code, namespace-object-import, namespace-reexports (×cjs/es, failed-tests.json; passed 1213→1207). The chunking-form suite only asserts chunk count, not contents, so a "one fewer chunk" delta gets skipped rather than characterized. The PR's explanation (runtime folded into a same-bitset host → one fewer chunk, behavior unchanged) is plausible and consistent with the code (the merge only ever removes the runtime chunk, never merges two user chunks), but I did not independently diff the actual _actual/ vs _expected/ output for these three. A content-aware rolldown-side fixture pinning the intended topology would make the "benign" claim durable.

(Also minor: the design-doc "Regression coverage" list omits issues/9597, the headline new fixture this PR adds.)

Reviewed this PR — the standalone-first runtime placement is a good direction and the cycle/TLA reasoning holds up. I found one confirmed correctness regression (verified with a live A/B run) and two lower-priority items (reasoned from the code, but not rigorously verified). Details below.

🔴 Confirmed (verified): runtime merge ignores preserveEntrySignatures and leaks helper exports onto an entry chunk

try_merge_runtime_chunk can fold the runtime module into a user-defined entry chunk without consulting preserveEntrySignatures. When another chunk reads a helper from that entry cross-chunk, the helper symbols (__esmMin, __toESM, …) — plus internal symbols like init_lib — get published onto the entry's public export surface, changing its signature.

The facade / common-chunk merge path guards exactly this via can_merge_without_changing_entry_signature (chunk_optimizer.rs:816-818), but the runtime merge path has no such guard. Note also that find_single_runtime_bitset_host (chunk_optimizer.rs:1246-1272) does not require ChunkKind::Common, so it can select a user entry as the host; and runtime_merge_target_is_allowed (1289-1294) only rejects ManualCodeSplitting.

Minimal reproduction (verified)

Drop this in as crates/rolldown/tests/rolldown/issues/repro_sig/ and run cargo test -p rolldown --test integration repro_sig -- --ignored:

_config.json

{
  "config": {
    "input": [
      { "name": "main", "import": "./main.js" },
      { "name": "lib", "import": "./lib.js" }
    ],
    "format": "cjs",
    "exports": "named",
    "strictExecutionOrder": true,
    "preserveEntrySignatures": "strict",
    "minifyInternalExports": false
  }
}

lib.js (entry — declared signature is { foo, bar })

export const foo = 'foo_value';
export const bar = 42;

main.js (second entry — imports lib's exports and independently pulls runtime helpers)

import assert from 'node:assert';
import { foo, bar } from './lib.js';
assert.strictEqual(foo, 'foo_value');
assert.strictEqual(bar, 42);
export { foo, bar };

Equivalent JS-API options: input: { main, lib }, output: { format: 'cjs', exports: 'named', preserveEntrySignatures: 'strict', minifyInternalExports: false } (+ experimental.strictExecutionOrder).

Observed result (A/B), with explicit preserveEntrySignatures: "strict"

I ran the identical fixture on this PR's HEAD (24361d4b) and on pre-PR main (645ed627):

pre-PR main — lib.js exports exactly its declared signature ✅ (runtime/helpers/init_lib are isolated in a separate lib2.js chunk):

Object.defineProperty(exports, Symbol.toStringTag, { value: "Module" });
const require_lib = require("./lib2.js");
require_lib.init_lib();
exports.bar = require_lib.bar;
exports.foo = require_lib.foo;

This PR — runtime merged into the strict entry; helpers + init_lib leak onto lib.js ❌:

Object.defineProperty(exports, Symbol.toStringTag, { value: "Module" });
// HIDDEN [\0rolldown/runtime.js]
//#region lib.js
var foo, bar;
var init_lib = __esmMin((() => { foo = "foo_value"; bar = 42; }));
//#endregion
init_lib();
exports.__esmMin = __esmMin;   // ← leaked
exports.__toESM = __toESM;     // ← leaked
exports.bar = bar;
exports.foo = foo;
Object.defineProperty(exports, "init_lib", { enumerable: true, get: () => init_lib }); // ← leaked

Why this matters beyond opt-in strict

This also reproduces under the default preserveEntrySignatures: "exports-only", which is strict for entries that have exports — and it's already visible in this PR's own committed snapshots, e.g. topics/exports/entry_esm_named_named/artifacts.snap and entry_esm_named_default/artifacts.snap, where the lib entry gained __esmMin/__toESM/init_lib exports vs main. So default-config multi-entry builds with CJS interop / reified namespaces are affected, not just explicit strict.

Suggested fix

Add a signature guard to the runtime merge target selection: reject a candidate that is a user entry with preserve_entry_signature != AllowExtension when the merge would re-export helpers (i.e. more than one runtime consumer). Equivalently, only allow merging the runtime into such an entry when it is the sole runtime consumer (helpers stay internal, which is already the safe single-consumer case). Chunk.preserve_entry_signature already exists, so the guard is cheap. (Worth also checking whether the facade-elimination interaction that pulls the lib body into the entry should respect the same guard.)

🟡 Two lower-priority items (NOT rigorously verified — reasoned from the code only)

1. Perf: the runtime-symbol scan now runs unconditionally and largely redundantly. try_merge_runtime_chunk(None) is now called on every code-split build (code_splitting.rs:970), and in collect_runtime_consumer_chunks the || chain evaluates the expensive chunk_references_runtime_symbol (per-symbol canonical_ref_resolving_namespace scan, chunk_optimizer.rs:1333-1363) before the cheaper dependencies.contains(&runtime_module_idx) (1318). Since patch_module_dependencies already populates dependencies with the runtime owner for these same referenced symbols, the scan looks redundant on this path. Likely a cheap win to reorder those || operands (or gate the scan). I have not benchmarked this, and the existing CodSpeed presets are all single-entry so they don't exercise it — would be good to add a multi-entry/dynamic-import bench.

2. Test coverage: 3 chunking-form Rollup samples moved from passing → skipped. entry-point-without-own-code, namespace-object-import, namespace-reexports (×cjs/es, failed-tests.json; passed 1213→1207). The chunking-form suite only asserts chunk count, not contents, so a "one fewer chunk" delta gets skipped rather than characterized. The PR's explanation (runtime folded into a same-bitset host → one fewer chunk, behavior unchanged) is plausible and consistent with the code (the merge only ever removes the runtime chunk, never merges two user chunks), but I did not independently diff the actual _actual/ vs _expected/ output for these three. A content-aware rolldown-side fixture pinning the intended topology would make the "benign" claim durable.

(Also minor: the design-doc "Regression coverage" list omits issues/9597, the headline new fixture this PR adds.)

addressed

Merge activity

• Jun 4, 8:20 AM UTC: The merge label 'graphite: merge-when-ready' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Jun 4, 8:22 AM UTC: IWANABETHATGUY added this pull request to the Graphite merge queue.
• Jun 4, 8:27 AM UTC: Merged by the Graphite merge queue.

@IWANABETHATGUY Would you run https://github.com/sapphi-red/zarara with the changes to ensure there's no regression? (if you haven't)

@IWANABETHATGUY Would you run https://github.com/sapphi-red/zarara with the changes to ensure there's no regression? (if you haven't)

I have run it twice locally, each time with 6000 seeds. Not sure if it is enough.

Ah, ok. That should be sufficient.