Angular-cli: [1.3.0-rc.0] Sourcemaps seem borken when using new build optimizer

Created on 22 Jul 2017  ·  11Comments  ·  Source: angular/angular-cli

First of big thanks to @filipesilva for adding the --build-optimizer! It saved about 200kb (non gzip) in overall size on a blank project with material and about 500kb on a production one, good job 👍

(as a note: up until now I could not see any real size difference when enabling the vendor chunk again, always <1kb)

Bug Report or Feature Request (mark with an x)

- [x] bug report -> please search issues before submitting
- [ ] feature request

Versions.

    _                      _                 ____ _     ___
   / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
  / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
 / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
/_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
               |___/
@angular/cli: 1.3.0-rc.0
node: 8.1.1
os: win32 x64
@angular/animations: 4.3.1
@angular/cdk: 2.0.0-beta.8
@angular/common: 4.3.1
@angular/compiler: 4.3.1
@angular/core: 4.3.1
@angular/forms: 4.3.1
@angular/http: 4.3.1
@angular/material: 2.0.0-beta.8
@angular/platform-browser: 4.3.1
@angular/platform-browser-dynamic: 4.3.1
@angular/router: 4.3.1
@angular/cli: 1.3.0-rc.0
@angular/compiler-cli: 4.3.1
@angular/language-service: 4.3.1

on Windows 10

Repro steps.

Install latest @angular/[email protected],
generate a new project and
run ng build --prod --bo --oh=none --vendor-chunk=true. (same goes when vendor chunk is disabled)
change to dist and run source-map-explorer vendor.bundle.js (same for webpack-bundle-analyzer)

or use https://github.com/bboehm86/mat-chunk-test
run npm run build:bo:vc

The log given by the failure.

No failure but just no usable informations for vendor files (there should be angular, angular material and rxjs inside)
cli

Desired functionality.

It would be nice if still could still have usabe sourcemap infos to take a look into our bundle and see whats inside :-)

1 (urgent) bufix

Most helpful comment

Thanks a bunch @bboehm86, this is super useful info - especially with easy repro and numbers. This is exactly the stuff I want to get fixed for 1.3.0. I'll get on it.

Regarding size differences, they were there but the stats didn't show it. We fixed the stats in https://github.com/angular/angular-cli/pull/6989, which went in rc.0 as well.

All 11 comments

Thanks a bunch @bboehm86, this is super useful info - especially with easy repro and numbers. This is exactly the stuff I want to get fixed for 1.3.0. I'll get on it.

Regarding size differences, they were there but the stats didn't show it. We fixed the stats in https://github.com/angular/angular-cli/pull/6989, which went in rc.0 as well.

Thanks a lot for the quick response, you guys are rly doing a great job!

As for the size differences.. I guess you are refering to the vendor chunk disbaled/enabled option. I checked the actual size of the files for that (main.bundle.js and vendor.bundle.js) since I was used to do that anyways and didn't look at the console output. (but I was aware of the fix of the stats output) :-)
Since you like numbers I took a look again. So for the example repo it would be:

  • vc disabled: 708.961 bytes [with gzip: 153.871 bytes] (main.bundle.js)
  • vc enabled: 709.010 bytes [with gzip: 153.919 bytes] (main.bundle.js & vendor.bundle.js)

Not that big a difference (for this example at least)

I digged into the sourcemaps and we're definitely breaking them somewhere, and also the default was broken (prod build should have it turned off by default).

It's cool to see that the VC didn't make much of a difference in your setup. In another setup (angular.io actually) it made a huge difference. About 40% of the total savings were gone by having the VS. But I hope that webpack improvements in scope hoisting might bring that down. It's something we'll keep monitoring.

@filipesilva Good point you've got there it slipped my mind that they are disabled by default...

And you are quite right about the vendor chunk size at aio. I tried it with the version you commited with the new CLI and I'm getting the same differences in size you've mentioned. Not sure why though...
If you are going to investigate this, it might help you that I found some Material assets in the vendor chunk that shouldn't be there (as they aren't present in the version without the vendor chunk).
eg. the MdDatepicker gets removed while building since it's not used. But when using the vc the error messages, the default month names, etc. are still present in the vendor chunk file (while getting remove when disabling the vc)...

Your findings corroborate what I've been seeing as well. I think it's wholly related to scope hoisting and the current status of angular material tree shaking (https://github.com/angular/material2/issues/4137).

So by itself material is not tree-shaked properly; but with scope hoisting + uglify + build-optimizer, parts of it are. Scope hoisting is very important here as it helps uglify drop more stuff. When you have a vendor chunk, there should be at least 2 scope hoisting contexts (one for main, or for vendor). Having them separated reduces gains by not allowing uglify to drop as much.

This seems to be more important when the code is stuff to which build optimizer adds annotations (downleved TS code and angular specific code). So when you have a lot of angular libs in the same chunk, more is saved.

If you have a lot of stuff that the build optimizer doesn't touch, the difference isn't as dramatic.

I see, great explanation thanks al lot 👍

Hi @filipesilva, I'm not sure if this is related to this error, but now source map explorer is working again, but I get strange results in the reported sizes.
For instance my "main.bundle.js" file is 683kb (not gziped) but the reporting in the source map explorer is only 297kb.
Is it possible that we are still loosing some info in the source map?
( this was done with rc.5)

Will look at it, reopening.

@ianchi with 1.3.0 final I could see a difference, but not directly related to build optimizer. I built the application three times, and compared the disk size of main.bundle.js with the size reported by source-map-explorer:

  • --aot --build-optimizer: 3.57 MB disk-size, 3.26 MB source-map-explorer
  • --prod: 1.1 MB disk-size, 407 kB source-map-explorer
  • --prod --build-optimizer: 540 kB disk-size, 288 kB source-map-explorer

I also tried webpack-bundle-analyzer and it seems to report much closer values for stat/parsed sizes.

So there's always a difference, I'm not sure why. The difference without --prod is rather tame and could possibly be webpack helper functions.

But the difference in prod is around half the size. It seems related to either uglification or webpack concatenated modules (that's what changes in production).

@TheLarkInn do you have any insight on this?

Looks like an old issue. Closing it for now. If it's not resolved, feel free to open a new one with details and demo where we can reproduce the problem.

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

Was this page helpful?
0 / 5 - 0 ratings