[v9] "optimization": true breaks sourcemaps?

[mstawick]

🐞 Bug report

Command (mark with an x)

• new
• build
• serve
• test
• e2e
• generate
• add
• update
• lint
• xi18n
• run
• config
• help
• version
• doc

Is this a regression?

Yes, it was fine with v8

Description

There's a question mark, because either sourcemaps are broken, or my understanding of how they work is wrong. Here's my use case and "investigation".

I'm using Sentry for crash-tracking and for production builds I generate source maps and upload them directly to sentry. After switching to v9, all the resolved stack traces were wrong (ie. resolved methods are something else then they should be) - it's all garbage. After going back-and-forth, I've discovered that everything works fine if I disable optimization flag.

So I've created a simple project (ng new), add a small piece of code (button + onclick handler) and generated a production build with optimization enabled (ng build --prod --source-map). I've then decoded the map file using @bengourley/source-map-decoder and compared mapping with the actual minified js file. Turns out column number from the mapping is nowhere close to the actual code it should point to.

🔬 Minimal Reproduction

I've attached a reproduction. Inside is a folder help that contains files I've investigated - the main bundle, it's source map, decoded version, and relevant entries.

sourcemap-bug.zip

🌍 Your Environment

Angular CLI: 9.0.1
Node: 12.14.1
OS: linux x64

Angular: 9.0.0
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router
Ivy Workspace: Yes

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.900.1
@angular-devkit/build-angular     0.900.1
@angular-devkit/build-optimizer   0.900.1
@angular-devkit/build-webpack     0.900.1
@angular-devkit/core              9.0.1
@angular-devkit/schematics        9.0.1
@angular/cli                      9.0.1
@ngtools/webpack                  9.0.1
@schematics/angular               9.0.1
@schematics/update                0.900.1
rxjs                              6.5.4
typescript                        3.7.5
webpack                           4.41.2

[james-criscuolo]

I noticed this as well, just with a different setup. I disable differential loading in my dev environment by switching the target to es5 in a tsconfig. Switching that target to es2015 is the only change needed to break my sourcemaps. This turns off differential loading, along with I'm sure several other things in the configuration process. I was able to get a differential loading build working, but then turning on optimization in that build (as this ticket did) also breaks the sourcemaps, so there is something a bit deeper here.

As for how I've seen the sourcemaps broken, in the working cases, the sources tab of the inspector shows a folder webpack:// with nested folder .. After the dot folder, the path is as I'd expect into my source files. In the broken cases, the dot folder is missing and after webpack:// my source folders/files begin. I'm trying to dig more into this, but at this point it's digging somewhat blindli through a ton of source. It's hard to tell if it's the piece reporting to webpack what files to sourcemap, or webpack itself, although my current suspicions rest in the former. If anybody has any insight on how to debug this aspect better, please let me know.

Lastly, I was going to open a ticket about my specific case the other day before this one appeared, but was unable to reproduce it with a fresh angular/cli project. This makes me believe there must be some way to make this work, but I'm currently at a loss. Still digging though, I will report if I find anything.

[clydin]

@mstawick I used http://sokra.github.io/source-map-visualization/#custom to analyze the main bundle in the help folder from the included zip file. Other than a couple sections of the app component's HTML template (mainly the <style> element and its content), everything appears to map back to the correct section of code. The unmapped HTML template sections appear to be AOT compiler related and I will be investigating further. The actual application code (TS/JS) appears to be accurately mapped back to the original source though. I also tried and was successful in using breakpoints placed on the original source in the Chrome debugger.

However, for output code that was previously greater than 500Kb, there was an issue with the source maps regarding the absence of the source content that can accompany the mappings. This is not an issue if the debugging environment is setup to map back to the on-disk project files but is problematic if using the source maps in isolation. This has been corrected in the referenced PR and will be in the next patch release.

[mstawick]

@clydin Thanks! So probably my issue with the actual project is real, and my "reproduction" is flawed. I'll test with next CLI release and bother Sentry support if it still doesn't work. In any case, thank you very much.

[james-criscuolo]

I can confirm that the new release (9.0.3) fixes the issue I was running into. Thanks!

[elvisbegovic]

Thank you @clydin, fixed on our side (.map files are no more empty)