Angular-cli: It takes forever in "92% chunk asset optimization" can it be cached or disabled?

[marcalj]

Bug Report or Feature Request (mark with an x)

- [x] feature request

Versions.

@angular/cli: 1.0.0-rc.2
node: 6.9.2
os: darwin x64
@angular/common: 2.4.10
@angular/compiler: 2.4.10
@angular/core: 2.4.10
@angular/forms: 2.4.10
@angular/http: 2.4.10
@angular/platform-browser: 2.4.10
@angular/platform-browser-dynamic: 2.4.10
@angular/router: 3.4.10
@angular/cli: 1.0.0-rc.2
@angular/compiler-cli: 2.4.10

Desired functionality.

assets optimization it rarely changes when you only do coding, and specially for my project it takes 2-5 minutes each time. So it's killing my productivity. With "--verbose" it doesn't show me any specific files which I could remove temporally to speed up the process of compiling...

Hash: 51ba5014dae3bd179ab9                                                                 
Time: 395021ms
chunk    {0} main.bundle.js, main.bundle.js.map (main) 10.8 MB {4} [initial] [rendered]
chunk    {1} polyfills.bundle.js, polyfills.bundle.js.map (polyfills) 278 kB {5} [initial] [rendered]
chunk    {2} styles.bundle.js, styles.bundle.js.map (styles) 751 kB {5} [initial] [rendered]
chunk    {3} scripts.bundle.js, scripts.bundle.js.map (scripts) 362 kB {5} [initial] [rendered]
chunk    {4} vendor.bundle.js, vendor.bundle.js.map (vendor) 4.44 MB [initial] [rendered]
chunk    {5} inline.bundle.js, inline.bundle.js.map (inline) 0 bytes [entry] [rendered]

Thanks.

[Meligy]

This is Webpack output, not an awesome one.

Assets here do not refer to Angular CLI assets. They refer to Webpack chunk files. This is where a big part of the Webpack processing of files happens. That's why it's a long-ish one.

There's a very long discussion about the whole build speed topic here https://github.com/angular/angular-cli/issues/1980.

What you are seeing is certainly crazy though (and very unusual from experience with many projects), regardless of this specific message.

[clydin]

can you provide the command line used to perform the build?

[marcalj]

@clydin I'm using ng serve --proxy-config proxy.config.json --aot --watch false --verbose or ng build --aot.

I'm also compiling without Ahead of Time (AoT) though... but my project is big...

[marcalj]

Without AoT the build time is reduced considerably:

40207ms building modules                                                                   
293ms sealing
17ms optimizing
1ms basic module optimization 
0ms module optimization 
1000ms advanced module optimization
58ms basic chunk optimization       
0ms chunk optimization 
4ms advanced chunk optimization 
0ms module and chunk tree optimization 
0ms module reviving 
60ms module order optimization
9ms module id optimization 
0ms chunk reviving 
11ms chunk order optimization
51ms chunk id optimization
186ms hashing
4ms module assets processing 
368ms chunk assets processing
10ms additional chunk assets processing
0ms recording 
0ms additional asset processing 
11447ms chunk asset optimization
106ms asset optimization
784ms emitting
Hash: 52784939e9af576aa850
Version: webpack 2.2.1
Time: 54662ms

But I get more errors with AoT enabled, that's why I want to use it while building.

[marcalj]

Now I need to expand node's heap memory size to compile with AoT. It now uses 5.5GB of RAM to compile with AoT... :(

node --max_old_space_size=8192 ./node_modules/.bin/ng build --aot
Hash: 2013b35185f990a8e57f                                                                 
Time: 373584ms
chunk    {0} main.bundle.js, main.bundle.js.map (main) 12 MB {4} [initial] [rendered]
chunk    {1} polyfills.bundle.js, polyfills.bundle.js.map (polyfills) 278 kB {5} [initial] [rendered]
chunk    {2} styles.bundle.js, styles.bundle.js.map (styles) 751 kB {5} [initial] [rendered]
chunk    {3} scripts.bundle.js, scripts.bundle.js.map (scripts) 362 kB {5} [initial] [rendered]
chunk    {4} vendor.bundle.js, vendor.bundle.js.map (vendor) 4.44 MB [initial] [rendered]
chunk    {5} inline.bundle.js, inline.bundle.js.map (inline) 0 bytes [entry] [rendered]

[ciesielskico]

