bundler: sort module namespace exports ascending to match spec

[robobun]

Closes #4695

Repro

// leaf.mjs
export const zed = 1; export const Alpha = 2; export const beta = 3;
export default 4; export const _under = 5; export const $dollar = 6;
// entry.mjs
import * as ns from './leaf.mjs';
console.log(Object.keys(ns).join(','));

bun entry.mjs, node entry.mjs, and the esbuild bundle all print $dollar,Alpha,_under,beta,default,zed (Module Namespace Exotic Object [[OwnPropertyKeys]] returns sorted export names).

bun build entry.mjs --target=node printed zed,default,beta,_under,Alpha,$dollar instead.

Cause

sorted_and_filtered_export_aliases in doStep5.rs was built with strings::sort_desc instead of strings::sort_asc. The __export(exports_leaf, {...}) object literal was emitted in reverse-sorted order, so Object.keys() / for..in / JSON.stringify() on the bundled namespace disagreed with the unbundled run.

Fix

One-character direction flip: sort_desc → sort_asc. The __export literal now matches esbuild's output exactly.

Updated the handful of existing bundler tests whose stdout/snapshot encoded the old descending order; the new expected values match what esbuild produces.

Verification

New test importstar/NamespaceOwnKeysSorted asserts Object.keys(ns), Reflect.ownKeys(ns), and an export * re-export chain all enumerate in ascending sorted order. Fails on main (zed,default,beta,_under,Alpha,$dollar), passes with this change.

---

no test proof · iteration 5 · Platform-specific test(s) that do not run on this machine. Deferring to CI, which covers all platforms: test/bundler/bundler_edgecase.test.ts

[coderabbitai]

Warning

Review limit reached

@robobun, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 2 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 5d5e18f9-35bc-45a6-bc88-9962a72ef153

📥 Commits

Reviewing files that changed from the base of the PR and between 44f6469 and e7d75eb.

📒 Files selected for processing (7)

• src/bundler/linker_context/doStep5.rs
• test/bundler/bundler_browser.test.ts
• test/bundler/bundler_cjs.test.ts
• test/bundler/bundler_edgecase.test.ts
• test/bundler/bundler_promiseall_deadcode.test.ts
• test/bundler/esbuild/importstar.test.ts
• test/regression/issue/cyclic-imports-async-bundler.test.js

---

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

[robobun]

^{Updated 12:57 AM PT - Jul 28th, 2026}

✅ @robobun, your commit e7d75eb212a4f447af7c9c7365bca0b983ef1522 passed in Build #83872! 🎉

---

🧪   To try this PR locally:

bunx bun-pr 35957

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

bun-35957 --bun

[claude]

LGTM — one-word direction flip aligns bundled namespace key order with the spec and esbuild.

What was reviewed:

• Verified all consumers of sorted_and_filtered_export_aliases (postProcessJSChunk, computeCrossChunkDependencies, MetafileBuilder, scanImportsAndExports) are order-agnostic or benefit from ascending.
• Confirmed the cjs_export_copies[i] positional correspondence in postProcessJSChunk is preserved — both arrays are built from the same post-sort list.
• Checked no other __export(...) snapshots or metafile-exports assertions in the suite encode multi-key descending order beyond the ones updated here.

Extended reasoning...

Overview

Single-line change in src/bundler/linker_context/doStep5.rs: strings::sort_desc → strings::sort_asc on the export-alias list that drives the __export(exports_foo, {...}) object literal. Five test files updated to reflect the new (spec-correct) ascending key order, plus one new itBundled test asserting Object.keys/Reflect.ownKeys/re-export-chain enumeration matches the ECMA-262 Module Namespace [[OwnPropertyKeys]] ordering.

Security risks

None. Pure output-ordering change in the bundler; no untrusted input parsing, no memory-layout changes, no FFI/syscall paths touched.

Level of scrutiny

Low-to-medium. The native change is trivially local (a comparator direction), but I traced every consumer of sorted_and_filtered_export_aliases to confirm none depends on descending order:

• postProcessJSChunk.rs:1024 iterates and indexes cjs_export_copies[i] — that array is built at scanImportsAndExports.rs:623 by zipping over the already-sorted alias list, so the positional pairing is preserved regardless of direction.
• computeCrossChunkDependencies.rs and MetafileBuilder.rs just iterate; ascending is fine (metafile output improves — now matches esbuild).
• create_exports_for_file in doStep5 itself iterates to build the __export literal — this is exactly the emission the fix targets.

I also grepped the test tree for other __export(exports_...) snapshots and metafile "exports": [...] assertions with ≥2 keys; the only affected ones are already updated in this PR (the bun-build-api.test.ts.snap hits are single-key so unaffected).

Other factors

• The updated test expectations are the correct new values (ascending byte-order: $ < uppercase < _ < lowercase), matching what Node/esbuild/unbundled Bun produce.
• The new NamespaceOwnKeysSorted test covers a good input span ($, _, uppercase, lowercase, default, re-export chain) and would fail on main.
• The debugId hash changes in the inline snapshots are the expected consequence of the byte-for-byte output change.

[claude]

LGTM — one-token direction fix (sort_desc → sort_asc) aligning bundled namespace key order with the spec and esbuild.

What was reviewed:

