composeSourceMaps: Encode the composed map directly

[robhogan]

Context

composeSourceMaps built its output with source-map's SourceMapGenerator, which allocates and validates an object per mapping and serialises by string concatenation:

metro/packages/metro-source-map/src/composeSourceMaps.js

Lines 44 to 56 in b7c2055

	const generator = new SourceMapGenerator({
	file: consumers[0].file,
	});
	consumers[0].eachMapping(mapping => {
	const original = findOriginalPosition(
	consumers,
	mapping.generatedLine,
	mapping.generatedColumn,
	);
	generator.addMapping({
	generated: {
	line: mapping.generatedLine,

On a large map that was most of the remaining time.

This change

This collects the composed mappings into parallel arrays and encodes them with Metro's own B64Builder. Output is unchanged, including source and name ordering, de-duplication, sorting and the error for an invalid mapping.

That puts Metro's composer level with Expo's @jridgewell/remapping-based one (~680ms on the same input), with more faithful output. It's the point of this stack: it makes the case for Expo's Hermes export path using Metro's composer rather than its own.

composeSourceMaps is 20.6% faster than #1981 (95% CI 19.7-21.2%) and 3.25x faster than main (2,088ms -> 646ms on our benchmark app), with byte-identical output and no change in memory.

Benchmark

AI-driven.

	Time (median)	vs previous	vs main	Composition memory	vs previous	vs main	Peak RSS
main	2,088ms (2,082 to 2,094)			1,070MB (1,070 to 1,070)			1,664MB
#1981	805ms (802 to 811)		-61.4% (-61.6 to -61.1)	911MB (910 to 912)		-14.9% (-15.0 to -14.7)	1,505MB
This PR	646ms (641 to 650)	-20.6% (-21.2 to -19.7)	-69.2% (-69.3 to -69.0)	914MB (907 to 915)	0.0% (-0.4 to +0.3)	-14.8% (-15.2 to -14.6)	1,508MB

Changelog

 - **[Performance]**: `composeSourceMaps` encodes its output directly rather than through `source-map`

Test plan

Compared against #1981 on 40,000 randomly generated compositions of one to three maps, including repeated and out-of-order mappings, names, unmapped positions and invalid mappings. Every output and every error message is identical.

Benchmark (AI-driven): Mattermost Mobile 2.45.0 (React Native 0.83.9, Metro 0.83.7), iOS release bundle, unminified: 7,086 sources, 52.6MB bundle, 82.4MB flat source map. Composed with its hermesc -O -output-source-map map (hermes-compiler 0.14.1, 10.7MB, 1.84M segments). Timings are composeSourceMaps alone, excluding JSON parsing, over 105 rounds on Node 22.13.1 on an M5 Pro. Each round runs main, every PR in this stack and a memory baseline, in a shuffled order. Figures are medians with 95% bootstrap confidence intervals, for changes of the per-round paired ratio. Composition memory is peak RSS less that of the same process parsing both maps without composing them (594MB).

[Copilot]

Copilot review overview

🟡 Changes recommended

The reviewed implementation has unresolved correctness issues, including a critical mapping truncation bug.

Review effort: Lite
Findings: 1 · 1

Open (2)

• Large line gaps truncate generated source-map mappings · New
• Rejects valid source-map mappings with empty source · New

What changed in this PR

Optimizes composeSourceMaps by encoding maps directly with Metro’s B64Builder.

Changes:

• Collects mappings in parallel arrays.
• Sorts, deduplicates, and encodes mappings directly.
• Preserves source-map metadata and ordering.

File	Summary
packages/​metro-source-map/​src/​composeSourceMaps.js	Direct encoding implementation. Findings include one critical line-gap truncation issue and two moderate correctness issues involving empty sources and null sorting.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.