+1, experiencing same problem with --aot enabled on CLI 1.0.0 and Angular 4.
It takes over 3 minutes to compile, most of it is at 92% chunk asset optimization.

> ng serve --proxy-config proxy.conf.json --open --aot

** NG Live Development Server is running on http://localhost:4200 **
 12% building modules 21/25 modules 4 active ...ode_modules/style-loader/addStyles.jswebpack: wait until bundle finished: /
 94% asset optimizationwebpack: wait until bundle finished: /
Hash: b569b293e489e6c84a01
Time: 192655ms
chunk    {0} 0.chunk.js, 0.chunk.js.map 3.84 MB {1} {2} {3} {4} {5} {6} {7} {9} [rendered]
chunk    {1} 1.chunk.js, 1.chunk.js.map 2.23 MB {0} {2} {3} {4} {5} {6} {7} {9} [rendered]
chunk    {2} 2.chunk.js, 2.chunk.js.map 1.91 MB {0} {1} {3} {4} {5} {6} {7} {9} [rendered]
chunk    {3} 3.chunk.js, 3.chunk.js.map 1.73 MB {0} {1} {2} {4} {5} {6} {7} {9} [rendered]
chunk    {4} 4.chunk.js, 4.chunk.js.map 1.74 MB {0} {1} {2} {3} {5} {6} {7} {9} [rendered]
chunk    {5} 5.chunk.js, 5.chunk.js.map 1.63 MB {0} {1} {2} {3} {4} {6} {7} {9} [rendered]
chunk    {6} 6.chunk.js, 6.chunk.js.map 1.6 MB {0} {1} {2} {3} {4} {5} {7} {9} [rendered]
chunk    {7} 7.chunk.js, 7.chunk.js.map 1.57 MB {0} {1} {2} {3} {4} {5} {6} {9} [rendered]
chunk    {8} polyfills.bundle.js, polyfills.bundle.js.map (polyfills) 231 kB {13} [initial] [rendered]
chunk    {9} main.bundle.js, main.bundle.js.map (main) 179 kB {12} [initial] [rendered]
chunk   {10} styles.bundle.js, styles.bundle.js.map (styles) 576 kB {13} [initial] [rendered]
chunk   {11} scripts.bundle.js, scripts.bundle.js.map (scripts) 858 kB {13} [initial] [rendered]
chunk   {12} vendor.bundle.js, vendor.bundle.js.map (vendor) 1.72 MB [initial] [rendered]
chunk   {13} inline.bundle.js, inline.bundle.js.map (inline) 0 bytes [entry] [rendered]
webpack: Compiled successfully.

Without --aot it takes around 20 seconds.

[hccampos]

For now, compiling AoT is unusable, and the Angular team knows it. Apparently they are working hard to make it faster, but it will always be significantly (?) slower than just going through the Typescript compiler.

Another thing that makes compilation extremely slow (and use a lot of memory) is having source maps enabled. In most situations we compile and develop without sourcemaps enabled because of how slow the rebuilds get when they are enabled. It is not ideal, but there is a lot of work that has to go into Webpack (especially) to make them fast.

Wepack has some cheaper source map options but they don't work properly with Typescript, so no go there either.

[clydin]

AOT is not currently intended for use during development. It is in essence a production optimization similar in some respects to minification or compression.

[marcalj]

@clydin I've used to detect bootstrap errors only present while executing (not compiling). Before writing tests it's very useful.

[DrMueller]

@clydin I have the 92% problem using ng test, which means Karma doesn't detect changes and I have to restart ng test every time. Is that the same problem or just a coincidence?

[filipesilva]

The 92% asset optimizing is a webpack thing, yes. I second what @hccampos and @clydin said: it is unadvisable to use --aot for development right now, as it will be too slow. The Angular team is working hard to make it fast enough to use at all times, but we're not there yet.

@DrMueller ng test currently does not make use of some optimizations we have in ng build and that causes rebuilds to be slow. That is being tracked in https://github.com/angular/angular-cli/issues/5423, with a tentative solution in https://github.com/angular/angular-cli/pull/6160.

[SchnWalter]

I had the same performance issue and I saw that by adding --sourcemap=false to ng serve and ng test things started to work a lot faster.

ng serve --sourcemap=false

[cevarief]

@SchnWalter This reduces significantly from 11 seconds to 6 seconds. Awesome. Any affect to development by turning off sourcemap?

[tytskyi]

Any affect to development by turning off sourcemap?

