Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[1.3.0-rc.0] Sourcemaps seem borken when using new build optimizer #7093

Closed
bboehm86 opened this issue Jul 22, 2017 · 11 comments · Fixed by #7262
Closed

[1.3.0-rc.0] Sourcemaps seem borken when using new build optimizer #7093

bboehm86 opened this issue Jul 22, 2017 · 11 comments · Fixed by #7262
Labels
P1 Impacts a large percentage of users; if a workaround exists it is partial or overly painful type: bug/fix

Comments

@bboehm86
Copy link

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/cli@1.3.0-rc.0,
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 :-)

@filipesilva
Copy link
Contributor

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 #6989, which went in rc.0 as well.

@filipesilva filipesilva self-assigned this Jul 22, 2017
@filipesilva filipesilva added P1 Impacts a large percentage of users; if a workaround exists it is partial or overly painful type: bug/fix labels Jul 22, 2017
@bboehm86
Copy link
Author

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)

@filipesilva
Copy link
Contributor

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.

@bboehm86
Copy link
Author

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

@filipesilva
Copy link
Contributor

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 (angular/components#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.

@bboehm86
Copy link
Author

I see, great explanation thanks al lot 👍

filipesilva added a commit to filipesilva/angular-cli that referenced this issue Aug 3, 2017
hansl pushed a commit that referenced this issue Aug 3, 2017
hansl pushed a commit that referenced this issue Aug 3, 2017

Unverified

This user has not yet uploaded their public signing key.
Fix #7114
Fix #7110
Fix #7093
@ianchi
Copy link

ianchi commented Aug 8, 2017

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)

@filipesilva
Copy link
Contributor

Will look at it, reopening.

@filipesilva filipesilva reopened this Aug 10, 2017
@filipesilva
Copy link
Contributor

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

dond2clouds pushed a commit to d2clouds/speedray-cli that referenced this issue Apr 23, 2018
@mgechev
Copy link
Member

mgechev commented Dec 18, 2018

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.

@mgechev mgechev closed this as completed Dec 18, 2018
@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 9, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
P1 Impacts a large percentage of users; if a workaround exists it is partial or overly painful type: bug/fix
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants