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

[mstawick]

🐞 Bug report

Command (mark with an x)

• [ ] new
• [x] 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)

[mstawick]

@clydin It seems like part of the issue was fixed, however using "optimization": true combined with "localize": true still breaks it for me.

When I inspect source maps using http://sokra.github.io/source-map-visualization/#custom, it seems like the beginning of the maps match, but then after certain point (maybe the first appearance of $localize in the original code?), it's all messed up.

I think it's more of a localize problem now rather than optimization problem, but I just wanted to know what you think before opening a new issue.

Meanwhile, I'll try to create a small reproduction.

[clydin]

@mstawick If you have some time, can you try with version v9.1.0-next.0 (and @angular-devkit/[email protected])?

[mstawick]

@clydin I've tested with my project, and it's still broken. It looks like something is done differently - the build takes ca. 4x longer (with 5 languages), however, the source maps come out broken.

Since the js files generated per language are different, I would assume that the source map files should also differ slightly. However all of the source map files are identical across the languages (so main-es2015 for da_DK locale is the same as main-es2015 for en_GB locale, and so on).

Here's a small project which illustrates the problem (included build output):
https://github.com/mstawick/angular9-repro

If you build it with "localize": false, then source maps match nicely with minified js. However, if you build it with "localize": true, source maps don't align, not event the source locale ("en" in this case).

[johnbwoodruff]

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.

[clydin]

@johnbwoodruff I don't think that is related to this issue. Can you open a new issue detailing the problem? A minimal reproduction demonstrating the issue would also be helpful.

[vltansky]

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.

angular 9.0.4 i have exactly opposite situation. with target: es5 getting empty sourcempas, changing it to es2015 and getting sourcemap fixed.

[pschmiedel]

We're having a similar issue (source maps being empty) when setting "localize": true. The application in question is a hybrid AngularJS/Angular application using the custom-webpack builder. Right now this is preventing us from switching to Ivy.

I created a sample repo to showcase the issue: https://github.com/pschmiedel/angular-phonecat-hybrid

It's basically the AngularJS demo phonecat application converted to a hybrid following the docs. The application itself is working fine, however the source map for main.js turns out empty when running ng build. Note that this is the dev build, so optimiation should be off.

[terencehonles]

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]

@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!

[clydin]

@terencehonles The fix is included in the recently released version 9.1.1. Please give it a try and let us know if it solves your issues.

[terencehonles]

@clydin it looks like it's working for me.

[clydin]

This should now be fixed in version 9.1.1. If anyone is still encountering issues, please ensure the project is using that version. If it is, please open a new issue detailing the problem.

[mstawick]

Yes, works for me as well. Thanks!

[scote]

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

@johnbwoodruff did you create the issue?

[mkhodan]

@scote I faced the same issue, code is formatted but once I put debugger it stops in wrong place and highlights wrong variables

[scote]

@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.

[mkhodan]

@scote Thank you so much! It works for me now.

[scote]

@mkhodan took me awhile to find a fix/workaround to this issue. Before I found this debugging unit tests was impossible.

[tonivj5]

Hence, does codeCoverage break the source maps? :confused:

[scote]

Yes , for Angular 9 when debugging unit tests.

[grzesiek110]

@scote Thanks!

[sdesmond]

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

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{_This action has been performed automatically by a bot._}