@cevarief
If you want to use debugger; or explore stack trace, then you will get mapping to unreliable lines of source code.
Which is acceptable when you don't want to debug. Otherwise if you want to debug you just turn it on with sourcemaps again.

[vance]

our AOT build takes 26 seconds. Is there a way to gain insight into what it is building at this step?

[ctrl-brk]

AOT takes some time but I only use it for production builds so it's OK.
ng serve takes a bit of time (less than AOT) initially but then it's pretty fast on rebuilds.
The only problem I still have is that when I change some interface definition it doesn't pick it up. It will rebuild but then complain that some field doesn't exist on the interface. You have to kill it and run ng serve again to make changes work.

[karthik04]

Disabling sourcemap made things much faster for me,

ng serve --sourcemap=false

[vance]

I guess I should have been more specific as this is part of ng test command from the angular cli. It is really frustrating running unit tests and having to wait 30 seconds...

[vance]

That slow 36-second ng test mentioned earlier was using CLI version 1.0. Using the latest 1.3.0-rc.5 is even slower. 2x time for compilation, 2x time for chunk asset optimization step. Using this version it takes 56 seconds before unit tests can run. If you turn on build-optimization it takes a whopping 98 seconds... We need a way to disable it for ng-test and/or get more verbose output during the chunk asset phase.

[tzehetner]

"ng serve --sourcemap=false" reduced the rebuild time from 20 seconds to 2 seconds in my case.

[egervari]

My AOT build takes 362 seconds on Google's Compute engine, 1 CPU, 6.5 Gig Ram. Adding more cpus hasn't really made any difference.

On my personal computer, it takes about 210 seconds to build the app, which is strange, because it's a 5-year old i7-3660 (OC'd to 4.2ghz, but still).

Honestly, this makes deployment frustrating, especially when you get a Javascript Heap Error and you've been waiting 6 minutes just to discover that.

As an aside, I think ng build's with aot should set the node memory for you, or you really ought to add this to your default package.json just to make things easier for people:

"build-prod": "node --max-old-space-size=8192 node_modules/@angular/cli/bin/ng build --prod --aot",

[gangsthub]

92% chunk asset optimization

I'm already ordering some! 😂

[allanesquina]

Running into the same issue here, it stops in 94%. Can we customize the shirt @gangsthub? :smile:

[SchnWalter]

You should stop complaining, update your Angular CLI, fix your AOT build warnings and use AOT also for debugging, since it now supports debugging:

ng serve --aot

And try to keep up with the Angular CLI releases, things are getting better day by day.

P.S. Thanks to everyone working on this!

EDIT: With AOT the initial build is slow, subsequent builds are a lot faster.

[bluefire2121]

I use Angular 6 with an extremely large enterprise project.

ng build --aot --prod

Time: 780178ms

Way too long

[gangsthub]

@bluefire2121 --aot makes it a little slower but it's totally worth it for the end user, IMO. Do you have a lot of assets? (just curious to know were the bottleneck is)

ng serve --aot is great advise by @SchnWalter

[bluefire2121]

@gangsthub I have 6.06MB of assets. I had initially created an API CDN to connect to my assets, but I had to scrap that plan due to CORS restrictions on our intranet. The assets have to exist on the same server domain. .gitignore and .tfignore both include node_modules so I'm unsure what could be causing the issue. We have lots of components, services, classes, and templates, but the initial compile shouldn't be that long.

[mlwilkerson]

I wonder if this "92% chunk asset optimization" problem is related to this performance regression on uglify-es (now terser). I was also seeing "92%" for a long time as a result of that issue.

[cub]

For me manually patch the "node_modulesuglify-es\lib\compress.js" like @mlwilkerson said for the issue https://github.com/fabiosantoscode/terser/issues/50 works : 26sec to build --prod --aot

[vermadev95]

You can use this flag while compiling:
ng serve --source-map=false

It take 10sec to compile now while previously it was taking 32sec.
source-map is just used for debugging. So if not using debugger you can disable and compile.

[gangsthub]

@spmsupun that hint was super good: But I'd recommend to use: --build-optimizer=true along with --vendor-chunk=true. I also added the --extract-css=true

ng build --aot --extract-css=true --build-optimizer=true --vendor-chunk=true --prod

The main chunck goes (with only --aot --prod) from 2.37MB to 734kB 😊

Also, timing, wich is what we were discussing decreases a little bit: from 120s to 70s.

