[robobun]

Problem

• The same sources build to different output each time. On Bun 1.4.2 one server build gives 8 contents of out/server.js in 40 builds and 5 --compile executables in 8. meta.json of five files has 2 contents in 50 builds.
• MetafileBuilder::generate (MetafileBuilder.rs:247) lists inputs by source index. compute_chunks (computeChunks.rs:516) sorts CSS chunks, the output stylesheets, by a hash of source indices. A source index follows the arrival of parse results.
• No user report. Repeated builds found it.

Fix

• generate walks reachable_files, as LinkerGraph.rs:242 says and as esbuild does.
• compute_chunks keeps CSS chunks in the order the entry points made them. CssImportOrder::hash is unchanged.
• Verified: test/bundler/metafile.test.ts, 11 new tests. 10 fail on main every run.
• Self-reviewed: 14 concerns raised, 13 addressed. A scan-order shuffle for tests is a follow-up.

Background

• reachable_files is the linker's own order: the import graph walked from the entry points.
• The position of a CSS chunk reaches HTML import manifests, executables and [hash] names.
• The first design hashed paths into the chunk key. Two modules with one path then shared a stylesheet.

Downsides

• inputs has a new order: an entry point was first and now follows its imports. CSS chunks move to entry point order in all 22 tested shapes stable on main. A chunk that loads several stylesheets with import() gets a new [hash] name.
• generate runs 49 more instructions on a five-file build. compute_chunks makes 3 fewer allocator calls.
• Not fixed: server-imported pages (bundler: put the pages that server code imports in import order #46256), onResolve-answered entry points (bundler: resume the shared resolve pass for imports that went to onResolve plugins #45408), top-level await in an import cycle (bundler: compute top-level await as a fixed point #45949).

Notes

Request. Repeated builds of five files gave 2 meta.json files in 50 builds. The request was a rebase of this PR and a test of two sources with one path. That test showed a defect in the first design, so this push replaces the design.

Repro, five plain files.

printf 'import { a } from "./a.js";\nimport { b } from "./b.js";\nconsole.log(a + b);\n' > entry.js
printf 'import { x } from "./x.js";\nexport const a = x;\n' > a.js
printf 'import { y } from "./y.js";\nexport const b = y;\n' > b.js
printf 'export const x = 1;\n' > x.js
printf 'export const y = 2;\n' > y.js
for i in $(seq 50); do bun build entry.js --outdir=out --metafile=meta.json >/dev/null; sha1sum < meta.json; done | sort | uniq -c

main lists entry.js b.js a.js x.js y.js or entry.js b.js a.js y.js x.js. This PR lists x.js a.js y.js b.js entry.js in 50 of 50 builds. esbuild 0.25.1 gives that order too.

Repro, emitted bytes. server.js imports page.html. The script of the page has four import("./lazyN.js"), and each lazyN.js imports lazyN.css. Build with bun build server.js --target=bun --splitting --outdir=out.

Same sources, one directory	Bun 1.4.2	main 57fe602	this PR
out/server.js, 40 builds	8 contents	7 to 10	1
server-[hash].js, 24 builds	1 name, 6 contents	1 name, 7 contents	1 name, 1 content
--compile --splitting executable, 8 builds	5	3 to 5	1
meta.json of the five plain files, 50 builds	2	2	1

Why it matters without a report. docs/bundler/executables.mdx:378 says that builds stay reproducible. #42151 and #43811 added tests that compare two executables byte for byte. Their fixtures have no stylesheet. A full-stack server with two or more CSS chunks breaks that promise on main.

Why the first design is gone.

• It hashed the path of each file into the CSS chunk key. In bun build server.ts --target=bun, server.ts and the page it imports both use shared.css. main writes 5 files. The first design wrote 4, and the page linked ./server.css, the stylesheet of the server graph.
• It sorted inputs by path with the source index as tie-break. Two records with one path still changed places.
• Its docs section promised the same bytes in any directory. That is false today: a root-level index.js takes the name of its default export from the directory (alpha_default, beta_default).
• Also weighed: hash stable_source_indices into the key and keep the sort. One unrelated new file then moves the CSS outputs, and the hunk touches the lines of bundler: compare CSS import orders before two entry points share a stylesheet #46357.

History. inputs changes order on 1.3.9 too. The CSS part is newer. Four JS entry points with one stylesheet each give 1 outputs order in 30 builds on 1.3.9 and 6 on 1.3.10. #27040 gave those chunks a key that hashes source indices. The sort by key was already there.

What moves.

• inputs: the entry point was the first key. Each file now comes after the files it imports, and the entry point is last.
• CSS chunks in outputs, in Bun.build().outputs, in the CLI table and in the manifest of an HTML import: entry point order. Over 42 shapes with 40 builds each, this PR has one order in 42 shapes and main in 22. Each of those 22 gets entry point order. Two CSS entry points keep their order. bun build d.css b.css a.css c.css lists d a b c on main and d b a c here.
• One [hash] name. A chunk hashes the chunks it reaches in chunk order. A page whose script loads four stylesheets with import() is page-vhb6bsa8.js on main and page-yzwj0y4w.js here. With --css-chunking that name depends on the directory on main (page-112k66w8.js, page-63ja3jvn.js). Here it is one name.
• JS chunks keep the order they have on main. Past eight entry points that order is not entry point order. Ten JS entry points with one stylesheet each list JS e0 e8 e9 e1 .. e7 and CSS e0 .. e9.
• esbuild 0.25.1 lists inputs in the same order. It lists CSS entry points in argv order too.

Tests. 11 new tests in one describe.

• 4 use an onLoad plugin that holds a file until the bundler asks for an import of another file. That fixes the order in which parse results arrive, and each test builds in two orders.
• 5 run the CLI and assert an exact order that main does not give. One of them builds in three directories.
• 1 compiles an executable in two parse orders. It runs on release builds only: one compile takes 22 s on a debug build.
• 1 checks that a stylesheet in the server graph and the browser graph stays two chunks. On main its chunk count holds and its order depends on the directory.
• On Bun 1.4.2 and on a release build of main, 10 of the tests fail in 10 of 10 runs. A debug build of main fails 9 and skips the compile test. All 11 pass in 10 of 10 runs on a release build of this PR. The 10 that a debug build runs pass in 10 of 10 runs there.
• With the files_live lines of generate deleted, 3 of the tests fail. With a walk that skips one file of a chunk, the new debug assertion stops the build.

Measurements. Release builds of 57fe602 with and without this diff, Linux x64.

• 50 builds of the five files: 1 meta.json and 1 meta.md (main 2 and 2).
• 41 project-and-flag sets, 4 builds in each of two directories. One meta.json in 36 sets (main 2 to 5). One outputs order in 36 (main 21 to 26). The other 5 sets are the server build with two pages. No bundle name or byte differs from main. No inputs or outputs record differs from main.
• Two forced parse orders: 1 inputs order and 1 CSS chunk order (main 2 and 2).
• A plugin namespace with virtual modules, debug builds: 1 inputs order in 3 builds (main 3), the same 9 records.
• One stylesheet in the server graph and the browser graph: 5 output files, 2 stylesheets (main 5 and 2).
• compute_chunks with 4 CSS chunks, allocator calls on the bundle thread counted with gdb: 135 allocations and 71 frees (main 138 and 72). The function has 46,217 bytes (main 46,765).
• generate on the five files: 56 allocator calls, as on main. 35,875 instructions (main 35,826). The function has 9,301 bytes (main 9,246).
• text of the binary: 107,559,600 bytes (main 107,560,112).
• process_resolve_queue and on_parse_task_complete have the same instructions as on main: 486 and 3,661 disassembly lines, 0 differ when absolute addresses are masked.
• valgrind, perf, strace and bloaty are not installed on this machine. The counts come from gdb, size, nm and objdump.

Cost for a build that never had the problem. A build with no metafile and no CSS chunk runs none of the changed lines. A metafile build runs 49 more instructions in generate on the five files, with no new allocation and no sort. A build with CSS chunks loses two arena slices and one sort in compute_chunks.

Not fixed. Both hunks take their order from the entry point list. That list still follows arrival in three cases.

• HTML pages that server code imports: a server with two pages gives 1 meta.json in one directory and 2 over four directories (bundler: put the pages that server code imports in import order #46256).
• Entry points that an onResolve plugin answers after an await: 7 outputs orders in 20 builds, main 15 (bundler: resume the shared resolve pass for imports that went to onResolve plugins #45408). Plugin users see the CSS order move here and again when bundler: resume the shared resolve pass for imports that went to onResolve plugins #45408 lands.
• Server-component boundary entries of bun build --app. Found by reading, no PR yet.
• A top-level await behind an import cycle: 2 bundles and 2 meta.json in 16 directories, main 2 and 6 (bundler: compute top-level await as a fixed point #45949).
• Every page that server code imports has two inputs records with one key, and so has a file in both graphs. Their order is now fixed. After JSON.parse one record is left. So a file comes after its imports in the records, and not always in the parsed keys.
• Two import orders that differ only in @layer names share a stylesheet: bundler: compare CSS import orders before two entry points share a stylesheet #46357 owns it and has the case html/SeparateCSSWhenLayerNamesDiffer. This PR does not touch CssImportOrder::hash.
• The errors of a failed build print in parse order: 11 orders in 30 builds of five files with one error each.
• The [hash] in the name of a server entry does not cover the manifest inside it. A change in one stylesheet of the page keeps the name server-pa3rha63.js and changes its bytes.

Questions for a maintainer.

• Entry point order is now the layout of CSS chunks. CSS entry points can keep the order they have on main: the sort then stays, with a key made from the entry point id. That variant moves fewer orders and pins a hash order in the tests.
• Does the reorder ship in a 1.4.x patch with a release-note line, or on the next list of breaking changes? bundler: make metafile import paths deterministic and match input keys #34534 went on the list for 1.4 (List of breaking changes for 1.4 #28792).

Self-review. 14 concerns raised, 13 addressed. Not done: a test-only switch that shuffles scan order, so that a suite finds the next reader of source indices. It touches the scan phase and belongs in its own PR.

Earlier code. The compute_chunks hunk is the one on branch robobun/fa954c11/closed-entry-point-list.

Suites run on a debug build. On the final diff: test/bundler/metafile.test.ts (75 pass, 1 skip) and 18 other files: esbuild/{metafile,css,splitting,loader}, bundler_{html,html_server,naming,plugin,bun,loader,files,defer}, html-import-manifest, css/css-modules, bun-serve-html, bun-serve-html-manifest, bun-serve-html-entry and bake/dev-and-prod. On the same two hunks before the last rebase, 24 more: bundler_{splitting,edgecase,browser,regressions,compile_splitting}, esbuild/dce, bun-build-api, cli, four files in css/, bake/dev/{css,html} and 10 regression files. 7 tests time out in bun-build-api, cli and bundler_compile_splitting (--compile, bytecode and a 180 s loop). The same 7 time out on a debug build of main on this machine.

---

no test proof · iteration 0 · platform-specific test(s) that do not run on this machine, deferring to CI, which covers all platforms: test/bundler/metafile.test.ts

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: oven-sh/bun
• Branch: farm/e9ef9e0d/metafile-deterministic-inputs
• File: .coderabbit.yaml
• Commit: 5a2cff7
• Layers: Repository YAML
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 26da64f4-5212-4c51-9e09-77c7ffa44640

Commits

Reviewing files that changed from the base of the PR and between 10b0f39 and 5a2cff7.

Files selected for processing: 3

• src/bundler/linker_context/MetafileBuilder.rs
• src/bundler/linker_context/computeChunks.rs
• test/bundler/metafile.test.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 0 remain after this review.

Walkthrough

The bundler now emits metafile inputs in reachable-file order and retains CSS chunk insertion order when assigning chunk positions and JavaScript CSS references. New tests vary plugin load completion order and compare metafile records, CSS outputs, embedded HTML manifests, and compiled executable hashes.

Changes

Deterministic bundler ordering

Layer / File(s)	Summary
Metafile input ordering src/bundler/linker_context/MetafileBuilder.rs, test/bundler/metafile.test.ts	Metafile inputs are emitted by traversing reachable files. A debug assertion checks seen-source bits for reachable files. Tests compare input ordering across builds and output formats.
CSS chunk order and output determinism src/bundler/linker_context/computeChunks.rs, test/bundler/metafile.test.ts	CSS chunks retain insertion order, and JavaScript CSS references use the first CSS chunk index. Tests compare CSS ordering, output records, embedded manifests, and compiled executable hashes.

Suggested reviewers: jarred-sumner, alii

Priority: Normal

Merge Risk: Minimal · up to 5a2cf

The ordering changes have no identified merge-blocking defect; the compiled-executable test follows an existing bundler-test timeout pattern.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly summarizes both primary changes: deterministic metafile input ordering and CSS chunk ordering by entry point.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Description check		The description is complete and relevant. It explains the problem, fix, scope, known limitations, performance impact, and verification results. It does not use the exact template headings, but it prov…

Full details: Description check

Explanation

The description is complete and relevant. It explains the problem, fix, scope, known limitations, performance impact, and verification results. It does not use the exact template headings, but it provides the required information in equivalent sections.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[claude]

The code change is straightforward and looks correct, but the new "Reproducible builds" docs section establishes a formal user-facing guarantee (byte-identical output across directories, no timestamps, no absolute paths, content-derived hashes) that a maintainer should sign off on — especially since imports[].path still leaks absolute paths pending #34534. There's also an unresolved comment-cop note on the 4-line comment at MetafileBuilder.rs:232 (I think it's a false positive — the comment explains a non-local invariant, not a workaround — but you may want to address it).

What was reviewed:

• The sort in generate() preserves all existing filter guards (seen_sources, RUNTIME, empty text/pretty) and uses index as tie-break for equal paths.
• path.pretty is &[u8]; byte-order .cmp() matches the JS .sort() in the test for the ASCII fixture paths.
• buildIn() now drains stdout alongside stderr (earlier nit addressed in 2abde25).

Extended reasoning...

Overview

Three files: MetafileBuilder.rs replaces the source-index-order iteration with collect → sort-by-pretty-path → emit; test/bundler/metafile.test.ts adds two determinism tests (cross-directory byte-identity via CLI, sorted-inputs via Bun.build); docs/bundler/index.mdx adds a new "Reproducible builds" section.

Security risks

None. This changes JSON key emission order in build metadata and adds documentation. No untrusted input parsing, no auth/crypto/permissions.

Level of scrutiny

The Rust change is low-risk and mechanical — the same filter guards are applied, only iteration order changes, and JSON key order is semantically meaningless to consumers. Tests are well-constructed (test.concurrent, tempDir, all pipes drained, both CLI and JS API surfaces covered, fixture designed so sorted order differs from discovery order).

The docs change is what tips this to human review: it documents a formal reproducibility contract (no timestamps, no absolute paths in sourcemap sources/metafile keys, content-derived hashes including debugId, deterministic ordering) that constrains future bundler behavior and that users will rely on. The PR description says bundles/sourcemaps/assets are "already byte-identical" but I can't independently verify that holds across all bundler configurations (splitting, plugins, --compile, HTML entrypoints, etc.). The claim is carefully scoped ("metafile's inputs and outputs keys", --compile explicitly excluded), but publishing a guarantee is a product decision a maintainer should confirm.

Other factors

• My earlier nit (stdout not drained in buildIn()) was fixed in 2abde25 and the thread is resolved.
• The comment-cop bot flagged the 4-line comment above ordered_inputs. I read it as a false positive: the comment explains why index order is non-deterministic (a fact about process_resolve_queue in another file), not a workaround justification. But it is unresolved on the PR.
• The stripDirPrefix helper in the test is a deliberate accommodation for #34534 (absolute paths in imports[].path), which the PR description calls out; the two fixes are designed to land independently.
• No CODEOWNERS cover these files.

[robobun]

Update, 2026-10-27. This comment describes the first design of this PR. That design is replaced: the path hash for CSS chunks merged the stylesheets of two modules that share a path, and the docs section is not in the PR any more. See the description for the current design.

---

Follow-up from self-review: probing multi-entry builds surfaced a second source of metafile nondeterminism, worse than the first. With multiple entry points importing CSS (including multi-page HTML builds), the outputs section listed CSS chunks in a different order on every run, even in the same directory. CSS chunks are deduplicated and ordered by a hash over their import order entries, and that hash used raw source indices, which are assigned in scheduling-dependent order.

fca392a fixes it by hashing the file's pretty path instead, so chunk identity and order become a function of the input files alone, and adds multi-entry CSS and multi-page HTML determinism tests (both fail on main). The docs section is also scoped more precisely: --format=cjs inlining of import.meta.url (it bakes the absolute source path into the bundle), --compile executables, and --bytecode artifacts are explicitly outside the guarantee.

The PR description now covers both mechanisms. CSS, HTML, and splitting suites pass: esbuild CSS (56), bundler_html (22), bundler_html_server, html-import-manifest, bundler_splitting.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/bundler/Chunk.rs`:
- Around line 1426-1436: Update the layer hashing loop in the chunk-key
generation logic to encode each layer component with its length before its raw
bytes, so embedded separators or NULs cannot create collisions between distinct
parsed identifiers. Keep layer boundaries unambiguous and preserve deterministic
ordering, then add a regression test covering equivalent-looking paths such as
escaped-dot components in different positions and assert they produce distinct
CSS chunk map keys.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 555ccc60-3625-4df2-9c3a-8c5c91c7ee34

📥 Commits

Reviewing files that changed from the base of the PR and between 1f606e6 and 93c9565.

📒 Files selected for processing (5)

• docs/bundler/index.mdx
• src/bundler/Chunk.rs
• src/bundler/linker_context/MetafileBuilder.rs
• src/bundler/linker_context/computeChunks.rs
• test/bundler/metafile.test.ts

[robobun]

Status: reworked on 2026-10-27. Ready for review.

How it was reproduced.

1. Five plain files: entry.js imports a.js and b.js, a.js imports x.js, b.js imports y.js. Run bun build entry.js --outdir=out --metafile=meta.json 50 times. main writes 2 different meta.json files. This PR writes 1.
2. Emitted bytes: server.js imports page.html. The script of the page has four import() of modules that each import a stylesheet. Run bun build server.js --target=bun --splitting --outdir=out 40 times. out/server.js has 8 contents on Bun 1.4.2, 7 on main and 1 with this PR.

The description has the full numbers, the orders that move, and what is not fixed.

PR: #36974

[claude]

All earlier review feedback has been addressed and this pass found no issues. Deferring to a human for two sign-offs: the new Reproducible builds docs section states a public byte-identity contract for bun build output, and CssImportOrder::hash now derives CSS chunk identity from pretty paths instead of source indices — both look correct and are covered by the new determinism tests, but they are product/behavioral commitments rather than mechanical fixes.

What was reviewed

• Metafile inputs sort in MetafileBuilder::generate — filter predicates preserved, tie-break on index keeps the sort total.
• CssImportOrder::hash length-prefixed encoding — self-delimiting for layers, external paths, and source pretty paths; both call sites in computeChunks.rs updated.
• New tests drain all pipes, use tempDir/test.concurrent, and strip only each build's own directory prefix before the byte-identity assertion.

Extended reasoning...

Overview

The PR makes bundler metafile and CSS chunk output deterministic across build directories. Three code changes: (1) MetafileBuilder::generate collects reachable input indices, sorts by path.pretty with index tie-break, then emits; (2) CssImportOrder::hash gains a sources: &[Source] parameter and hashes the file's pretty path instead of its scheduling-dependent source index, with every field length-prefixed so unescaped CSS identifiers cannot collide; (3) both hash call sites in computeChunks.rs pass sources. Four new determinism tests in test/bundler/metafile.test.ts and a new "Reproducible builds" section in docs/bundler/index.mdx.

Prior feedback resolved

My earlier inline comments (undrained stdout in buildIn, incomplete import.meta.* enumeration in the CJS docs caveat, and the pre-existing is_last index/length mismatch in the Layers hash arm) were fixed in 2abde25 and 93c9565. CodeRabbit's escaped-dot layer-component ambiguity was addressed in 10b0f39 by length-prefixing every count and byte string. All threads are resolved and this run's bug hunt found nothing.

Security risks

None identified. No untrusted input parsing was added; the hash is a non-cryptographic dedup key over bundler-internal data, and length-prefixing strictly reduces collision surface. The docs change is prose only.

Level of scrutiny

Medium-high. The sort in MetafileBuilder is mechanical, but the CssImportOrder::hash change redefines what makes two CSS chunks "the same" in compute_chunks' css_chunks map — a core bundler invariant. It looks correct (pretty paths are the same values used as metafile keys, and the encoding is now unambiguous), and the multi-entry CSS / multi-page HTML tests exercise the dedup path across runs and directories. Separately, the docs section is a user-facing reproducibility guarantee ("byte-identical bundles, sourcemaps, and assets on every run") with enumerated exceptions; per the repo's API-design guidance this is the kind of public contract a maintainer should explicitly agree to.

Other factors

Test quality is good: test.concurrent, tempDir with using, all pipes drained, no network, and the cross-directory assertion strips only each build's own absolute prefix so the remaining bytes must match exactly. The PR description shows the new tests fail on main (both debug+ASAN and release) and pass with the fix, and that the existing metafile/CSS/HTML/splitting suites pass. Given the docs contract and the chunk-identity semantics change, a maintainer sign-off is the right bar even though the implementation itself reads as correct.

[robobun]

This PR also fixes a second symptom of the same defect: the key order of metafile.inputs changes between identical builds in one directory and one process.

The repro uses public APIs only. It has three entry points with import() edges into 14 modules, splitting: true and metafile: true, and it runs the same build in a loop.

build	inputs key orders
release 1.4.2 (744846f)	7 different orders in 20 builds (2 of 2 runs)
canary 1.4.3-canary.1 (367d939, before the 1.4.3 tag)	8 different orders in 40 builds
main 5822b76 (debug, ASAN)	6 different orders in 10 builds
main 5822b76 merged with the first design of this PR (debug, ASAN)	1 order in 60 builds

Only the top-level inputs key order moves. outputs and every value under inputs are byte-identical between the runs. The entry points stay first, and the import groups of the three entry points permute.

The cause is the one this PR already names, with a second trigger. process_resolve_queue (src/bundler/bundle_v2.rs:6932) assigns a source index when the bundle thread handles a finished parse task. The entry points parse in parallel, so the order of the finished tasks follows thread scheduling. MetafileBuilder::generate writes inputs in source-index order. The description said that repeated builds in one directory are stable (8/8). That was wrong. One entry point with static imports only also changes order: five files give 2 orders in 50 builds.

Update, 2026-10-27. The paragraphs that were here pointed to the branch robobun/7e0d1f94/metafile-inputs-order. That branch held the first design of this PR (sort inputs by path, hash paths into the CSS chunk key). The first design merges the stylesheets of two modules that share a path, so the branch is deleted. The PR now has another design, see the description. It fixes the repro in this comment: 1 order in 20 builds.

Repro script

import fs from "node:fs"; import path from "node:path"; import os from "node:os";
const d = fs.mkdtempSync(path.join(os.tmpdir(), "mf-")); const N = 14;
for (let i = 0; i < N; i++) { let s = `export const v${i} = ${i};\n` + "// pad\n".repeat(((i * 37) % 11) * 300);
  for (const j of new Set([i + 1, (i * 5 + 3) % N, (i * 3 + 7) % N])) if (j < N && j > i) s += j % 2 ? `export const l${j} = () => import("./m${j}.js");\n` : `import * as s${j} from "./m${j}.js"; globalThis.k = s${j};\n`;
  fs.writeFileSync(path.join(d, `m${i}.js`), s); }
for (const e of [0, 1, 2]) fs.writeFileSync(path.join(d, `e${e}.js`), [0, 3, 5, 8, 11].map(i => `import("./m${(i + e) % N}.js");`).join("\n"));
const seen = new Map();
for (let run = 0; run < 20; run++) {
  const r = await Bun.build({ entrypoints: [0, 1, 2].map(e => path.join(d, `e${e}.js`)), splitting: true, metafile: true });
  const order = Object.keys(r.metafile.inputs).map(k => path.basename(k, ".js")).join(" ");
  seen.set(order, (seen.get(order) | 0) + 1);
}
for (const [o, n] of seen) console.log(n + "x", o);
console.log(seen.size === 1 ? "stable" : `UNSTABLE: ${seen.size} different key orders in 20 identical builds`);
fs.rmSync(d, { recursive: true, force: true });

[robobun]

^{Updated 9:09 PM PT - Oct 26th, 2026}

✅ @robobun, your commit 5a2cff7c1d446b38a46fb44f693f9680c6a1eaeb passed in Build #133384! 🎉

---

🧪   To try this PR locally:

bunx bun-pr 36974

That installs a local version of the PR into your bun-36974 executable, so you can run:

bun-36974 --bun

[claude]

Code review completed

Nothing new to post: everything this review found is already covered by existing comments on this pull request or didn't merit a separate one.