runtime: one module record for a .json imported with and without the type attribute - #35914
Open
robobun wants to merge 6 commits into
Open
runtime: one module record for a .json imported with and without the type attribute#35914robobun wants to merge 6 commits into
robobun wants to merge 6 commits into
Claude / Claude Code Review
completed
Jul 26, 2026 in 27m 58s
Code review found 2 important issues
Found 4 candidates, confirmed 4. See review comments for details.
Details
| Severity | Count |
|---|---|
| 🔴 Important | 2 |
| 🟡 Nit | 2 |
| 🟣 Pre-existing | 0 |
| Severity | File:Line | Issue |
|---|---|---|
| 🔴 Important | src/js_printer/lib.rs:6011-6012 |
RuntimeTranspilerCache EXPECTED_VERSION not bumped |
| 🔴 Important | src/js_printer/lib.rs:6199-6216 |
Synthesized type:"json" defeats ?raw on .json specifiers |
| 🟡 Nit | src/js_printer/lib.rs:6204-6208 |
Leading '#' truncation misses subpath-import .json specifiers |
Annotations
Check failure on line 6012 in src/js_printer/lib.rs
claude / Claude Code Review
RuntimeTranspilerCache EXPECTED_VERSION not bumped
This changes bun-target printer output (adds `with { type: "json" }`) and the serialized `esm_record` (`FetchParameters::None` → `Json`) for attribute-less `.json` import records — both persisted in `.pile` entries — but `EXPECTED_VERSION` in `src/jsc/RuntimeTranspilerCache.rs:46` is still `23`. A warm-cache importer ≥4 KB written by a pre-PR Bun will hit unchanged and serve the old un-attributed output + `FP::None`, silently reinstating the identity fork this PR fixes; bump to `24` with a one-l
Check failure on line 6216 in src/js_printer/lib.rs
claude / Claude Code Review
Synthesized type:"json" defeats ?raw on .json specifiers
`record_implies_json_type()` strips `?`/`#` before the `.json` suffix check, so `import a from "./cfg.json?raw"` now gets a synthesized `with { type: "json" }` — and at fetch time the type attribute unconditionally overrides the `?raw` loader (jsc_hooks.rs:4034-4041), so the default export flips from the raw string to the parsed object. `normalizeFetchParametersForResolvedPath` has the same issue for dynamic `import("./cfg.json?raw")`. Skip the synthesis when the stripped query is `?raw` in both
Check warning on line 6208 in src/js_printer/lib.rs
claude / Claude Code Review
Leading '#' truncation misses subpath-import .json specifiers
For a Node subpath-import specifier like `#cfg/data.json`, `.position(|&c| c == b'?' || c == b'#')` returns 0, so `path` becomes `b""` and this function returns `false` — no `with { type: "json" }` is emitted, and the identity fork this PR fixes remains for static `#`-prefixed subpath imports resolving to JSON. On the printer side `record.path.text` is the unresolved specifier, where a leading `#` is a subpath marker (resolver.rs:2569), not a URL fragment; Bun's own `normalize_specifier_for_load
Loading