[mrhrao]

this is the ram problem, you need to increse your ram or free ram.

[kdubious]

@mrhrao It is not a "ram problem" for me.

I'm trying to build and serve for debugging purposes. I'd like to AOT as well, but can live without it.

I'm using a configuration in my angular.json to set environment variables for my test machine:

configurations": {
        "production": {
          "fileReplacements": [
            {
              "replace": "src/environments/environment.ts",
              "with": "src/environments/environment.prod.ts"
            }
          ],
          "optimization": true,
          "outputHashing": "all",
          "sourceMap": false,
          "extractCss": true,
          "namedChunks": false,
          "aot": true,
          "extractLicenses": true,
          "vendorChunk": false,
          "buildOptimizer": true
        },
        "dev": {
          "fileReplacements": [
            {
              "replace": "src/environments/environment.ts",
              "with": "src/environments/environment.dev.ts"
            }
          ],
          "optimization": true,
          "outputHashing": "all",
          "sourceMap": true,
          "extractCss": true,
          "namedChunks": false,
          "aot": true,
          "extractLicenses": true,
          "vendorChunk": false,
          "buildOptimizer": true
        }
      }
    },

It takes forever (minutes) to compile. My command line is:
node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng serve ui -c dev --aot

I have current versions of all angular packages (as of 2018-07-12) "@angular/cli": "^6.0.8"

I have 562 files in my src folder.

Any ideas?

[kdubious]

@filipesilva Can we re-open this issue? Or direct me to a good one that's open?

[Empereol]

I get stuck at 92% chunk asset optimization UglifyJSPlugin seemingly forever (I left it overnight and it never passed).

This seems to only be an issue when using WSL (Windows Subsystem for Linux) as I'm able to build it appropriately in Docker containers or even using git-bash.

[hlohrenz]

I am also experiencing this with a new Angular 6 project. It ONLY takes forever when I build for prod with --prod. When I don't do a prod build, it goes super fast and smooth. Anybody ever figure this out?

[BigSakoLol]

Also got this problem. It takes 25 minutes to build project. Was 2-3 minutes before.

[ochadenat]

Same issue when deploying Angular 6 application to Heroku usingng build --prod
Getting stuck at 92% chunk asset optimization UglifyJSPlugin for at least 5 min

[nimatrazmjo]

same issue with webpack production

[rwlnd]

This is becoming quite the running gag. Stuck on 92% chunk asset optimization UglifyJSPlugin on gitlab while it's _quite_ acceptable when building locally, even with the --prod flag.

[sanjay2880]

it took me 1 hr to make a prod build
we are using angular 4.4.6 & my build command is
node --max_old_space_size=6048 node_modules/@angular/cli/bin/ng build --prod --aot --env=azureDev --extract-css --preserve-symlinks --named-chunks

[meghma]

Wish there was an acknowledgement from the Angular team about this issue and a tentative eta for solution

[hammadbinarif]

Same here, Getting stuck at 92% chunk asset optimization UglifyJSPlugin for at least 3 min

[kdubious]

@meghma, this item is marked as closed. Maybe open a new issue?

@filipesilva Can you help us with this?

[lucboutier]

Had the same issue and found some details on font awesome website:

https://fontawesome.com/how-to-use/with-the-api/other/tree-shaking

The workaround I have currently used is to create a patch.js file with the following content:

const fs = require('fs');
const common = 'node_modules/@angular-devkit/build-angular/src/angular-cli-files/models/webpack-configs/common.js';

