angular-cli: [v9] "optimization": true breaks sourcemaps?

🐞 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

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 8
Comments: 28 (7 by maintainers)

Most upvoted comments

@mkhodan For myself I found the problem was coming from codeCoverage. I remove it from test in angular.json file and now I can debug unit tests like before.

scote on May 26, 2020

I sady just spent the effort of enabling and uploading my source maps only to realize that they were not working properly when using --localize. I just confirmed this is an issue on 9.0.2 and when upgrading to 9.1.0 it still seems to be an issue.

Has there has been much progress made other than 7f4da00865402da10e9b4a7c31dbb1796fa98ecc which was about two weeks ago? (Not saying there should be, just wanted to know the status of this issue)

terencehonles on Apr 3, 2020

So is there an issue open for codeCoverage: true breaking the source maps?

sdesmond on Jun 26, 2020

@clydin it looks like you fixed the issue with #17389. I was starting to look into the issue further, and I noticed your commit. When building against that commit it appears my optimized source maps are valid (the original breakpoints which weren’t working are now working)

Thanks for the fix, and looking forward to it being published!

terencehonles on Apr 8, 2020

Other people who have the issue with source map not matching with Karma debugging when running ng test?

@johnbwoodruff did you create the issue?

scote on May 4, 2020

Sourcemaps for the app code while running ng test and using the karma debugging in Chrome have also broken since the 9.0 release. Not test code, however, that continues to work.

johnbwoodruff on Feb 20, 2020

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.

james-criscuolo on Feb 12, 2020