6rc3 build size multiplied by 4 & build time multiplied by 2

[elvisbegovic]

Versions

Angular CLI: 6.0.0-rc.3
Node: 8.11.1
OS: win32 x64
Angular: 6.0.0-rc.3
... animations, cli, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

@angular/cdk: 6.0.0-rc.1
@angular/material: 6.0.0-rc.1
@angular-devkit/architect: 0.5.5
@angular-devkit/build-angular: 0.5.5
@angular-devkit/build-optimizer: 0.5.5
@angular-devkit/core: 0.5.5
@angular-devkit/schematics: 0.5.5
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 6.0.0-rc.3
@schematics/angular: 0.5.5
@schematics/update: 0.5.5
typescript: 2.7.2
webpack: 4.5.0

Repro steps

update from 1.7.x to 6rc3

Observed behavior

cli version	build size in MB	build time in ms	command
1.7.x	8.24	150000	ng build --prod (+ others i18 options)
6 rc.x	40.4	325078	ng build myProject (+see image below)

[skreborn]

Why aren't you building with --prod in v6's case? Isn't it still required to actually make use of the defined production configuration?

[elvisbegovic]

@skreborn with --prod it is same. Maybe another syntax instead of ng build myProject --prod ...

[filipesilva]

Heya @istiti, and 4x build size sounds like something is broken somewhere. ng build myProject --prod should give you a prod build.

I'm not sure where to start. Can you tell me if the output from CLI 6 in dist looks like it is uglified? All the vars renamed and in a single line.

Other than that I'd have to debug myself... in the projects we tests, we didn't see a size increase and the build time went down.

[elvisbegovic]

thanks @filipesilva ,
I tried many times... same behavior.

The only problem is "build size" I still get >40 MB ( see screenshot I delete intentially)

1.7.x verison build

6rc3 build

My heart is broken too ^^

I tried disable vendorChunk but build size still 4x big: here's screenshot:

To answer to your question: yes one line and yes vars renamed

Update

one of them in 6rc3 output 66.cb3a50319cb5f9413888.js

FYI most of blocking time build is at

step	time in mn
10%	1
79%	1
92%	2

[filipesilva]

@istiti very helpful information in your last comment, thank you!

@clydin was wondering if our sourcemaps were bugged but looking at the bundle you uploaded and the screenshot of file sizes, we now know that's not the case.

So we can see that some bundles just got much, much bigger.

I think that explains why the build time is longer: webpack and build optimizer have a lot more code to process.

I don't have an explanations for why the bundles got bigger in the first place.

I notice you have a vendor chunk in the second rc.3 example. Can you try setting vendorChunk to false in the production configuration please?

[elvisbegovic]

@filipesilva i was in editing mode of my last comment while you respond here, please check my last comment you was in my mind ^^ I post screenshot without vendorChunk

[filipesilva]

:D

Ok, so it didn't really change much with or without vendor chunk.

Maybe this is something related to Webpack and Module Concatenation... your project has many modules, and many as lazy as well. In the past regressions in Module Concatenation have broken your project, so that might be it.

I'll try to have a look soon in a big project I have. I also added this as a blocker for our 6.0 final.

[elvisbegovic]

Thanks to git !

/app size before update to angular6rc3 & cli6rc3 & rxjs6rc3

/app size after update

yes my project is >1.2k files :S hope not bad, business usecase lol

[elvisbegovic]

@filipesilva if you want to see content of some module let me know:

[elvisbegovic]

@clydin you are the boss it is ALMOST fixed with 6rc4 release !

Do I need open new issue or it's maybe related because now size build output seems correct (total 10MB) instead 8.2MB with cli1.7.x

I think I find why it is 10 instead 8 because with cli6rc4 I have a weird output chunks number beginin with ..js

Before in cli 1.7.x I had <75 chunks from 0...js to 72...js

And now with 6rc4 I have 115 chunks from 0...js to 115...js here is screenshot with vendorChunk to false but it is same if I put it to true:

I think numbers chunks are lazyload module? so when in my project I search loadChildren I only found 77matches :

FYI: you can check images above but yesterday with 6rc3 I had only 80 chunks begining from 0to80....js that seems more correct than today with 6rc4.

Maybe you miss something else ? Because Yes I continue to develop since my last 1.7.x build but I can't believe I add 2MB compiled code ^^