fs.readFile(common, 'utf8', function (err, data) {
  if (err) {
    return console.log(err);
  }
  var result = data.replace(/compress: {/g, 'compress: { collapse_vars: false,');

  fs.writeFile(common, result, 'utf8', function (err) {
    if (err) return console.log(err);
  });
});

And reference it in the package.json

...

  "scripts": {
    "postinstall": "node patch.js",
...

you'll have to run node/yarn install so it is triggered.

HTH

[Sebubu]

@lucboutier Doesn't work in my case.

[vandammeb]

@lucboutier no luck here either, the only thing working for now is disabling compression all together, which is not an option in my case

[mlwilkerson]

There's a workaround available for yarn builds, using an alias to replace uglify-es with terser, which includes the root cause fix for the collpase_vars issue. That might be an option for some folks here until that fix makes its way into the Webpack 4 dependencies.

Has anyone tried that for an angular-cli project?

(UPDATE Sept 26, 2018: this change will _not_ make it into Webpack 4 deps, but the Webpack 5 roadmap includes a move to terser which has the fix.)

[vandammeb]

Managed to get it working by explicitly overriding all compress settings with their default values according to the docs (I have yet to figure out why that actually works though).

An update for the script from @lucboutier :

const fs = require('fs');
const common = 'node_modules/@angular-devkit/build-angular/src/angular-cli-files/models/webpack-configs/common.js';

fs.readFile(common, 'utf8', function (err, data) {
  if (err) {
    return console.log(err);
  }
  var result = data.replace(/compress: {[^}]*}/g, 'compress: {\n' +
    '           arrows: true,\n' +
    '           booleans: true,\n' +
    '           collapse_vars: true,\n' +
    '           comparisons: true,\n' +
    '           computed_props: true,\n' +
    '           conditionals: true,\n' +
    '           dead_code: true,\n' +
    '           drop_console: false,\n' +
    '           drop_debugger: true,\n' +
    '           ecma: wco.supportES2015 ? 6 : 5,\n' +
    '           evaluate: true,\n' +
    '           expression: false,\n' +
    '           global_defs: {},\n' +
    '           hoist_funs: false,\n' +
    '           hoist_props: true,\n' +
    '           hoist_vars: false,\n' +
    '           if_return: true,\n' +
    '           // Workaround known uglify-es issue\n' +
    '           // See https://github.com/mishoo/UglifyJS2/issues/2949#issuecomment-368070307\n' +
    '           inline: wco.supportES2015 ? 1 : 3,\n' +
    '           join_vars: true,\n' +
    '           keep_classnames: false,\n' +
    '           keep_fargs: true,\n' +
    '           keep_fnames: false,\n' +
    '           keep_infinity: false,\n' +
    '           loops: true,\n' +
    '           negate_iife: true,\n' +
    '           // PURE comments work best with 3 passes.\n' +
    '           // See https://github.com/webpack/webpack/issues/2899#issuecomment-317425926.\n' +
    '           passes: buildOptions.buildOptimizer ? 3 : 1,\n' +
    '           properties: true,\n' +
    '           pure_funcs: null,\n' +
    '           pure_getters: buildOptions.buildOptimizer,\n' +
    '           reduce_funcs: true,\n' +
    '           reduce_vars: true,\n' +
    '           sequences: true,\n' +
    '           side_effects: true,\n' +
    '           switches: true,\n' +
    '           toplevel: false,\n' +
    '           top_retain: null,\n' +
    '           typeofs: true,\n' +
    '           unsafe: false,\n' +
    '           unsafe_arrows: false,\n' +
    '           unsafe_comps: false,\n' +
    '           unsafe_Function: false,\n' +
    '           unsafe_math: false,\n' +
    '           unsafe_methods: false,\n' +
    '           unsafe_proto: false,\n' +
    '           unsafe_regexp: false,\n' +
    '           unsafe_undefined: false,\n' +
    '           unused: true,\n' +
    '           warnings: false\n' +
    '         }');

  fs.writeFile(common, result, 'utf8', function (err) {
    if (err) return console.log(err);
  });
});

To prevent the memory issue ng build still has to be run in a context with increased memory available

node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build ...

Hope still helps someone.

[gpresland]

Currently experiencing this issue.

Angular CLI: 6.1.3
Node: 8.11.3
OS: win32 x64
Angular: 6.1.2
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.7.3
@angular-devkit/build-angular     0.7.3
@angular-devkit/build-optimizer   0.7.3
@angular-devkit/build-webpack     0.7.3
@angular-devkit/core              0.7.3
@angular-devkit/schematics        0.7.3
@angular/cli                      6.1.3
@ngtools/webpack                  6.1.3
@schematics/angular               0.7.3
@schematics/update                0.7.3
rxjs                              6.2.2
typescript                        2.7.2
webpack                           4.9.2

@egervari 's solution of:

"build-prod": "node --max-old-space-size=8192 node_modules/@angular/cli/bin/ng build --prod --aot",

Makes the build go from ~12 minutes to 2 seconds for me.

[Drogglbecher]

@mlwilkerson: Worked with angular-cli. Thanks for the hint :+1:

[konstantinkoeppe]

@mlwilkerson: terser is working great - Significantly reduced build times from > 50 minutes to < 2 minutes for me.

Here's what I did (more of a temporary solution):

# Add terser to dependencies
npm install terser --save-dev

# Remove uglify-js
rm -r node_modules/uglify-js
rm -r node_modules/uglifyjs-webpack-plugin/node_modules/uglify-es

# Symlink to terser (which is fully compatible)
ln -s $(pwd)/node_modules/terser $(pwd)/node_modules/uglify-js
ln -s $(pwd)/node_modules/terser $(pwd)/node_modules/uglifyjs-webpack-plugin/node_modules/uglify-es

[tzjoke]

@konstantinkoeppe thanks for the script. building time decreased by 30%

[vitorrd]

konstantinkoeppe is the only solution I found in this thread. Great job mate.

[elie222]

Trying to build this in a docker container. Had no luck with any of the above approaches. Always hangs at 92%.

Why did this issue get closed?

[dietergoetelen]

FYI: I'm using the linux shell on windows. When I use the linux shell it's terribly slow (didn't even wait to finish).

When I use powershell it builds in 10seconds.

[anupy]

https://github.com/webpack-contrib/uglifyjs-webpack-plugin/issues/272

I found this solution node --max_old_space_size=4096 node_modules/.bin/webpack -p --progress --profile Hopefully, this will help someone.

[kdubious]

@anupy Any tips on what we do with that line and how it will help? I don't see the connection, yet.

[Bl4ckPix3l]

I had also a very slow build time from up to 20 min. But in my case, i had to optimize the imports. So, the tree shaking will not have to many to do. Especially the optimization of the fontawesome imports to deep imports solved the build time problem. Maybe this will help someone.

[inthegarage]

I can confirm moving to terser has done the trick as described by @mlwilkerson , the short simple steps are:

npm i terser --save-dev

and then

  "resolutions": {
    "uglify-es": "npm:terser"
  }

In your package.json

My build reduced to less than a minute. (from over several mins)

[clydin]

Please also note that version 7.0 of the CLI now uses terser by default. No additional steps are necessary.

[DiegoMGar]

Hi, i fixed this issue in my work pc using powershell instead wsl. I don't know if any of you are using the linux subsystem but the cpus are locked, you cannot parallelize, so using powershell for build and serve boosted up my times.
I am talking about: ctr+c after +40minutes to -2minutes.

[rbluethl]

Can anybody tell why this issue has been closed? Our release build still takes literally years to complete. Always hangs at "92% chunk asset optimization".

[DiegoMGar]

My issue with this was solved when I finished using Ubuntu subsystem as npm default manager, it doesn't parallelize and this task last forever.
I moved to powershell.

[gangsthub]

Can anybody tell why this issue has been closed? Our release build still takes literally years to complete. Always hangs at "92% chunk asset optimization".

@rbluethl, 92% is about where UglifyJSPlugin was being used. Updating to Angular 7 will help because a different plugin (Terser) is used. Also, you may be going out of RAM. Happened to me with a 4GB server at the beginning.

I'm still with Angular 6. This is what I'm using in production these days:

> ng build --prod --extract-css=true --sourceMap=false --aot --build-optimizer=true --vendor-chunk=true

And in development:

> ng serve --progress --open --sourceMap=true --optimization=false --aot --vendorChunk=true

• --optimization=false disables the minification using UglifyJSPlugin, wich will help you.
• And notice that it is recommended to use --aot in both processes.
• --prod --aot will reduce the build time and output size ;). See my previous comment: https://github.com/angular/angular-cli/issues/5775#issuecomment-402745894

[DiegoMGar]

-- prod is - - aot already.

[Dzhuneyt]

@gangsthub I tried --optimization=false on our internal project (which takes 2:40 minutes generally to build). It didn't bring any improvement. In fact, it increased the build time to 2:44.

It's important to note that we are using ng build --watch=true though, not ng serve (your example). Maybe the flag is only valid for the serve subcommand.

[gangsthub]

You are right, @DiegoMGar. --prod includes --aot according to the documentation.
@Dzhuneyt, I might not be getting your issue correctly: why are you using build + watch in development? I don't think it's what it is thought for. Build makes a production bundle by default: https://angular.io/cli/build

[Dzhuneyt]

@gangsthub because we have a fairly complex project that requires NGINX, Apache and forwarding these two to a static directory where the frontend source code is accessible (/dist). The "lite server" of Angular doesn't do the trick.

[tomardern]

This seems to be more of an issue if you enable source maps. The following setup/commands work under Angular 7:

SourceMap settings in angular.json

"sourceMap": {
    "hidden": true,
    "scripts": true,
    "styles": true
}

Using the following command:

node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build --es5BrowserSupport=true --prod=true --aot --build-optimizer=true --output-hashing all --extract-css=true --output-path=./tmp/dist

It will stick at 92% for a while, but does eventually build.

[ishaan-puniani]

Well, in my case the the process was terminating because of insufficient memory.
I enabled swapping on build server and then it works perfectly fine.

[aijazkhan81]

Can we open this issue back again?

[vitaminac]

I got this error when i built in docker in Window, i changed the limit of memory to 4GB in virtualbox configuracion and it works for me.

[Stradivario]

I think we are facing this issue since Reflect metadata API is now part of the build process of angular, so we will have more computation input but the application will be more faster.I am trying to use some work around building it with Parcel since 1 GB ram is really not enough building complex angular project these days even with 4 GB of swap...

It will be really useful if we have cache output from the build so we can then attach this cache to Docker container and only the changes will be build instead the whole application.Yes some will say it will trigger more problems with cache but it depends on how well is written ;)

