bundler: error instead of panic when splitting is used with non-ESM format

[robobun]

What does this PR do?

Fixes #32395.
Fixes #15125.

Reproduction

// shared.ts
export function sharedFn() { return "shared"; }
export const sharedConst = 42;

// a.ts / b.ts both:
import { sharedFn, sharedConst } from "./shared";
export const a = sharedFn() + sharedConst;

$ bun build ./a.ts ./b.ts --outdir ./dist --format cjs --splitting
panic: called `Option::unwrap()` on a `None` value

Same via Bun.build({ entrypoints: ["./a.ts", "./b.ts"], outdir: "./dist", format: "cjs", splitting: true }). --format iife panics identically. --format esm works.

Root cause

CrossChunkImport::sorted_cross_chunk_imports (src/bundler/Chunk.rs:1548) looks up each cross-chunk import in the target chunk's exports_to_other_chunks map:

item.export_alias = (*exports_to_other_chunks.get(&item.r#ref).unwrap()).into();

exports_to_other_chunks is only populated when output_format == Esm (computeCrossChunkDependencies.rs, the match c.options.output_format { Esm => { ... } _ => {} } arm), while imports_from_other_chunks is populated unconditionally earlier in the same function. So when CJS/IIFE + splitting produces a shared chunk, each entry chunk has import items whose refs are looked up in an always-empty map, and None.unwrap() panics.

Fix

The linker has never implemented cross-chunk imports/exports for non-ESM formats (both match output_format arms are _ => {} for CJS/IIFE), so the combination has never produced working output. esbuild rejects it outright:

error: Splitting currently only works with the "esm" format

This PR adds the same validation in BundleV2::init, which both bun build (CLI) and Bun.build (JS API) go through, and which both follow with a log().has_errors() check that converts it into a build failure. The panic becomes a catchable build error:

$ bun build ./a.ts ./b.ts --outdir ./dist --format cjs --splitting
error: Code splitting is currently only supported when format is set to "esm"

try { await Bun.build({ ... }) } catch (e) {
  // AggregateError with errors[0].message = "Code splitting is currently only supported ..."
}

Verification

New tests in test/bundler/esbuild/splitting.test.ts cover cjs and iife on both the cli and api backends (4 cases). On the unfixed build the CLI cases fail with 'bun build' subprocess killed by SIGILL and the API case panics the test process; with the fix all four pass with the expected error message.

• bun bd test test/bundler/esbuild/splitting.test.ts: 26 pass, 2 todo (pre-existing)
• bun bd test test/bundler/bundler_splitting.test.ts: 10 pass
• bun bd test test/bundler/bundler_cjs.test.ts: 23 pass

[robobun]

^{Updated 2:17 AM PT - Jun 25th, 2026}

❌ @robobun, your commit 044b135 has 2 failures in Build #64590 (All Failures):

• test/js/bun/terminal/terminal.test.ts - code 1 on 🍎 14 x64
• test/napi/napi.test.ts - code 1 on 🪟 2019 x64
• test/napi/napi.test.ts - code 1 on 🪟 2019 x64-baseline
• test/napi/napi.test.ts - code 1 on 🪟 11 aarch64

---

🧪   To try this PR locally:

bunx bun-pr 32685

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

bun-32685 --bun

[github-actions]

Found 1 issue this PR may fix:

1. build with splitting for cjs are not imported chunks #15125 - Reports broken output (ReferenceError: Can't find variable: __export) when using --splitting --format cjs, which this PR now rejects with a clear validation error

If this is helpful, copy the block below into the PR description to auto-close this issue on merge.

Fixes #15125

🤖 Generated with Claude Code

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 4e182dea-4c00-4e09-b04d-62b24d25bb03

📥 Commits

Reviewing files that changed from the base of the PR and between 0b2e586 and 044b135.

📒 Files selected for processing (1)

• test/bundler/esbuild/splitting.test.ts

💤 Files with no reviewable changes (1)

• test/bundler/esbuild/splitting.test.ts

---

Walkthrough

Bundle initialization now logs an error when code splitting is enabled without an ES module output format. A regression test covers failed bundling for cjs and iife across cli and api backends and checks the expected error message.

Changes

Code splitting format validation

Layer / File(s)	Summary
Init-time format check src/bundler/bundle_v2.rs	BundleV2::init records an error when code splitting is enabled and the output format is not Esm.
Regression test coverage test/bundler/esbuild/splitting.test.ts	The splitting test iterates cjs and iife across cli and api backends, expects bundling to fail with the code-splitting format error, and adds shared fixture modules for the failing entries.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly matches the main change: rejecting code splitting for non-ESM output formats instead of panicking.
Description check	✅ Passed	The description covers the bug, root cause, fix, and verification, so it is mostly complete despite using different headings.
Linked Issues check	✅ Passed	The validation and tests address both linked issues by cleanly rejecting cjs/iife splitting and preventing the reported crash/broken chunks.
Out of Scope Changes check	✅ Passed	The changes stay within scope: one guard in bundling and targeted regression tests for the unsupported splitting cases.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

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

[claude]

LGTM — straightforward validation that turns a panic into a clean build error, matching esbuild.

Extended reasoning...

Overview

This PR adds a single validation check in BundleV2::init (src/bundler/bundle_v2.rs) that emits a build error when code_splitting is enabled with a non-ESM output_format. Previously this combination would proceed into the linker and panic on a None.unwrap() in sorted_cross_chunk_imports because exports_to_other_chunks is only populated for ESM. The error is logged via transpiler.log_mut().add_error(...), and I verified that all callers of init (both the CLI/normal build path at line ~3791/3929 and the bake-production path at line ~3970) immediately check log().has_errors() and convert it to a BuildFailed error, so the build aborts cleanly without reaching the panic site. Four new test cases in test/bundler/esbuild/splitting.test.ts cover cjs/iife × cli/api and assert the exact error message via bundleErrors.

Security risks

None. This is purely an input-validation guard that rejects an option combination earlier than before. No new I/O, parsing, or privilege-bearing code paths are introduced.

Level of scrutiny

Low. The change is 13 lines of additive Rust (a conditional + log call) and ~30 lines of test code that follow existing patterns in the same file. The combination being rejected never produced working output (it panicked), so there is no risk of regressing existing valid use cases. I checked that code_splitting = true is only set via the user-facing --splitting flag / splitting JS option, so the check cannot accidentally trip for the internal InternalBakeDev format (which doesn't enable code splitting). The error message and behavior mirror esbuild's, which is the reference implementation for this bundler.

Other factors

No CODEOWNERS cover the touched files. No outstanding reviewer comments. The PR description includes a clear root-cause analysis and reports passing test runs for the splitting and CJS bundler suites. The bug-hunting system found no issues.

[claude]

LGTM — small, well-tested validation that turns a panic into a clear build error, matching esbuild.

Extended reasoning...

Overview

This PR adds a 13-line guard in BundleV2::init (src/bundler/bundle_v2.rs) that emits a build error when code_splitting is enabled with any output format other than Esm, plus a 30-line regression test in test/bundler/esbuild/splitting.test.ts covering cjs/iife × cli/api (4 cases). Previously this combination panicked on None.unwrap() in sorted_cross_chunk_imports (or produced broken output per #15125); now it fails cleanly with the same message esbuild uses.

Security risks

None. This is a user-facing config validation in the bundler — no auth, crypto, permissions, injection surface, or data handling involved. The change strictly narrows behavior from panic/garbage-output to a catchable error.

Level of scrutiny

Low. The change is small, mechanical, and self-contained:

• add_error(None, Loc::EMPTY, msg) is an established pattern (e.g. generateChunksInParallel.rs:439).
• Both entry paths check log().has_errors() after init (verified at bundle_v2.rs:3791 and :3929), and the new tests confirm the error surfaces on both CLI and JS API backends.
• Internal callers that set code_splitting = true (bake production, HTMLBundle serve) already use Format::Esm — bake only uses InternalBakeDev in development mode where code_splitting = false — so no internal regression.
• The combination never produced working output, so no functionality is being removed.

Other factors

No CODEOWNERS for src/bundler/. The PR description includes verified test runs (26 pass / 2 pre-existing todo in splitting.test.ts, plus the related bundler_splitting and bundler_cjs suites). The one inline nit (extra bug-history comment line in the test per CLAUDE.md style) is cosmetic and doesn't block approval.

[claude]

LGTM — thanks for dropping the extra comment line.

Extended reasoning...

Overview

This PR adds a single guard in BundleV2::init (src/bundler/bundle_v2.rs) that emits a build error when code_splitting is enabled with any output_format other than Esm, replacing a downstream Option::unwrap() panic in sorted_cross_chunk_imports. It also adds four regression tests in test/bundler/esbuild/splitting.test.ts (cjs/iife × cli/api) asserting the new error message via the existing bundleErrors harness.

Security risks

None. The change is pure input validation on bundler config flags — it adds an early log_mut().add_error(...) call with a static message string. No parsing, no I/O, no auth/crypto/permission surface. The only behavioral change is that an unsupported flag combination now fails cleanly instead of panicking.

Level of scrutiny

Low. The diff is ~13 lines of Rust and ~29 lines of test fixture. I verified:

• add_error flows into the existing has_errors() → BuildFailed checks at bundle_v2.rs:3791/3929/3970, so both CLI and JS API paths surface it as a build failure as described.
• options::Format::Esm matches the enum usage already present a few lines above (line 2784, InternalBakeDev).
• code_splitting = true is only set from the user-facing --splitting flag / splitting JS option — no internal path (e.g. Bake dev server with InternalBakeDev) enables it, so the new guard can't regress internal callers.
• The error wording mirrors esbuild's equivalent rejection.
• Neither changed file is covered by CODEOWNERS.

Other factors

My only prior feedback (drop the bug-history comment line per CLAUDE.md) was addressed in 044b135 and the thread is resolved. The bug-hunting system found no issues on this revision. The PR description includes passing test runs for the touched suite plus adjacent splitting/cjs suites. This is a textbook panic→clean-error conversion with regression coverage on both entry points.

[robobun]

CI on build 64590 finished with 281 jobs passed and 5 failed, none related to this diff:

• darwin-26-aarch64-test-bun: buildkite-agent artifact download timed out after 120s before any tests ran (same agent darwin-aarch64-26-5-1-1, identical failure on build 64586)
• darwin-14-x64-test-bun: test/js/bun/terminal/terminal.test.ts "creates subprocess with terminal attached" timed out after 90s
• windows-{2019-x64, 2019-x64-baseline, 11-aarch64}-test-bun: test/napi/napi.test.ts "Condition was not met after 100 GC attempts" + a Windows line-ending mismatch in napi_is_arraybuffer

The flaky-retry annotations are bun-install, s3-list-objects, webview-chrome, node-http2-upgrade, streams-leak, etc. None touch the bundler; test/bundler/esbuild/splitting.test.ts (including the four new cases) passed on every lane that ran it. Ready for a maintainer retry or merge.