Especially if you see my comment above #10294 (comment)
you can see I have /app folder almost same size, thanks

@filipesilva thanks adding it as blocker to v6 release

[filipesilva]

@istiti very happy to hear a bit part of the problem was addressed!

I don't know why the size is still bigger than before. This isn't isn't closed so I think you don't need to open a new one, we can continue to look into it here.

The numbers are the lazy loaded modules, yes. I'm not sure why the numbers go so high, but it looks like the number of those bundles is the same as in 1.7 (or near the same). You can replace the numbers with their names by adding "namedChunks": true in the production configuration.

[elvisbegovic]

@filipesilva yep some are weird, here you are:

first part screenshot of my /dist

bottom part screenshot of my /dist

in these both screenshot you don't see all but second sreenshot is pretty interesting because of src chucnk which are duplicated, I think without theses chunks, the number should be correct ! no?

my routing.ts are declared from /src/... example:

{
    path: '', component: WrapperComponent,
    children: [
      // Module des immeubles
      {path: 'immeuble', loadChildren: 'src/app/immeuble/immeuble.module#ImmeubleModule'},

      // Module des objets
      {path: 'objet', loadChildren: 'src/app/objet/objet.module#ObjetModule'},
      
      // Module des baux
      {path: 'bail', loadChildren: 'src/app/bail/bail.module#BailModule'},

      // Module des loyers
      {path: 'loyer', loadChildren: 'src/app/loyer/loyer.module#LoyerModule'},

      // Module des personnes
      {path: 'personne', loadChildren: 'src/app/personne/personne.routes.module#PersonneRoutesModule'},

      // Modules des autorisations (Utilisateurs et groupes)
      {path: 'authorisation', loadChildren: 'src/app/autorisations/autorisations.module#AutorisationsModule'},

      {path: 'donnees-statiques', loadChildren: 'src/app/donnees-statiques/donnees-statiques.module#DonneesStatiquesModule'},

      {path: 'societe', loadChildren: 'src/app/societe/societe.module#SocieteModule'},
      {path: 'sauvegardes-rapides', loadChildren: 'src/app/sauvegardes-rapides/sauvegardes-rapides.module#SauvegardesRapidesModule'},

      {path: 'home', component: HomeComponent},
      {path: '', pathMatch: 'full', redirectTo: 'home'}
    ]
  }

[elvisbegovic]

I found the bug here! But i can't understand.

If it can help you here you are the squelete of my code. If you are interested in one module/file in particular let me know .

In this stackblitz repro, I write (not working) structure of my app.

Please check where is imported DialogModule.

If in app.module = 115 numeroted chunks generated.
If in wrapper.module = 96 numeroted chunks generated.

cc @filipesilva @clydin

[clydin]

The observed behavior isn't necessarily a bug but a result of the new behavior for Webpack 4, and as a result CLI 6.0. The module analysis and splitting is significantly more advanced. In CLI 1.x all common modules found within lazy routes where combined into one potentially large common chunk. While this reduced the size of the affected modules, it required all these lazy routes to download and use this common chunk regardless of how many of those common modules were actually needed for that route. The new behavior now creates more granular common chunks based on the specific needs of each lazy chunk and only loads the necessary common chunks for each lazy route. This is the cause for the increase in file count. Overall this should provide a benefit to end users of the application by reducing the amount of data necessary to visit a particular lazy route. This can be especially true if, for example, two routes (out of potentially many) require a vary large dependency that would in CLI 1.x be required to be downloaded by all lazy routes but now would not.

The settings may need to be fine tuned over time as more data is collected from a variety (e.g., lazy route count, dependency count & size, etc.) of projects.

[clydin]

Also, a blog post by the Webpack team provides some more details regarding the new behavior: https://medium.com/webpack/webpack-4-code-splitting-chunk-graph-and-the-splitchunks-optimization-be739a861366

[elvisbegovic]

@clydin
thanks to your explanation !
I was thinking it's bug but your response convice me to like this approach of lazyroutes!

I just notice that when more chunks are created size of app is around 1 MB bigger. This is too normal ?

You let my issue still opened I won't close it myself, feel free close it.

ps : someone create duplication here #10364 might be related

thanks again

[clydin]

This should now be improved in the upcoming release. If you are still encountering issues after the new release, please open a new issue with your findings.

[angular-automatic-lock-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.}