Conversation
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 68c516ba9d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| (match (!current, Hashtbl.find_opt marker_locs id) with | ||
| | Some builder, Some loc -> | ||
| let generated_line, generated_column = Ext_pp.position fmt in | ||
| add_mapping builder ~generated_line ~generated_column loc |
There was a problem hiding this comment.
comment_of_loc stores every marker ID in the process-global marker_locs, but mark_comment only does a find_opt and never removes the entry. In long-lived processes (notably rewatch watch mode), each rebuild/file compile adds more IDs and this table grows without bound, which steadily increases memory use and retained location data even after maps are emitted.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
👍 Good catch. The rewatch-specific leak is limited today because rewatch spawns bsc as a separate process, so the OCaml global table does not live for the whole watch session. Still, consumed markers should be removed from marker_locs; they are one-shot internal markers and keeping them unnecessarily retains location data for the rest of the compiler process. I’ll update mark_comment to remove marker entries after lookup.
| | from_root :: _, to_root :: _ when from_root = to_root -> | ||
| let from_rest, to_rest = drop_common from_parts to_parts in | ||
| let parts = repeat ".." (List.length from_rest) @ to_rest in | ||
| if parts = [] then Filename.basename to_file else String.concat "/" parts | ||
| | _ -> Filename.basename to_file |
There was a problem hiding this comment.
When the first normalized path segment differs, relative_path falls back to Filename.basename, which drops directory context entirely. If generated outputs and source files resolve through different absolute prefixes (for example symlink/canonicalized roots), the map will emit only bare filenames, causing ambiguous or unresolvable sources entries when sourcesContent is disabled.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
👍 Good catch. Falling back to Filename.basename can lose useful source path context and make sources ambiguous when sourcesContent is disabled. I updated the path logic to preserve relative paths whenever possible, even when the first normalized path segment differs. It now only falls back to a normalized absolute path for cross-drive Windows paths, where a filesystem-relative path is not representable.
|
|
||
| pub namespace: Option<NamespaceConfig>, | ||
| pub jsx: Option<JsxSpecs>, | ||
| #[serde(rename = "sourceMap")] |
There was a problem hiding this comment.
maybe these new options need to be nested in another "sourceMap": {}
object? You only use them together anyway, right?
There was a problem hiding this comment.
That’s a fair point. I kept the MVP shape as top-level fields to keep the implementation simple, but nesting the source map-specific options under a sourceMap object also looks like a good direction, especially if we add more options later.
{
"sourceMap": {
"mode": "linked",
"sourcesContent": true,
"sourceRoot": "",
...
}
}
rescript
@rescript/darwin-arm64
@rescript/darwin-x64
@rescript/linux-arm64
@rescript/linux-x64
@rescript/runtime
@rescript/win32-x64
commit: |
3 participants
Summary
Introduce linked Source Map v3 generation for ReScript JavaScript output.
This adds per-file
.js.mapoutput, appends//# sourceMappingURL=...to generated JavaScript, and wires source map options throughrescript.json,bsc, and rewatch. The compiler printer now tracks generated line/column positions and records mappings back to.ressource locations.Basic
rescript.jsonusage:{ "sourceMap": true, "sourceMapSourcesContent": true }This PR also preserves source locations through function output, call expressions, pipe expressions, and pattern-match branch output so browser breakpoints and Node stack traces can resolve back to .res files more usefully.
Validation
From the repository root:
The build test suite now includes
tests/build_tests/source_map, which verifies thatsourceMap: trueemits a.js.mapfile, writes a sourceMappingURL comment, includes non-empty mappings, and includes source contents.For manual browser and Node sourcemap behavior, see the external Vite test project:
https://github.com/mununki/rescript-sourcemap-test
The test project README explains how to check out the sourcemap branch of a local ReScript compiler clone, link it from package.json, and verify sourcemaps in Vite/Chrome DevTools and Node.
Next To Do
namesmappings for better symbol-level debugging.