[geniusunil]

Angular-cli 7.1.2 using terser only, removed uglify. The problem is still the same. I don't understand why this issue is closed.

[ssarkisy]

MacBook Pro 2017 (max configuration). On my colleague's laptop, it took like 6 times longer.
Angular-cli 7.3.8
ng build --prod --aot

Date: 2019-05-22T14:17:10.865Z
Hash: c46f53e11f136ebcccaf
Time: 252612ms
chunk {0} common.afc1032bf3c4b8275ad0.js (common) 13.3 kB [rendered]
chunk {1} 1.a15ce621172a345de3fb.js () 17.7 kB [rendered]
chunk {2} 2.2f5ed724319337a8e568.js () 35.4 kB [rendered]
chunk {3} 3.60e537acc75ac058b27c.js () 18.4 kB [rendered]
chunk {4} runtime.579f6773a2b26d94db5d.js (runtime) 3.55 kB [entry] [rendered]
chunk {5} 5.347c1f3685ec3ba82396.js () 22.5 kB [rendered]
chunk {6} main.9181a4cb2e65813f8502.js (main) 4.3 MB [initial] [rendered]
chunk {7} polyfills.7b3fb56fc82120d2029f.js (polyfills) 61.7 kB [initial] [rendered]
chunk {8} styles.268c785458aec578546e.css (styles) 326 kB [initial] [rendered]
chunk {9} 9.cf61d9ddb5622467f3f3.js () 31 kB [rendered]
chunk {10} 10.0cd72c145b577e65cf28.js () 5.3 kB [rendered]
chunk {11} 11.9dfeb2dd944fe80224cf.js () 98.6 kB [rendered]
chunk {12} 12.8aa7c4e6cdd6615f2014.js () 7.07 kB [rendered]
chunk {13} 13.8999e86ed963ef839840.js () 29 kB [rendered]
chunk {14} 14.8cf84a196f45ed341ce0.js () 5.31 kB [rendered]
chunk {15} 15.d313fabcfc0d0a86d25d.js () 18.7 kB [rendered]
chunk {16} 16.3bb6114bc3541835e4a0.js () 6.38 kB [rendered]
chunk {17} 17.7c5dbc1fbe2336666081.js () 18.4 kB [rendered]
chunk {18} 18.709082325c1f7cbbd1b9.js () 5.32 kB [rendered]
chunk {19} 19.f75679cd15753e642ace.js () 5.32 kB [rendered]
chunk {20} 20.ead991d5d12b29a5c046.js () 23.2 kB [rendered]
chunk {21} 21.b19be2caaa1019c1d5a8.js () 5.32 kB [rendered]
chunk {22} 22.b8710a26bd79a8f2d9d5.js () 6.36 kB [rendered]
chunk {23} 23.31688d97f4b9eb3e8b7d.js () 5.31 kB [rendered]
chunk {24} 24.4ddab1995018ff5b7989.js () 6.34 kB [rendered]
chunk {25} 25.604287facfdf4d4ef67c.js () 5.34 kB [rendered]
chunk {26} 26.7da604b902f6832785fa.js () 38 kB [rendered]
chunk {27} 27.bdbbe5cfd351f05fb927.js () 44.5 kB [rendered]
chunk {28} 28.8d1645bad2f255229883.js () 6.36 kB [rendered]
chunk {29} 29.cae28ed727cef99550da.js () 18.2 kB [rendered]
chunk {30} 30.0757b5c5e76726394c96.js () 36.1 kB [rendered]
chunk {31} 31.f70fcde5f461f52b298f.js () 24.6 kB [rendered]
chunk {32} 32.f6a13d5d31d0811486c1.js () 5.32 kB [rendered]
chunk {33} 33.2f77b41e9e23b60d7a4c.js () 5.34 kB [rendered]
chunk {34} 34.75833ca150c5c8fdd6bd.js () 5.32 kB [rendered]
chunk {35} 35.c57bcf3e34e617dfabc6.js () 6.35 kB [rendered]
chunk {36} 36.5fa2d920b12f46a07172.js () 6.35 kB [rendered]
chunk {37} 37.a394ec89e4d0bf0d72a6.js () 6.36 kB [rendered]
chunk {38} 38.b34cc886a6eaa8be42a7.js () 5.37 kB [rendered]
chunk {39} 39.ffa574e6aed984aef474.js () 18 kB [rendered]
chunk {40} 40.30389c2e462dcd3da05f.js () 6.36 kB [rendered]
chunk {41} 41.8e53571d710cc118d3a7.js () 6.35 kB [rendered]
chunk {42} 42.1489d4775a8537d8cf61.js () 23 kB [rendered]
chunk {43} 43.d986a7e4817dc6559e1c.js () 30.8 kB [rendered]
chunk {44} 44.416ca46085d6452e2aae.js () 56.9 kB [rendered]
chunk {45} 45.807652b30c9ae86f81df.js () 48.8 kB [rendered]
chunk {46} 46.0b5ed5eb48ede6e2a472.js () 59.3 kB [rendered]
chunk {47} 47.23e8ca78a06e5de3029b.js () 51.2 kB [rendered]
chunk {48} 48.61a69980e6f487c0562c.js () 20.1 kB [rendered]
chunk {49} 49.b10ef4d1f7cad8e72cd1.js () 20.8 kB [rendered]
chunk {50} 50.9ad9e94f088ad56d6dd8.js () 23.6 kB [rendered]
chunk {51} 51.121732df2f2a4fcee042.js () 5.32 kB [rendered]
chunk {52} 52.d288a7457b03303af53c.js () 5.3 kB [rendered]
chunk {53} 53.a26d29e5795cb20db1c3.js () 36.1 kB [rendered]
chunk {54} 54.985c05de0e4736723d6e.js () 5.33 kB [rendered]
chunk {55} 55.577c2d061a42d919bbce.js () 6.67 kB [rendered]
chunk {56} 56.46d02993596d7be5fcc6.js () 42.5 kB [rendered]
chunk {57} 57.f182f866ab2ff39159a8.js () 58.9 kB [rendered]
chunk {58} 58.aac5f7b34340b2766b37.js () 63.3 kB [rendered]
chunk {59} 59.c6d03497f0a9fc3e2920.js () 5.3 kB [rendered]
chunk {scripts} scripts.df23d47c2e627c65cf17.js (scripts) 262 kB [entry] [rendered]

[Ni55aN]

Angular 8. The same issue

[Ni55aN]

Running with node --max-old-space-size=8192 node_modules/@angular/cli/bin/ng build --prod --aot doesn't help

[bleuscyther]

reduce --max-old-space-size=8192 , i had to use --max-old-space-size=4096 or lower : 2048, 1024... depending on the host

[inthegarage]

@bleuscyther Really only any use for small projects, will seriously impair large projects. Still if you have a small project, then this is the setting for you.

[kdubious]

@filipesilva This seemed to be an issue you understood well. Is the issue back? Should this be re-opened?

[renatop7]

I'm using WSL Ubuntu 18.04, tried everything others commented in this thread and I can't build my Angular 7 project.
Eventually I gave up and now I'm using powershell to build it...

[majid-rehman]

This help me solve the problem on t2.micro ,, max time 2 minutes

create swap

sudo /bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=3024
sudo /sbin/mkswap /var/swap.1
sudo chmod 600 /var/swap.1
sudo /sbin/swapon /var/swap.1

If you need more or less than 3024 then change that to something you want.

To enable it by default after reboot, add this line to /etc/fstab:

/var/swap.1 swap swap defaults 0 0

After doing all these run below command

ng build --prod --build-optimizer=false

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