• Confirmed strings::sort_asc is the ascending sibling of the removed sort_desc.
• Checked all consumers of sorted_and_filtered_export_aliases (postProcessJSChunk, computeCrossChunkDependencies, MetafileBuilder, create_exports_for_file) — none depend on descending order; they only affect emitted key order.
• Grepped for other __export(...) snapshots that might encode the old order — only bun-build-api.test.ts.snap matched and its three occurrences are single-key, so unaffected.
• Spot-checked the large NodePolyfills stdout: per-module keys reversed to ascending; the stream: block correctly unchanged (runtime-assigned properties, not __export).

Extended reasoning...

Overview

Single functional line changed in src/bundler/linker_context/doStep5.rs: strings::sort_desc → strings::sort_asc on the export-alias slice that becomes sorted_and_filtered_export_aliases. The remaining six files are test-expectation updates flipping key order from descending to ascending, plus one new itBundled test in importstar.test.ts that directly asserts Object.keys(ns) / Reflect.ownKeys(ns) and an export * chain enumerate in ascending order. Three inline-snapshot debugId hashes changed as a byproduct of the byte-level output diff.

Security risks

None. Pure output-ordering change in the bundler's namespace-export emission; no parsing of untrusted input, no allocation/bounds logic touched.

Level of scrutiny

Low-medium. The native change is a one-token flip between two sibling helpers whose implementations I confirmed (order(a,b) vs order(b,a)). I audited every reader of sorted_and_filtered_export_aliases — postProcessJSChunk (emits export {...} / __export({...})), computeCrossChunkDependencies (walks aliases to mark refs), MetafileBuilder (writes exports JSON array), and create_exports_for_file in the same file. All iterate the slice without any order-dependent logic; the order only surfaces in emitted artifacts, where ascending is the spec-mandated / esbuild-matching direction.

Other factors

• Verified no other sort_desc call sites remain in src/bundler/.
• Grepped test snapshots for multi-key __export literals that might have been missed — none found beyond what the PR already updated.
• The new NamespaceOwnKeysSorted test exercises $, _, uppercase, lowercase, default, and an export * merge — good coverage of the bytewise sort the spec requires.
• The huge bundler_browser.test.ts stdout string is the mechanical reversal of each namespace's key list; the stream: block is correctly left untouched since those properties are assigned at runtime rather than via __export.

[robobun]

All test lanes pass on build #82554. The only red job is binary-size, which is comparing against the stale canary baseline (main #79916) and is currently failing the same way on unrelated concurrent PR builds (#82546, #82549, #82551, #82552). The source change here swaps one existing 3-line sort helper for its sibling; both are already linked into the binary, so there is no size impact from this diff.

[claude]

LGTM — one-token direction flip (sort_desc → sort_asc) that aligns bundled namespace key order with the spec, esbuild, Node, and unbundled Bun.

What was reviewed:

• Verified strings::sort_asc is the byte-wise ascending sibling of the previous sort_desc (immutable.rs:1881).
• Audited every consumer of sorted_and_filtered_export_aliases (postProcessJSChunk, computeCrossChunkDependencies, MetafileBuilder, scanImportsAndExports) — none depend on descending order; cjs_export_copies stays index-aligned because it's built by iterating the same already-sorted array.
• Spot-checked the reordered test expectations (NodePolyfills, cjs, edgecase, importstar, snapshots) — same key sets, ascending byte order; the export * chain test correctly omits default.

Extended reasoning...

Overview

Single source-line change in src/bundler/linker_context/doStep5.rs:166: strings::sort_desc → strings::sort_asc on the export-alias list that feeds the __export(exports, {...}) object literal. The rest of the diff is mechanical test-expectation updates (reversing key order in stdout/snapshot strings, plus three regenerated debugId hashes) and three new itBundled cases in importstar.test.ts covering Object.keys/Reflect.ownKeys, export * re-export chains, export * as ns, and CJS-format entry-point exports.

Security risks

None. Pure output-ordering change in the bundler; no user-input parsing, allocation sizing, or trust boundary is touched.

Level of scrutiny

Low-to-medium. The runtime change is trivially inspectable — sort_asc and sort_desc are 3-line siblings differing only in comparator argument order (order(a,b) vs order(b,a), where order is a.cmp(b)). The interesting question is whether any downstream consumer of sorted_and_filtered_export_aliases depended on descending order. I checked all five consumers: create_exports_for_file (same file) iterates in order to emit properties; postProcessJSChunk.rs:1024 pairs each alias with cjs_export_copies[i], but that array is populated in scanImportsAndExports.rs:623 by zipping over the same sorted array after step 5 runs, so index alignment holds regardless of direction; computeCrossChunkDependencies.rs and MetafileBuilder.rs just enumerate. Nothing assumes descending.

The new order matches esbuild's sort.Strings(aliases) (byte-wise ascending) and the ECMA-262 Module Namespace [[OwnPropertyKeys]] requirement. The byte-wise-vs-UTF-16-code-unit edge case for non-BMP export aliases is pre-existing esbuild-parity behavior, not introduced here.

Other factors

• CI: robobun reports all test lanes green on build #82554; the only red job is the known-stale binary-size baseline, unrelated to this diff.
• New tests are well-designed: NamespaceOwnKeysSorted exercises $, uppercase, _, lowercase, default, and an export * chain (which correctly drops default); CjsEntryPointExportsSorted covers the format: cjs path that goes through postProcessJSChunk.
• The large bundler_browser.test.ts stdout blob is a pure key reorder; I verified the assert and buffer sections and confirmed the stream section (a Function with insertion-order own properties, not a __export namespace) is correctly left untouched.