fix(@angular/build): inline external sourcemaps for workspace library files#32788
fix(@angular/build): inline external sourcemaps for workspace library files#32788JSMike wants to merge 1 commit intoangular:mainfrom
Conversation
There was a problem hiding this comment.
Code Review
This pull request fixes an issue where external sourcemaps from workspace libraries are not inlined, which breaks the sourcemap chain in esbuild. The change correctly identifies external sourcemap URLs, reads the map file, and inlines it as a base64 data URI. The fallback mechanism for unreadable map files is also sensible. My review includes a suggestion to improve the implementation by using asynchronous file I/O and adding a warning for when a sourcemap file cannot be read, which will aid in debugging.
packages/angular/build/src/tools/esbuild/javascript-transformer-worker.ts
Show resolved
Hide resolved
3ec6e15 to
4fc722c
Compare
… files When no Babel plugins are required, the JavaScript transformer returns library files as-is, preserving the comment but never reading the referenced map file from disk. esbuild does not follow external sourcemap links in input files, so the chain from bundled output back to the original TypeScript source is never formed. Read the external map file and return an inline base64 sourcemap instead. esbuild processes inline sourcemaps from input files correctly, allowing it to compose the full sourcemap chain through to the original TypeScript source.
4fc722c to
d72a80a
Compare
|
@alan-agius4 I just pushed some fixes. The initial PR was early, sorry about that. I've confirmed the fix locally. I'll be at the Angular Enterprise Summit in a couple of hours, see you there :) I could set up office hours with you if you'd like to review. |
The issue occurs when using tsconfig paths to alias to locally built libraries in dist/, I believe it was working as intended with node_modules/. I can push my repro soon. |
|
The TypeScript compiler emits two Before Fix (Sources shows |
|
Could you provide a minimal reproduction of this issue using ng new? Alternatively, an isolated E2E test case highlighting the regression would be highly beneficial for our debugging process. Unless I am missing something from the above, in the first instance the |
|
@alan-agius4 working on my slides for tomorrow (where I discovered the issue), I have this in an NX monorepo right now if that helps, |
When no Babel plugins are required, the JavaScript transformer returns library
files as-is, preserving the
//# sourceMappingURLcomment but never readingthe referenced map file from disk. esbuild does not follow external sourcemap
links in input files, so the chain from bundled output back to the original
TypeScript source is never formed.
Read the external map file and return an inline base64 sourcemap instead.
esbuild processes inline sourcemaps from input files correctly, allowing it
to compose the full sourcemap chain through to the original TypeScript source.
Reproduction
A workspace library built with TypeScript (e.g.
dist/libs/my-lib/index.js)contains a
//# sourceMappingURL=index.js.mapcomment. When an Angularapplication imports from that library via a TypeScript path alias, the bundled
main.js.mapincludes the transpiled JS insourcesContentending with//# sourceMappingURL=index.js.map, but the browser DevTools cannot resolvethe original TypeScript source because esbuild never followed the external
map reference.
Fix
When the early-return branch is taken (no Babel plugins needed), check for an
external
sourceMappingURLreference, read the.mapfile from disk, andreturn an inline base64 sourcemap. esbuild correctly chains inline sourcemaps
from input files, producing a complete map from bundle output back to the
original TypeScript source.
The
catchblock handles unreadable map files gracefully, falling back to theoriginal external reference.