bundler: chain inline input sourcemaps through to output - #30539
bundler: chain inline input sourcemaps through to output#30539robobun wants to merge 29 commits into
Conversation
|
Found 1 issue this PR may fix:
🤖 Generated with Claude Code |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughParses trailing inline data:application/json ChangesInline sourcemap chaining
🚥 Pre-merge checks | ✅ 3 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (3 passed)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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/bundle_v2.zig`:
- Around line 3675-3677: The assignment to
graph.input_files.items(.input_source_map)[result.source.index.get()] =
result.input_source_map leaks the previous ParsedSourceMap and can leak the
freshly parsed map on early failure; before overwriting the graph slot,
deinit/free the existing map (if any) stored in
graph.input_files.items(.input_source_map)[...], then move
result.input_source_map into that slot, and ensure you null out or mark
result.input_source_map as moved; additionally add matching cleanup in the error
path around runResolutionForParseTask() so that if result transitions from
.success to .err the newly allocated ParsedSourceMap and its sourcesContent are
deallocated (use defer or explicit deinit in the same scope where
result.input_source_map is allocated) to avoid leaks.
In `@src/bundler/ParseTask.zig`:
- Around line 1320-1325: The inline source-map parsing currently runs for
plugin/virtual sources too; update the conditional that computes
input_source_map (the if using transpiler.options.source_map,
loader.canHaveSourceMap(), and source.contents) to also require that the input
is file-backed by checking source.path.isFile() (or that source.path.namespace
== "file") so only file-backed inputs attempt
bun.SourceMap.InputSourceMap.parseFromSource; leave the other checks
(transpiler.options.source_map and loader.canHaveSourceMap and non-empty
source.contents) intact.
In `@src/sourcemap/InputSourceMap.zig`:
- Around line 37-145: The parse function currently treats allocator failures
(e.g., at allocator.alloc, allocator.dupe, and similar catch sites such as
source_paths_slice, sources_content_slice, and the dupes inside the loops) as
generic parse failures by using `catch return null`; update each such `catch` to
inspect the error and call `bun.handleOom()` for `error.OutOfMemory` and
otherwise `return null` — e.g. replace `... catch return null` with `... catch
|err| if (err == error.OutOfMemory) bun.handleOom() else return null` at every
allocation/dupe site in InputSourceMap.parse (including the other occurrences
around lines ~203-209) so OOMs trigger Bun’s fatal path while preserving null
for real decode/validation failures.
🪄 Autofix (Beta)
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: 3d64f326-1bc4-4bfb-98df-db68570a30e3
📒 Files selected for processing (9)
src/bundler/Graph.zigsrc/bundler/LinkerContext.zigsrc/bundler/ParseTask.zigsrc/bundler/bundle_v2.zigsrc/js_printer/js_printer.zigsrc/sourcemap/Chunk.zigsrc/sourcemap/InputSourceMap.zigsrc/sourcemap/sourcemap.zigtest/bundler/bun-build-api.test.ts
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
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 `@test/bundler/bun-build-api.test.ts`:
- Around line 1297-1299: The test decodes base64 sourcemap payloads using m![1]
without checking that the regex match succeeded; add an explicit guard before
decoding at each occurrence (the variable m in the bun-build-api.test cases) —
e.g., assert expect(m).toBeTruthy() or if (!m) fail with a clear message, then
use m[1] to Base64-decode and JSON.parse; apply the same fix to all four
locations where m![1] is used (the matches at lines matching the
sourceMappingURL extraction).
🪄 Autofix (Beta)
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: 0d06802d-137b-46ff-afe3-f7d3c764486e
📒 Files selected for processing (1)
test/bundler/bun-build-api.test.ts
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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/sourcemap/InputSourceMap.zig`:
- Around line 197-212: The current findSourceMappingURL searches the whole file
for "\n//# sourceMappingURL=" which can miss a trailing inline comment or match
markers inside later content; change it to first trim trailing whitespace from
source, compute the start of the final line (use std.mem.lastIndexOfScalar to
find the last '\n' or 0), then only search for the needle inside that final-line
slice (e.g. search source[lineStart..] for "//# sourceMappingURL="). If found,
compute start/end relative to the original buffer and return the trimmed URL as
before; otherwise return null. Ensure you update uses of needle, found, start,
end and keep using bun.strings.trim for trimming.
- Around line 79-81: The parser currently treats the "version" field as
optional; in InputSourceMap.zig change the logic that handles
json.get("version") so that absence returns error.InvalidSourceMap and presence
is still validated (i.e., ensure version.data is .e_number and
version.data.e_number.value == 3.0); locate the block referencing
json.get("version") and replace the optional branch with an explicit existence
check that errors when missing and otherwise performs the same type/value
validation.
In `@test/bundler/bun-build-api.test.ts`:
- Around line 1357-1361: The test currently only asserts an inline source map
exists by checking text for "sourceMappingURL=data:...base64"; update the
assertion to decode and validate the actual fallback source used in the
malformed-map case: extract the base64 payload from the data URL in the variable
text (from Bun.file(result.outputs[0].path).text()), base64-decode and
JSON.parse it, then assert that the parsed source map's sources or
sourcesContent includes the expected intermediate/fallback source (e.g., the
intermediate filename or its source text) so the mapping truly targets the
documented fallback source instead of just existing.
🪄 Autofix (Beta)
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: 292ecd2b-9daf-426c-9bc5-9fd0149be05d
📒 Files selected for processing (3)
src/bundler/bundle_v2.zigsrc/sourcemap/InputSourceMap.zigtest/bundler/bun-build-api.test.ts
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
src/sourcemap/InputSourceMap.zig (1)
214-219:⚠️ Potential issue | 🟠 Major | ⚡ Quick winMatch trailing inline sourcemaps after code on the final line.
This only accepts a comment-only last line. Valid one-line outputs like
code;//# sourceMappingURL=data:...still returnnull, so chaining is skipped for minified/plugin-generated intermediates.Suggested fix
- const needle = "//# sourceMappingURL="; - if (!bun.strings.hasPrefixComptime(last_line, needle)) return null; - return bun.strings.trim(last_line[needle.len..], " \r\t"); + const needle = "//# sourceMappingURL="; + const found = std.mem.lastIndexOf(u8, last_line, needle) orelse return null; + return bun.strings.trim(last_line[found + needle.len ..], " \r\t");🤖 Prompt for 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. In `@src/sourcemap/InputSourceMap.zig` around lines 214 - 219, The current logic in InputSourceMap.zig only accepts a sourceMappingURL if the final line starts with the needle, so cases like "code;//# sourceMappingURL=..." are missed; update the check to search for needle anywhere in last_line (use a substring/index search instead of hasPrefixComptime) and, when found, slice last_line at the found index (needle.len after the index) and then trim that substring before returning; reference the existing variables last_line_start, last_line, and needle to locate and replace the prefix-only hasPrefixComptime logic with an index-based search (e.g., std.mem.indexOf or similar) and handle the not-found case by returning null.
🤖 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/LinkerContext.zig`:
- Around line 744-755: The code currently only sets path.pretty for file-backed
inputs (in the branch checking path.isFile()) but always serializes path.pretty,
which loses non-file/virtual/plugin module names; update the serialization so
that when path.isFile() is false you use outer_path.text (or set path.pretty =
outer_path.text beforehand) before calling js_printer.quoteForJSON and pushing
to joiner (symbols: outer_path, path, path.isFile(), path.pretty,
js_printer.quoteForJSON, joiner, MutableString.init, leading_comma) so
plugin/virtual module source names are preserved in emitted sources[].
In `@test/bundler/bun-build-api.test.ts`:
- Around line 1250-1253: The test currently grabs the first sourceMappingURL
match from the file (via text.match and m) which can pick up in-body markers;
change the extraction to target only the final inline sourcemap line by either
using a regex anchored to the end of the string (e.g. match the sourceMappingURL
line followed by optional whitespace to string end with the /m flag) or by
finding all matches and using the last one before base64 decoding; update the
occurrences that use Bun.file(...).text(), text.match(...), m and parsed at the
noted spots (including the other listed locations) to use this trailing-line
approach so the parsed JSON always comes from the final inline sourcemap.
---
Duplicate comments:
In `@src/sourcemap/InputSourceMap.zig`:
- Around line 214-219: The current logic in InputSourceMap.zig only accepts a
sourceMappingURL if the final line starts with the needle, so cases like
"code;//# sourceMappingURL=..." are missed; update the check to search for
needle anywhere in last_line (use a substring/index search instead of
hasPrefixComptime) and, when found, slice last_line at the found index
(needle.len after the index) and then trim that substring before returning;
reference the existing variables last_line_start, last_line, and needle to
locate and replace the prefix-only hasPrefixComptime logic with an index-based
search (e.g., std.mem.indexOf or similar) and handle the not-found case by
returning null.
🪄 Autofix (Beta)
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: 7927bb9d-82d1-4fb6-a98a-185ceb0904d3
📒 Files selected for processing (4)
src/bundler/LinkerContext.zigsrc/bundler/ParseTask.zigsrc/sourcemap/InputSourceMap.zigtest/bundler/bun-build-api.test.ts
c4223fc to
03f82da
Compare
06c646d to
528da29
Compare
There was a problem hiding this comment.
No new issues found, but this is a substantial bundler feature (~1k lines across parse/link/print + a new sourcemap parser handling untrusted input) with non-trivial slot-index arithmetic and ownership threading, plus an unrelated build-script change — worth a human pass before merge, and CI is still red on aarch64-musl build-rust.
Extended reasoning...
Overview
This PR threads inline //# sourceMappingURL=data:... input sourcemaps through Bun.build's output map. It adds a new parser module (InputSourceMap.{zig,rs}, ~270 lines each), a new SoA column on Graph::InputFile, ownership transfer in ParseTask/bundle_v2, per-mapping remapping in Chunk::Builder, and per-source slot expansion + chunk-stitching index arithmetic in LinkerContext::generate_source_map_for_chunk. 8 new tests in bun-build-api.test.ts. There's also an unrelated scripts/build/bun.ts change adding an order-only ninja dep to serialize strip against the smoke test.
Security risks
The new parser ingests untrusted bytes (any data: URL embedded in any bundled .js, including plugin onLoad returns). Failure modes are designed to fall back to None (silent no-chain), and earlier review rounds caught and fixed the source-index-aliasing case (out-of-range VLQ indices now hit .fail via the real sources_count). I don't see injection or auth surface, but the slot-expansion arithmetic in LinkerContext (base + chunk.end_state.source_index) and the dev-server gate are exactly the kind of subtle index bookkeeping that benefits from a second pair of eyes.
Level of scrutiny
High. This is production-critical bundler output (sourcemaps affect every debugging/error-reporting workflow), the change spans 19 files in two languages, and it carries several design decisions a maintainer should sign off on: keeping the intermediate as slot 0 alongside inner sources (vs. replacing it), gating the entire feature off for the Bake DevServer path, and deferring sourceRoot / external-.map / plugin-namespace path normalization to follow-ups.
Other factors
The PR went through several automated review rounds; all prior inline findings (dead errdefers, leak on Success→err overwrite, dev-server corruption, ban-words, port-fidelity trim) are marked resolved. The Rust port landed in 30171d1 and the tests are now active (not .todo). However, the most recent CI status (Build #56048, commit 528da29) still shows build-rust failing on aarch64-musl, and the scripts/build/bun.ts change is acknowledged as out-of-scope for the headline feature.
c74b504 to
e21f069
Compare
There was a problem hiding this comment.
No issues found on this pass, but this is a substantial feature touching the bundler's sourcemap stitching across both the Zig reference and the Rust port (new InputSourceMap module, per-chunk source_index offset arithmetic in LinkerContext/Chunk, ownership threading through Graph/ParseTask/bundle_v2, plus an unsafe 'static lifetime erasure in get_source_map_builder) — worth a human pass on the index-stitching math and the Rust lifecycle before merge.
Extended reasoning...
Overview
This PR adds inline-input-sourcemap chaining to Bun.build: a new ~270-line InputSourceMap module (both .zig reference and .rs port) plus threading through Graph/ParseTask/bundle_v2/LinkerContext/Chunk/js_printer so that a trailing //# sourceMappingURL=data:... on an input file expands the output map's sources[]/sourcesContent[] and remaps VLQ mappings through the inner map. It also bundles an unrelated scripts/build/bun.ts ninja order-only-dep fix and 8 new tests in bun-build-api.test.ts.
Security risks
Low. The new parser ingests untrusted inline sourcemap payloads from input files / plugin returns, but malformed input falls through to None/null (silent fallback), OOM goes through handle_oom/bun.outOfMemory, and the out-of-range source_index aliasing concern was fixed by passing the real sources_count to Mapping.parse. No auth, crypto, network, or filesystem-write surface.
Level of scrutiny
High. This is core bundler output-correctness code: the per-chunk source_index expansion and the prev_end_state.source_index = mapping_source_index + chunk.end_state.source_index stitching in generateSourceMapForChunk are subtle — an off-by-one silently corrupts sourcemaps for every downstream user. The Rust port also includes an unsafe { &*(r as *const _) } lifetime erasure to 'static in get_source_map_builder, manual MultiArrayList column draining in deinit_without_freeing_arena, and a Stacked-Borrows-sensitive hoist in ParseTask.rs. The PR went through ~15 inline fixes over the week (dead errdefer, leak paths, DevServer gating, ban-words, E0063, UB), which speaks to its complexity.
Other factors
All prior inline comments (mine and CodeRabbit's) are resolved. Test coverage is good (8 targeted cases including malformed/edge inputs). However, several design decisions were explicitly deferred to follow-ups (DevServer slot expansion, sourceRoot, version strictness, external .map resolution, path.pretty for non-file namespaces), and the unrelated build-script change is bundled in. Given the cross-cutting scope and the index-arithmetic subtlety, a human reviewer should sign off on the stitching math and the Rust ownership/lifetime story.
8e56af7 to
f0a63f6
Compare
There was a problem hiding this comment.
No new issues found, but this is a substantial feature touching bundler-core sourcemap stitching (slot-expansion index arithmetic in LinkerContext, per-token remapping in Chunk::Builder) plus an unsafe lifetime transmute in js_printer — worth a human pass before merge.
Extended reasoning...
Overview
This PR threads inline //# sourceMappingURL=data:... comments on bundler input files through to the output sourcemap, so authored sources (.vue/.svelte/.ts) surface in the final map instead of the intermediate .js. It adds a new ~270-line InputSourceMap module (both .rs and reference .zig), plumbs an input_source_map column through Graph::InputFile / ParseTask::Success / bundle_v2, adds remapping logic to Chunk::Builder::add_source_mapping, rewrites the sources[]/sourcesContent[] emission and chunk-stitching arithmetic in LinkerContext::generate_source_map_for_chunk, and adds a new input_source_map field to js_printer::Options with an unsafe transmute to erase its lifetime to 'static. It also carries an unrelated scripts/build/bun.ts fix (order-only ninja dep so the smoke test doesn't race strip). 19 files changed; 8 new tests in bun-build-api.test.ts.
Security risks
None apparent. The new code parses untrusted inline sourcemap JSON/base64 from input files, but malformed input falls back to None (no chain) rather than erroring; out-of-range VLQ source indices are bounded by sources_count so they can't alias neighboring slots; the URL scanner is anchored to the last line so in-body markers can't hijack. No filesystem reads of external .map files (explicitly out of scope). The unsafe transmute extends a borrow lifetime, not raw memory access.
Level of scrutiny
High. This is production bundler-core code that affects every Bun.build with sourcemap != none. The slot-expansion arithmetic (base + chunk.end_state.source_index, 1 + inner.source_index, expansion counts) is delicate — the review history shows it was wrong in multiple subtle ways (DevServer corruption, out-of-range aliasing, hint-coordinate-space mismatch) before being fixed. The unsafe lifetime erasure in js_printer/lib.rs:7995-8013 deserves a human eye on whether the SAFETY comment's invariant (graph slot outlives every add_source_mapping call) actually holds across all printer entry points. The DevServer gate (self.dev_server.is_none()) is a deliberate feature scope-down that a maintainer should sign off on.
Other factors
The PR went through ~10 rounds of bug fixes during review (dead-errdefer leaks, stacked-borrows UB, E0063 build break, ban-words violation, slot-overwrite leaks, DevServer corruption gate, hint-poisoning perf regression) — all now resolved, which speaks well of the final state but also confirms this is not mechanical code. All prior inline comments (mine and CodeRabbit's) are resolved. The unrelated scripts/build/bun.ts change is small and well-commented but bundling it here is a scope question for the maintainer. Test coverage is good (8 targeted cases including malformed/edge inputs).
|
CI on |
|
CI status after the rebase (head 8020783, build #61103): every test lane fails on exactly one test, |
3e0f8bb to
8020783
Compare
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
|
On the comment-lint findings: commit 7d009dd trims the explanatory comments across all flagged files to their load-bearing core, a net -116 comment lines. What remains is short (2-4 lines) and documents cross-file invariants a reviewer cannot recover from any single file: the sources[] slot layout shared by Chunk::Builder and LinkerContext, the chunk-relative vs absolute source_index stitching, the intermediate-vs-authored coordinate space for the line-table hint, the DevServer gating, the slab-only SoA drop requiring an explicit drain, and the adversarial-input caps. None of these annotate workarounds; they describe the contract between files, so I'm keeping them rather than trimming further. I'll mark the open lint threads resolved accordingly. |
3249a95 to
27ec2ea
Compare
…es through The DevServer stitcher never consumes the parsed map, so the per-reparse scan was dead work on the HMR path. URL-schemed inner sources[] entries (webpack:///...) must not be path-joined; emit them verbatim per spec.
A plugin onResolve custom-namespace path has no on-disk directory, so joining inner names against dirname(text) produced bogus labels.
| // A non-file intermediate (plugin virtual module) has no directory | ||
| // to resolve against; emit inner names verbatim. |
There was a problem hiding this comment.
If you need a paragraph-long comment to justify why the workaround is OK, the code is wrong — fix the code
|
CI on 2d79d79 (build #97866, now complete) has zero test failures: 176 jobs passed, including every lane that runs the bun-build-inline-sourcemap-chain suite (11 tests). The only non-green entries are infrastructure: the windows x64 verify-baseline step was canceled (no exit code, never failed), and the two darwin 14 aarch64 test-bun jobs expired waiting for an agent, the same darwin agent scarcity this PR has hit before. I've already used my one retrigger on this branch, so re-running those two darwin jobs (or merging past a lone agent-expiry) is a maintainer call. All review findings are addressed or explicitly deferred with the reviewer's agreement, and all review threads are resolved. |
1 participant
Closes #30536.
Also fixes #6173 — plugin
onLoadreturns with an inline sourcemap are fed through the same scanner, so the plugin case rides on the same pipeline.Summary
When
Bun.build({ sourcemap: 'inline' })bundles an input.jsfile that carries an inline//# sourceMappingURL=data:application/json;base64,…comment (e.g..vue/.sveltecompilers emitting an intermediate.jswith a chain back to the authored.ts/.vue), the final output's sourcemap chain now resolves through to the authored source. Before this change the deepestsources[]entry was the intermediate.js; after, it's the authored source, andsourcesContent[]holds the clean authored bytes without the trailing comment. Same fix coversonLoadplugin returns (#6173) because the scanner runs onsource.contentsregardless of where they came from.Repro
Before:
sources = ["../inner.js", "../entry.ts"].sourcesContent[0]is the rawinner.jsbytes including the literal//# sourceMappingURL=…comment. Chain stops at the intermediate.After:
sources = ["../inner.js", "../inner.ts", "../entry.ts"].sourcesContent[1]is the cleaninner.ts, no embedded comment. Mappings that live in the intermediate resolve through to the authored line/column.Cause
The lexer already detects
//# sourceMappingURL=but nothing reads it back — the bundler's linker emits the output map directly fromsource.contents+ the intermediate's path, discarding any chain.Fix
Thread the inline map end-to-end:
src/sourcemap/InputSourceMap.rs(new, ~220 lines): owns the parsed innerParsedSourceMap+ per-source contents.parse_from_sourcescans for a trailing//# sourceMappingURL=data:...anchored on the last line (Source Map spec — in-body markers in template literals must not hijack the lookup). Supports both;base64,and rawdata:application/json,...payloads. Malformed input →None(silent fallback); OOM propagates viahandle_oom.src/bundler/ParseTask.rs: after parsing JS, scan the source bytes. Gated onsource_map != .None && loader.can_have_source_map() && !source.contents.is_empty()so no-sourcemap builds pay nothing; external.mapreferences are out of scope. The scan runs onsource.contentsregardless of where the contents came from (file read or pluginonLoadreturn), so this also covers the plugin case from Support sourcemaps inonLoadplugins #6173.src/bundler/Graph.rs,bundle_v2.rs: newInputFile.input_source_map: Option<Box<InputSourceMap>>column; ownership moves from the parse result onto the file and drains indeinit_without_freeing_arena(MultiArrayList'sDropis slab-only).src/sourcemap/Chunk.rs+src/js_printer/lib.rs:Builder+Optionsgrow an optionalinput_source_map. Inadd_source_mapping, the(line, col)we'd have emitted against the intermediate is translated viamap.find_mapping:source_index = 1 + inner.source_index, inner(line, col)src/bundler/LinkerContext.rs: each outer source insources[]expands to[intermediate, inner_0 … inner_N-1]andsourcesContent[]matches slot-for-slot. Chunk stitching usesbase + chunk.end_state.source_indexas the absolute end so per-chunk mappings whosesource_indexvaries across their length compose correctly. Gated onself.dev_server.is_none()because Bake'sSourceMapStore::join_vlqstitcher hard-codes onesources[]slot per file and would corrupt on expansion.Malformed or unrecognized inline maps fall back cleanly — the build still succeeds with the pre-fix behavior (tested).
Verification
bun bd test test/bundler/bun-build-api.test.ts→ 53 pass / 0 fail (8 new + 45 existing). 8 new cases underdescribe("Bun.build chains inline input sourcemaps", …):data:URL — authored source surfaces in bundled mapdata:application/json,…URL — authored source surfaces.vue?script+?template) — all surfacesource_index >= sources.len— rejected, no slot aliasing//# sourceMappingURL=marker inside a template literal (but no trailing comment) — ignored, no hijack.mapfilename reference (non-data:) — unchanged behavioronLoadreturn carrying inline map — regression guard for Support sourcemaps inonLoadplugins #6173Also ran the full
bun-build-api.test.tsand adjacent bundler suites — no regressions.Build script fix
scripts/build/bun.tsgets a small fix unrelated to the bundler but triggered by this PR's larger release-mode build: addedstrippedExeas anorderOnlyInputsninja dep for the release smoke-test rule, so the test doesn't race thestrip bunstep. Without this, the gate hit an intermittentPermission deniedonbuild/release/bunduring the smoke test.Rebase notes (latest)
Rebased across ~1250 commits of main. Three substantive adaptations:
emitPostLinkcentralizes the strip-before-smoke-test invariant, crediting bundler: chain inline input sourcemaps through to output #30539), so that commit was dropped and the PR no longer touchesscripts/build/bun.ts.unsafelifetime erasure injs_printeris gone: main parameterizedChunk::Builderover a lifetime, soinput_source_mapis now a plainOption<&'a InputSourceMap>borrow with no transmute.EObjectJSON/EArrayJSONrows) and mademapping::parsereturn aResult;InputSourceMap::parse_internalnow readsversion/mappings/sources/sourcesContentthrough the tape accessors (ObjectJSON::get,JsonValue::as_str/as_array). Without this the container lookups silently failed and no chaining occurred.Verified after the rebase: all 9 chain tests pass, and the 9 sourcemap tests in
bun-build-api.test.ts(including main's new C0-control-chars and non-ASCII-columns cases) pass.