Angular-cli: 9.0.0-rc.0 large bundle files

Created on 4 Nov 2019  路  10Comments  路  Source: angular/angular-cli

main.js file increased from 462kb to 732kb after updating from @angular 8.2.13, @angular/cli 8.3.17 to @angular 9.0.0-rc.0, @angular/cli 9.0.0-rc.0

Node - v12.13.0
npm - 6.12.1
os - Ubuntu 16.04.3

@angular 9.0.0-rc.0, @angular/cli 9.0.0-rc.0
1

@angular 8.2.13, @angular/cli 8.3.17
2

blocked devkibuild-angular high regression bufix

All 10 comments

Any chance of repro? Would love to investigate this.

Yes, I will provide a repo soon

With 95% removed of the project repo link, still production main.js is 630kb.

Can you provide the on disk sizes of the files in question?

Thank you very much for the repro! Having a look right now. I turned on the named chunks in prod as well. Here's the output I get:

  • Ivy
$ du -ach --max-depth=1 dist/ivy/*-es2015*.js
4.0K    dist/ivy/account-module-es2015.651d45349e2fbe04c251.js
4.0K    dist/ivy/activation-index-es2015.9450cc36b6fded32a2a8.js
4.0K    dist/ivy/address-index-es2015.2dc71d8efc64d410c2c5.js
4.0K    dist/ivy/home-index-es2015.2acff8cea710ca8100dd.js
632K    dist/ivy/main-es2015.56a5fc1ca93b19ef45a5.js
4.0K    dist/ivy/main-module-es2015.ae7f6b5241a0ea484963.js
4.0K    dist/ivy/orders-index-es2015.d7a8763fee9ef0cbe249.js
36K     dist/ivy/polyfills-es2015.4ca042a700205e71b559.js
4.0K    dist/ivy/profile-index-es2015.99755589c062922c0fc9.js
4.0K    dist/ivy/runtime-es2015.bbab9761fc8ffe9c4638.js
4.0K    dist/ivy/settings-module-es2015.9c978feff3958a32572b.js
704K    total
  • View Engine (VE, what we used before Ivy) via "angularCompilerOptions": { "enableIvy": false } in tsconfig.app.json
$ du -ach --max-depth=1 dist/ve/*-es2015*.js
4.0K    dist/ve/account-module-ngfactory-es2015.008931b3e1b2661ed8e8.js
4.0K    dist/ve/activation-index-ngfactory-es2015.98fa8a4e08d4f199f7aa.js
4.0K    dist/ve/address-index-ngfactory-es2015.125745885a637b517e4a.js
4.0K    dist/ve/home-index-ngfactory-es2015.88d6be482f70e37e2931.js
368K    dist/ve/main-es2015.d08398feb4f7dc1e4bb3.js
4.0K    dist/ve/main-module-ngfactory-es2015.fa843e9eaf2620e3ad66.js
4.0K    dist/ve/orders-index-ngfactory-es2015.6f974e6038ab607434f3.js
36K     dist/ve/polyfills-es2015.4ca042a700205e71b559.js
4.0K    dist/ve/profile-index-ngfactory-es2015.4c33418c7bc5196959e6.js
4.0K    dist/ve/runtime-es2015.ad649188e0b971350ea2.js
8.0K    dist/ve/settings-module-ngfactory-es2015.c9d5ef9d86217337fe89.js
216K    dist/ve/store-module-module-ngfactory-es2015.38b5454b3ae48c06a602.js
660K    total

So for main-es2015 Ivy gives a 632K bundle and VE is a 368K bundle. The total file size is closer together, but Ivy is still bigger.

The important bit seems to be the store-module chunk that is 216K in VE but only gone in Ivy. Seems that size was slurped up in the main bundle instead. Which isn't great because it makes the initial payload bigger.

I think some of the code that was moved around for Ivy is causing webpack to decide to frontload the payload. Looking at store-module it seems it uses @angular/material while none of the other modules do. That seems a good place to start investigating.

@clydin looked into this and figured out it was because the src/app/guards/ActivationGuard's providedIn: StoreModule.

I looked a bit more and it looks to be a problem because of the src/app/guards/index.ts file. This file re-exports four guards, three of them have providedIn: 'root' and then there's providedIn: StoreModule in ActivationGuard.

I think that somewhere in Ivy's codegen some imports are being generated that reference src/app/guards/index.ts for both the main chunk and the store-module chunk. This'd make it not a lazy route at all.

But even if that wasn't happening there's already an import from the toplevel src/app.routes.ts to src/app/guards, and also one from src/app/store-module/account/routes.ts there too. So maybe it's not that Ivy added an import, but rather that VE removed some when processing decorators.

@alxhub does any of this sound familiar?

For now what you can do is to remove ActivationGuard from src/app/guards/index.ts and import it via import { ActivationGuard } from '../../guards/ActivationGuard'; in src/app/store-module/account/routes.ts. That'll get your sizes down again.

Yes, I found the same problem. I changed ActivationGuard place but somehow it really breaks lazy load before.

Let me just keep it open to see if we can prevent it.

Heya, we got other reports that end up being the same thing in the end: code that has a direct import from main.ts ends up in the main bundle. I've added a more comprehensive description and minimal repro in https://github.com/angular/angular-cli/issues/16146#issuecomment-557559287. Please follow that issue for updates.

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