AOT build fails due to "JavaScript heap out of memory"

Bug Report or Feature Request (mark with an `x`)

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

Versions.

@angular/cli: 1.0.0
node: 7.7.4
os: win32 x64
@angular/animations: 4.0.0
@angular/common: 4.0.0
@angular/compiler: 4.0.0
@angular/core: 4.0.0
@angular/flex-layout: 2.0.0-rc.1
@angular/forms: 4.0.0
@angular/http: 4.0.0
@angular/material: 2.0.0-beta.2
@angular/platform-browser: 4.0.0
@angular/platform-browser-dynamic: 4.0.0
@angular/router: 4.0.0
@angular/cli: 1.0.0
@angular/compiler-cli: 4.0.0

Repro steps.

ng build --prod --aot

The log given by the failure.

/node_modules/@angular/material/aut 92% chunk asset optimization
<--- Last few GCs --->

[6328:0000016AB4D09F00]  1775597 ms: Mark-sweep 1411.2 (1513.5) -> 1411.0 (1513.5) MB, 1240.6 / 0.0 ms  last resort


<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0000034B0DD266A1 <JS Object>
    2: optimize [0000000FABC02311 <undefined>:5480] [pc=00000082575652C8](this=000000633199A279 <an AST_Call with map 0000014753FA0291>,compressor=00000226DBDECA61 <a Compressor with map 0000032B1EC8F829>)
    3: before [0000000FABC02311 <undefined>:5463] [pc=0000008258C1818D](this=00000226DBDECA61 <a Compressor with map 0000032B1EC8F829>,node=000000633199A279 <an AST_Call with map 0000014753...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

Desired functionality.

I would like to be able the app using AOT.

Mention any other details that might be useful.

I have tried changing ng.cmd to this:

@IF EXIST "%~dp0\node.exe" (
  "%~dp0\node.exe" --max_old_space_size=8192 "%~dp0\..\@angular\cli\bin\ng" %*
) ELSE (
  @SETLOCAL
  @SET PATHEXT=%PATHEXT:;.JS;=;%
  node --max_old_space_size=8192 "%~dp0\..\@angular\cli\bin\ng" %*
)

and ngc.cmd to:

@IF EXIST "%~dp0\node.exe" (
  "%~dp0\node.exe" --max_old_space_size=8192 "%~dp0\..\@angular\compiler-cli\src\main.js" %*
) ELSE (
  @SETLOCAL
  @SET PATHEXT=%PATHEXT:;.JS;=;%
  node --max_old_space_size=8192 "%~dp0\..\@angular\compiler-cli\src\main.js" %*
)

I have 8GB swap file. The build fails after 20-25 minutes standing on 92% progress.

@TheLarkInn

Thanks for getting me that CPU profile. So most of the time is spent on some array operations. It seems that this is happening as part of webpack module detection. All of the operations that take a long time happen on webpack/lib/optimizer/RemoveParentModulesPlugin.js.

@TheLarkInn does this ring a bell to you? I wonder if it's some kind of circular import problem.

@pleerock what version of webpack comes up when you do npm ls webpack btw?

npm ls webpack

└─┬ @angular/cli@1.6.2
  └── webpack@3.10.0

Try —stacksize 2048 Cordialement, Amine BIZID

…

Le 3 janv. 2018 à 10:58, Umed Khudoiberdiev ***@***.***> a écrit : We still have this issue. We had this issue since ***@***.*** when I first time used angular CLI. Then I switched to angular starter and everything worked. Now Im trying to use angular cli again on the same project (upgrade from angular 4) and now I still have same issue with angular 5.1 and cli 1.6.2. We have a really huge project and we are using angular on this project from early versions of angular since 2013. When I simply use ng build build is going 1 hour. Here is a log. When I use ng build -prod or ng build -prod -aot I always have an error (after few minutes of build): ng build -prod -aot 10% building modules 3/3 modules 0 active <--- Last few GCs ---> [30628:0x102804600] 151498 ms: Mark-sweep 1405.8 (1664.5) -> 1405.8 (1664.5) MB, 1634.9 / 0.0 ms allocation failure GC in old space requested [30628:0x102804600] 152767 ms: Mark-sweep 1405.8 (1664.5) -> 1405.7 (1616.5) MB, 1268.5 / 0.0 ms last resort [30628:0x102804600] 154066 ms: Mark-sweep 1405.7 (1616.5) -> 1405.7 (1601.0) MB, 1298.4 / 0.0 ms last resort <--- JS stacktrace ---> ==== JS stack trace ========================================= Security context: 0x14c9d8b1cef1 <JSObject> 1: set [native collection.js:~247] [pc=0x2fa4affd9607](this=0x166929284d21 <Map map = 0x20d66a1183b9>,p=0xb60e511a3c9 <NodeObject map = 0x78bae661b01>,x=0x3ce8d86d6ce9 <Object map = 0x3647e82a689>) 3: record ***@***.***/compiler-cli/src/transformers/node_emitter.js:135] [bytecode=0x214b10b7f429 offset=37](this=0x166929284ce9 <_NodeEmitte... FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory 1: node::Abort() [/usr/local/bin/node] 2: node::FatalException(v8::Isolate*, v8::Local<v8::Value>, v8::Local<v8::Message>) [/usr/local/bin/node] 3: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/usr/local/bin/node] 4: v8::internal::Factory::NewFixedArray(int, v8::internal::PretenureFlag) [/usr/local/bin/node] 5: v8::internal::OrderedHashTable<v8::internal::OrderedHashMap, 2>::Rehash(v8::internal::Handle<v8::internal::OrderedHashMap>, int) [/usr/local/bin/node] 6: v8::internal::Runtime_MapGrow(int, v8::internal::Object**, v8::internal::Isolate*) [/usr/local/bin/node] 7: 0x2fa4afe040dd Abort trap: 6 If you want to know how many code and files we have: cloc ./src/ 2705 text files. 2680 unique files. https://github.com/AlDanial/cloc v 1.66 T=12.20 s (219.4 files/s, 17125.4 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- TypeScript 2662 21207 15921 143472 CSS 4 4084 203 18682 SASS 6 772 305 4144 JSON 3 0 0 68 HTML 1 8 5 25 ------------------------------------------------------------------------------- SUM: 2676 26071 16434 166391 ------------------------------------------------------------------------------- — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

What version of NodeJs are you running here? If < 8.9, would you mind testing and reprofiling. There is significant work done in V8 with garbage collection that surfaced in that version of node that we collaborated with the V8 team on.

@TheLarkInn

@TheLarkInn updated from v8.4.0 to v9.3.0.
Profiled first 12 minutes of RemoveParentModulesPlugin execution:

CPU-20180105T160658.cpuprofile.zip

@JaapMosselman

@JaapMosselman the chunk asset optimization in prod builds is when module concatenations and Uglification happen. This are the optimizations that reduce your bundle size by analyzing code and dropping unused one.

It is slow by it's very nature, but #8668 (merged but waiting for 1.7 to be released) will help by running Uglify in parallel.

@pleerock I've been looking at Webpack 4 and thought maybe it could help since there are a lot of performance improvements there. The plugin in question has suffered some changes:

in webpack@3.10.0: https://github.com/webpack/webpack/blob/b545b519b2024e3f8be3041385bd326bf5d24449/lib/optimize/RemoveParentModulesPlugin.js
in webpack@4.0.0-alpha.3: https://github.com/webpack/webpack/blob/9334fd8547831ded7f11e05319616a72ea0b4698/lib/optimize/RemoveParentModulesPlugin.js

It looks like there's a fair bit of optimizations changes there. But I'm not sure if the bottleneck has changed.

There's two places where time is being spent on your CPU profile:

a has call inside the hasModule function:
a filter call inside the hasModule function:

This function hasn't changed though so I don't think it would speed up your case. I'm going to open an issue in webpack about this.

EDIT: opened as webpack/webpack#6248

Started getting this issue last month, did try so many workarounds and got it working after upgrading to angular-cli 1.6.2. But the build started taking about 45 minutes, made it difficult to push new builds. But at least it was working. Now getting the issue again, and this time, it only works occasionally. And when it works it still takes about an hour. I am guessing the issue started occurring after the codebase grew above some threshold, before this, the build used to take ~10 mins.
Is there a way to get over the frequent build failures. This is the output I am getting:

92% chunk asset optimization<--- Last few GCs --->

[34132:0000025213C0DB90]  2282774 ms: Mark-sweep 1401.9 (1713.9) -> 1401.9 (1699.9) MB, 1637.6 / 0.0 ms  last resort GC in old space requested


<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0000037423C25EE1 <JSObject>
    2: visit [0000033FF8602311 <undefined>:7667] [bytecode=0000002651BE0769 offset=620](this=0000038789453039 <TreeWalker map = 0000020B4AB1BD21>,node=000001D6E5AAD121 <AST_VarDef map = 000002C8A2BBA649>,descend=0000001D6E073821 <JSFunction (sfi = 000003D9CF111AF9)>)
    4: _visit [0000033FF8602311 <undefined>:1512] [bytecode=000003D9CF10CF99 offset=57](this=0000038789453039 <TreeWalker map = ...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

Angular Version: 4.2.4
Angular-cli Version: 1.6.2
TypeScript Version: 2.3.4
Node Version: 8.9.3
npm Version: 5.5.1

This are the number of individual files:

      2 gif
      1 gitkeep
    252 html
      1 ico
      5 jpg
      1 js
      6 json
    110 png
    390 scss
    509 ts

Any guidance will be much appreciated. Stuck at this no build situation for the last 24 hours 😕

@sabeersulaiman

@sabeersulaiman have you tried setting a npm script for increasing the memory available? I mentioned it in #5618 (comment).

If you still have very long builds (10+ minutes) and have a repro available, I'd love to look into it.

@filipesilva

@filipesilva that did the trick. I tried it but I think I mistakenly tried --max-old-space-size instead of --max_old_space_size. It works fine now and only takes ~4 min. And about ~8 min on CI server. Thanks.

I have made some research and according to this both --max-old-space-size and --max_old_space_size syntax are valid. Here is a link in nodel documentation about --max-old-space-size. Also I found some people complain that first approach is not working, but obliviously both should work.

@filipesilva

@filipesilva Im able to do build using webpack3, latest angularcli and it takes 1 hour with node 8 as we discussed.

Now, Im trying to build production version using build --prod and having a memory error on 92%:

node --max_old_space_size=16384 ./node_modules/@angular/cli/bin/ng "build" "--prod"

 10% building modules 5/6 modules 1 active ...du.dev/src/assets/css/styles-prod.cssNode#mo  92% chunk asset optimization                                                      <--- Last few GCs --->

[633:0x102804600]  6440993 ms: Scavenge 3626.0 (4651.3) -> 3611.8 (4651.3) MB, 28.9 / 0.0 ms  allocation failure 
[633:0x102804600]  6441072 ms: Scavenge 3627.1 (4651.3) -> 3612.5 (4651.3) MB, 26.6 / 0.0 ms  allocation failure 
[633:0x102804600]  6452624 ms: Mark-sweep 4189.7 (4899.4) -> 3245.2 (4747.3) MB, 344.1 / 0.0 ms  (+ 3081.6 ms in 990 steps since start of marking, biggest step 6.3 ms, walltime since start of marking 4825 ms) finalize incremental marking via stack guard G

<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x27d30fb25ee1 <JSObject>
    1: flatten_args(aka flatten_args) [0x27d3efb02311 <undefined>:~11681] [pc=0x372b5a5bba0e](this=0x27d3efb02311 <undefined>,fn=0x27d3b7e0fe01 <AST_Function map = 0x27d444b33ab1>,scope=0x27d3b7e0f631 <AST_Function map = 0x27d411240269>)
    3: /* anonymous */(aka /* anonymous */) [0x27d3efb02311 <undefined>:11627] [bytecode=0x27d350f41949 offset=5456](this=0x27d3efb02311 <undefined>,self=0x27d4...

FATAL ERROR: invalid table size Allocation failed - JavaScript heap out of memory
 1: node::Abort() [/usr/local/bin/node]
 2: node::FatalException(v8::Isolate*, v8::Local<v8::Value>, v8::Local<v8::Message>) [/usr/local/bin/node]
 3: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/usr/local/bin/node]
 4: v8::internal::HashTable<v8::internal::StringTable, v8::internal::StringTableShape>::EnsureCapacity(v8::internal::Handle<v8::internal::StringTable>, int, v8::internal::PretenureFlag) [/usr/local/bin/node]
 5: v8::internal::StringTable::LookupKey(v8::internal::Isolate*, v8::internal::StringTableKey*) [/usr/local/bin/node]
 6: v8::internal::StringTable::LookupString(v8::internal::Isolate*, v8::internal::Handle<v8::internal::String>) [/usr/local/bin/node]
 7: v8::internal::LookupIterator::LookupIterator(v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Name>, v8::internal::LookupIterator::Configuration) [/usr/local/bin/node]
 8: v8::internal::LookupIterator::PropertyOrElement(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, bool*, v8::internal::LookupIterator::Configuration) [/usr/local/bin/node]
 9: v8::internal::Runtime_KeyedGetProperty(int, v8::internal::Object**, v8::internal::Isolate*) [/usr/local/bin/node]
10: 0x372b54a8463d
11: 0x372b5a5bba0e

If you have the time, can you try with CLI 1.7.0-beta.0?

@clydin

Looks like something got better, build times reduced by 50% in my project + memory consumption as well (for single node process) , although I think I see more node processes being spawned. @clydin : what was fixed?

@pleerock

@pleerock about --max-old-space-size and --max_old_space_size. node 8.9.3 on Windows gives me the following error while using --max-old-space-size

 $ npm run start

> test@0.0.0 start C:\Projects\test
> node --max-old-space-size=8192 ./node_modules/.bin/ng serve

C:\Projects\test\node_modules\.bin\ng:2
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
          ^^^^^^^

SyntaxError: missing ) after argument list
    at createScript (vm.js:80:10)
    at Object.runInThisContext (vm.js:139:10)
    at Module._compile (module.js:599:28)
    at Object.Module._extensions..js (module.js:646:10)
    at Module.load (module.js:554:32)
    at tryModuleLoad (module.js:497:12)
    at Function.Module._load (module.js:489:3)
    at Function.Module.runMain (module.js:676:10)
    at startup (bootstrap_node.js:187:16)
    at bootstrap_node.js:608:3
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! test@0.0.0 start: `node --max-old-space-size=8192 ./node_modules/.bin/ng serve`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the test@0.0.0 start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\sabee\AppData\Roaming\npm-cache\_logs\2018-01-13T04_47_40_099Z-debug.log

Is this supposed to happen or is it an issue with the way I configured it ?

@filipesilva

@filipesilva I was able to build site using webpack4 (with fixes applied by webpack team) + aot using your branch in 40 minutes. But for some reason index.html is not emitted (even with regular dev build)

This error happen with cli 1.6.2

node --max_old_space_size=12288 ./node_modules/.bin/ng build --prod

use this command works for me

updated to @angular/cli@1.6.4
but still the same error 'FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory'

This started happening for us. How can this happen when I have locked down all my angular versions? Does the CLI not follow the proper versioning? Is there any fix for this?

@Sarfarazsajjad

@Sarfarazsajjad and @sabeersulaiman are you trying with 64 bit node or 32 bit node?

64 bit node with --max_old_space_size should build fine for large applications in --prod mode.

@clydin

I tried what @clydin said, using 1.7.0-beta.0 worked like a charm, it did cut my building time from over 30 minutes to 3 minutes.
Thank you angular-cli team.

I did also a test run with 1.7.0-beta.0. The build time dropped from 13 minutes to 6.5 minutes (on my not to fast build machine). On my dev machine it builds now in 3.6 minutes (with 1.6.0 it was 7.8 minutes).
The size of the main bundling increased a little from 2653 to 2664 KB.
I needed to add @angular-devkit/core as a dev dependency to my package, else it would not be installed automatically.

i had to move from angular-cli 1.5.0 to 1.6.7 to resolve my build memory bug (without setting --max_old_space_size)

@clydin

I tried what @clydin said, using 1.7.0-beta.0 worked like a charm, it did cut my building time from over 30 minutes to 3 minutes.
Thank you angular-cli team.

For me, 1.7.0-beta.3 not work. Still get:

Security context: 0x3926bacfb39 <JS Object>
    2: write [/node_modules/typescript/lib/typescript.js:~9597] [pc=0x93487866c7f] (this=0x10feca1f0819 <an Object with map 0x98bc5b8c929>,s=0x39beab773a79 <String[2]: i4>)
    3: pipelineEmitExpression(aka pipelineEmitExpression) [/node_modules/typescript/lib/typescript.js:~69005] [pc=0x93487876ff7] (this=0x3926ba04381 <undef...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

Angular CLI: 1.7.0-beta.3
Node: 6.10.1
OS: darwin x64
Angular: 5.2.4
... common, compiler, compiler-cli, core, forms, http
... platform-browser, platform-browser-dynamic, router

@angular/cli: 1.7.0-beta.3
@angular-devkit/build-optimizer: 0.2.0
@angular-devkit/core: 0.2.0
@angular-devkit/schematics: 0.2.0
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.10.0-beta.3
@schematics/angular: 0.2.0
@schematics/package-update: 0.2.0
typescript: 2.6.2
webpack: 3.10.0

update global and local Angular Cli to 1.7.0-rc.0 work for me

update global Angular Cli

npm uninstall -g @angular/cli
npm cache clean --force
npm install -g @angular/cli@1.7.0-rc.0

update local Angular Cli
npm install @angular/cli@1.7.0-rc.0

I'd be careful with rc.0 - it corrupts some assets in aot builds e.g. fonts. I think it's been fixed but there hasn't been a release yet.

Using @angular/cli@1.7.0-rc.0 DID NOT fix the issue.

Workaround: "ng-high-mem": "node --max_old_space_size=8192 ./node_modules/@angular/cli/bin/ng", as mentioned had to be used.

This is something which needs to be fixed guys.

Just give it more memory. It is inevitable that the process consumes more and more memory as the project size grows. There's no way around that. The only thing that (probably) will fix this is https://bazel.build, but that's still quite far in the future.

So, the fix imho is that ng just adds some node flags by default and let's call it a day.

It's not inevitable. It does point to a fundamental flaw in the build architecture. If we default the --max_old_space_size=8192 flag, how large of a project will this build until that value is too small?

I'm just being practical, the build uses heavily webpack, node etc. and a lot of other dependencies that may not be trivial to rewrite. The change to bazel is coming, so how many man years should be put into this old build pipeline?

As long as the memory requirement is not outrageous, I'd like to vote the effort to be put into something else, as there are a lot of things that need attention. It's 2018, so I don't think 4 or 8 gigs of memory is that much.

I also don't think that many users would have noticed that the build uses 4 gigs of memory if that was the default.

That said, I'll shut up now ;)

I think something is kind of messed up with the SASS processing which might be contributing to these issues (definitely for dev builds but I'm not 100% sure for aot).

Essentially there seems to be something weird happening with sass de-duplication. In my project I had a common sass file with a bunch of includes (bootstrap and stuff). This is liberally included across component scss files with the expectation it would be de-duplicated in the build.

However I realized my dev build was up to 150MB for the main.bundle.js and it was hammering my workstation when it built. By re-structuring the scss to only include was was necessary in each component I bought this down to like 11MB.

For the aot build it was less significant (I think most of the size was from sourcemaps) but still went from:

Date: 2018-02-15T16:02:33.684Z
Hash: 41fbbec562aa54786309
Time: 208050ms
chunk {scripts} scripts.d12170c009efb4ef2dbb.bundle.js (scripts) 209 kB [initial] [rendered]
chunk {0} main.0cafaa559bb3700ad50f.bundle.js (main) 18.4 MB [initial] [rendered]
chunk {1} polyfills.700d53c47d7964ae8cad.bundle.js (polyfills) 169 kB [initial] [rendered]
chunk {2} styles.c77032e78777d8b73cfb.bundle.css (styles) 282 kB [initial] [rendered]
chunk {3} inline.27eae89520a68a8b4864.bundle.js (inline) 1.45 kB [entry] [rendered]

to

Date: 2018-02-15T15:56:45.830Z
Hash: 147dec00b5e7c81037ed
Time: 155488ms
chunk {scripts} scripts.d12170c009efb4ef2dbb.bundle.js (scripts) 209 kB [initial] [rendered]
chunk {0} main.9b030cbd40e05afd9bf7.bundle.js (main) 3.17 MB [initial] [rendered]
chunk {1} polyfills.700d53c47d7964ae8cad.bundle.js (polyfills) 169 kB [initial] [rendered]
chunk {2} styles.c77032e78777d8b73cfb.bundle.css (styles) 282 kB [initial] [rendered]
chunk {3} inline.5c3035ae831e1473f3d7.bundle.js (inline) 1.45 kB [entry] [rendered]

I tried to track the memory usage as well. It seemed like with the improved scss it maxd out at about 1300MB memory to do the aot build. With the old scss setup it was similar but briefly spiked up to over 2.5GB at the end of the process. So it could be that memory useage is also affected by the duplicated scss.

(I'm using cli v1.7.0-beta.0 btw. rc.0 breaks my fonts in aot).

edit: slightly more scientific readout of memory usage:

Inefficent scss includes:

More efficent scss:

Not much in it really.

also improved scss with cli v1.7.0-rc.0 instead of beta.0:

and v1.6.8:

I've installed increase-memory-limit and after I run it, although it ran successfully and it changed the files in the local project folder (I checked the files), the ram usage was still somewhere 1400 mega bytes and not more.

What I did after that is. I went to the folder where npm is installed which in my case was

C:\Users\USER\AppData\Roaming\npm

and I opened ng.cmd and edited it and added --max-old-space-size=10240 in both places (in the if and else clause)

Only after I did that and tried ng build --prod it started to use more ram.

Here in the photo you can see that I'm running two command prompts. The first one is after I ran increase-memory-limit, and the second one is after I edited the ng.cmd file manually. You can see that it started to use 3000 mega bytes.

Before doing this edit, the rare times that it worked (to build the project) it took me 660s and now it did it for 295s.

I hope it will help you.

@ZgjimDida

@ZgjimDida its working for me for @angular/cli@1.6.8 after added --max-old-space-size=10240 in both places

Updating typescript version in package.json to the latest 2.4.x to 2.7.x, fixed the issue for me

Adding SWAP will help in solving this error?

@kanji-keraliya

@kanji-keraliya I'm glad I could help.

@FOSSKolkata

@FOSSKolkata
But I'm getting the warning of > @angular/compiler-cli@5.2.5 requires a peer of typescript@>=2.4.2 <2.7 but none is installed. You must install peer dependencies yourself.

my project compiles on local machines but not in the CI due out of memory errors (8gb ram , 2gb swap).
setting max-old-space-size is not a viable option for our CI pipelines.

solved updating typescript to 2.7.x but a nasty warning about 'ng compiler not supporting that version of typescript' shows up.

this is an issue for us too;
we are using a hosted VSTS build environment;

node: v 8.x
npm: 5.6.0
@angular/cli: 1.7.2

I tried running npm install -g increase-memory-limit && increase-memory-limit prior to running the build command (node ./node_modules/@angular/cli/bin/ng build --prod --e=beta --sourcemaps=true), but it did not help. I still get OOM error as indicated above.

EDIT: updating the build command to the following, seems to have 'fixed' the issue.
node --max_old_space_size=10240 ./node_modules/@angular/cli/bin/ng build --prod --e=beta --sourcemaps=true

Facing the same issue.. Tried increasing the memory allocation which resolved this for a while, but after couple of days, things have started to fail again continuously.

Increasing the memory limit might just be a patch and never resolve what is causing this. Any idea?

it seems that they dont care about this.

@roymj88

@roymj88 Largely the performance issues have stemmed from build optimizations introduced in webpack that were incredibly expensive in terms of RAM usage for build. At least two of these issues were found and resolved in webpack itself, in part through the help of members of the angular-cli team.

So think it's really important to state what version you're using, as it may have been fixed for you, and roughly how large your project is. As depending on your size you will hit that wall eventually. Where the total build time and I think RAM usage does scale at least linearly with number of files.

So a quick-fix is indeed to simply increase the RAM usage even further. Alternatives to that:

Isolate the issue into a public repository or simply share your code if that is possible. Will help them a lot in trying to triage the issue.
Turn off build-optimizer (it's on by default for production). If you're not concerned about payload size of your app turning this flag off will likely speed up your production build significantly.
Upgrade to Angular 6 beta and angular-cli 6 beta. The latest version uses Webpack 4 along with some other optimizations that supposedly should make builds faster.

it seems that they dont care about this.

@Aindigo I think that's incorrect. There are steady performance improvements both in the cli and more importantly in Webpack, which the angular-cli sometimes contribute themselves. Bazel as an alternative to Webpack will very likely become a very much more performant alternative while version 6 does seem to come with a fair share of improvements to the build speed in general.

You could argue for different prioritization, with the big drawback of delaying other improvements and features like Service Workers and schematics.

Regardless, think the team is doing an awesome job and hope to continue see improvements in version 6 and onwards.

@Koslun

@Koslun
The versions are as follows:

angular-cli: 1.2.4
angular: 4.1.3
npm: 3.10.8
node: v6.9.1

The memory limit has been stretched to a whopping 2GB(2097152) and the builds are still failing with the heap memory issue after 92%.

BTW, why is this closed?

Regards
Roy

@roymj88

@roymj88 try the latest version. You got 1.2.4 while it's 1.7.3 out there with the improvements discussed in the thread above.

@DenisVuyka Are you sure the above issue is resolved with the latest version i.e 1.7.0? Upgrading to the latest version may have dependency issues and upgrading instantly may not be a choice that we can do right-away.

@roymj88

@roymj88 might require increasing the RAM to 4 or 8, maybe rely on swap if you don't have enough RAM. What is reasonable RAM usage partly depends on the size of your project. Supply the approximate size of your project. How many thousand lines of code?

However agree with @DenisVuyka . If you want any optimizations you will have to upgrade to the latest version of angular-cli. Which should likely include upgrading to Angular 5 and node 8.x. If you're not using angular universal/ssr, service-workers or specific libraries tied to older versions it shouldn't be too much effort.

If you're not using it, you should also use yarn or npm lock files if you want to avoid dependencies unexpectedly breaking under you.

In my experience leaving the --sourcemaps flag out fixes this issue during AOT compilation of larger projects and honestly what do we even need sourcemaps for in production.

@Flexicon

@Flexicon Thanks for the tip. We like to include --sourcemaps on our beta/test environment, but build with the --prod flag so the bits are the same as in production environment. I agree, no need for sourcemaps in production.

we were able to sort this out upgrading angular-cli in the package.json file to 1.6.7, and leaving typescript on 2.3.4 so the compiler does not warn about un-supported versions

This issue is still present even when upgrading CLI and TS to latest versions. Come on guys...

Regarding increasing available memory:

gulp handles node flags already. ng could do the same, with the help of https://www.npmjs.com/package/flagged-respawn. This module respawns the node process if v8 flags are present.

Until then the workaround for both Linux & Windows machines is running ng as node --max_old_space_size=4096 node_modules/@angular/cli/bin/ng build ...

bump.

Angular 5 and Node 8.9.1, but I have the circular dependency in-app maybe problem there are?

<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x19dcc2825ec1 <JSObject>
    1: _walk [0x19dcad702311 <undefined>:~1071] [pc=0x12ea75770373](this=0x19dc87984ec9 <AST_Call map = 0x19dcfb2fecc9>,visitor=0x19dcdb7e1571 <TreeWalker map = 0x19dc6a53c489>)
    2: /* anonymous */ [0x19dcad702311 <undefined>:~1226] [pc=0x12ea7547d7f7](this=0x19dc87984f01 <AST_ObjectKeyVal map = 0x19dcfb2fd359>)
    3: _walk [0x19dcad702311 <undefined>:~1225] [pc=0x12ea756e0c33](this=0x19dc87...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [/usr/local/bin/node]
 2: node::FatalException(v8::Isolate*, v8::Local<v8::Value>, v8::Local<v8::Message>) [/usr/local/bin/node]
 3: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/usr/local/bin/node]
 4: v8::internal::Factory::NewByteArray(int, v8::internal::PretenureFlag) [/usr/local/bin/node]
 5: v8::internal::TranslationBuffer::CreateByteArray(v8::internal::Factory*) [/usr/local/bin/node]
 6: v8::internal::compiler::CodeGenerator::PopulateDeoptimizationData(v8::internal::Handle<v8::internal::Code>) [/usr/local/bin/node]
 7: v8::internal::compiler::CodeGenerator::FinalizeCode() [/usr/local/bin/node]
 8: v8::internal::compiler::PipelineImpl::FinalizeCode() [/usr/local/bin/node]
 9: v8::internal::compiler::PipelineCompilationJob::FinalizeJobImpl() [/usr/local/bin/node]
10: v8::internal::Compiler::FinalizeCompilationJob(v8::internal::CompilationJob*) [/usr/local/bin/node]
11: v8::internal::OptimizingCompileDispatcher::InstallOptimizedFunctions() [/usr/local/bin/node]
12: v8::internal::StackGuard::HandleInterrupts() [/usr/local/bin/node]
13: v8::internal::Runtime_StackGuard(int, v8::internal::Object**, v8::internal::Isolate*) [/usr/local/bin/node]
14: 0x12ea7490463d
15: 0x12ea75770373
16: 0x12ea7547d7f7
Abort trap: 6

@ar53n

@ar53n - I have circular dependencies defined in my application amongst my models, but those give a warning at compile time, since they will only give an error at run time and you actually create your models with the circular dependencies implemented (which shouldn't be the case).

I got my AOT build working with the solution provided by @awerlang:

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

My exact build command based on my preferences:

node --max_old_space_size=4096 node_modules/@angular/cli/bin/ng b -op aot -sm -v -aot

My versions:
Angular CLI: 1.7.2
Node: 6.9.5
Angular: 5.2.7

How are people still having issues with this? Using the 1.7.2 build of @angular/cli works perfectly without changing the memory flag. This is on both a computer with an old i3 and 8gb ram as well as an amd fx6350 with 32gb ram.

@mast3rd3mon

@mast3rd3mon - well from my comments above, you can see I'm using the same angular-cli version, thus ruling that out.

I'm running an i7 4810MQ w/ 16GB ram, which is irrelevant since if I modify the memory flags I can get an AOT build working

@jarodsmk

@jarodsmk then explain how the very low spec i3/8gb ram computer works fine on 1.7.2? its evidently a lot lower spec than your machine and has only half the ram but works fine? Based on the fact that some people need the flag and some dont, i suspect its more of a computer issue than cli issue

@mast3rd3mon

@mast3rd3mon It depends on how big your project is.

Just a reminder that the memory consumption grows the more typescript / html files it has to analyze. At some point your project will grow over the limit and you need the flag. It's not about the machine.

The cli has been optimized, so the newer ones can cope more files, but still in the end it will run out off memory on larger projects.

Memory consumption is (mainly) determined by two factors - the cli version and the size & complexity of your project.

@mast3rd3mon

@mast3rd3mon , regarding what @swftvsn mentioned:

I have a rather complex enterprise-level project I'm working on, with many components and modules.

Actually I could get both of my big projects to compile with ng build --prod --base-href ./ --aot if I add --sm then both build fail. This is with latest angular cli (both global and project) and latest typescript (both global and project).

@jarodsmk so do i, its currently at around 20 modules, 3 normal components (to use with the html selector), around 10 service files and around 15 interfaces, it builds fine on the i3/8gb ram build without the memory flag. I would say that its very complex

…

@makdeniss

@makdeniss - Yea, adding the source map parameter is a common issue because the memory requirements when generating them on larger projects can be enormous.

But on a debug/qa build, adding source maps could be beneficial

@mast3rd3mon

@mast3rd3mon

I have 8 modules with approximately 89 components, 20 services, a number of interfaces and I believe around 52 model classes, failing with or without sourcemaps

@jarodsmk

@jarodsmk both of my projects are bigger and removing that --sm and also upgrading to the latest deps for ts and cli (and of course ng) solved the js memory error.

@makdeniss

Hmm, we're having 60 components, 5 own modules, 47 3rd party modules imported and about 50 services. I consider this to be a really simple app compared to some of the enterprise stuff I've worked with.

What does the --sm flag do @makdeniss ?

@swftvsn

@swftvsn source maps. better debugging posibilities, but for prod this is not needed anyways.

@makdeniss

@makdeniss hmm interesting, I've tried updating my ts & cli (local on a different branch and global) but didn't change anything

@jarodsmk

@jarodsmk how are you building the project? I didn't change any npm memory flags btw. All is as default.

@makdeniss

@makdeniss
So these fail:
ng b -op aot -aot -sm -v
ng b -op aot -aot -v

But I resorted to:
node --max_old_space_size=4096 node_modules/@angular/cli/bin/ng b -op aot -aot -sm -v

Which worked. Interesting that setting the max_old_space_size to 4gb helped

@jarodsmk

@jarodsmk it should help, because you are giving in more memory. This is a workaround, but a hacky one.

I ran into a this issue today, but I saw it when attempting to perform a regular ng build. It would stop at 10% and hang until the error occurred. Allocating more memory did allow it to build. I found this issue on typescript (microsoft/TypeScript#14628) and one of the comments led me to changing the tsconfig.app.json.

tsconfig.app.json

"include": [
    "src",
    "typedefs"
],

This appears to have fixed the issue. However, the tests will still not work and I have not been able to add anything to the tsconfig.spec.json to get them working.

Environment:

angular-cli: 1.3.1
node: 8.10.0
os: macOS 10.12.6

I've been following this thread for a while, but not sure if this has been mentioned before.

In my case, I'm doing the auto-rebuild stuff. So when I make a modification in my source, it'll rebuild and reload the browser page. The initial startup build always works, but after doing approximately 20 or more modifications and therefore rebuilds, I end up getting the out of memory error.

I have a fairly small project so it isn't the issue that the project itself will build and hit a memory limit. I ran into the memory issue after 10 or more repeated builds were run in TeamCity. Restarting the build agent/server got things back to normal, so it seems that memory is not being cleared after each build and eventually aggregating toward the limit.

fix(@ngtools/webpack): remove app decorators on AOT

fix(@angular/cli): update webpack, uglifyjs-webpack-plugin

@Ericdowney

@Ericdowney angular-cli 1.3.1 is quite old in this context. A lot has happened since then until 1.7.x. And a lot more is about to happen when they release 6.x. Might want to either switch to 1.7.x now and then use ng update to update to 6.x when that comes out and you also want to migrate to Angular 6.

I wouldn't expect any fixes or help with angular cli version 1.3.1. Maybe version 6 will have similar LTS support but would always assume the latest version to give the best experience.

I previously had this error on Angular 5 with --aot flag and then it went away with the updates to @angular/cli. I have now upgraded to Angular 6 and the issue is back :/. I'm using:

ng serve myapp --prod

 "serve": {
          "builder": "@angular-devkit/build-angular:dev-server",
          "configurations": {
            "production": {
              "optimization": true,
              "aot": true,
              "vendorChunk": false
            }
          }

And it fails with:

** Angular Live Development Server is listening on localhost: 4200, open your browser on http://localhost:4200/ **
 90% chunk assets processing
<--- Last few GCs --->

[19772:000001E2123ECE00]    95613 ms: Mark-sweep 1404.0 (1506.8) -> 1404.0 (1503.8) MB, 1021.6 / 0.0 ms  (+ 0.0 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 1130 ms) last resort GC in old space requested
[19772:000001E2123ECE00]    96624 ms: Mark-sweep 1404.0 (1503.8) -> 1404.0 (1503.8) MB, 1010.8 / 0.0 ms  last resort GC in old space requested


<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 000000B751F25EE1 <JSObject>
    2: declareVarName [c:\dev\FitRockApp\node_modules\acorn\dist\acorn.js:2831] [bytecode=0000036F39CCD189 offset=32](this=0000016629E387F9 <Parser map = 0000000C4C3050C1>,name=0000016629E37629 <String[33]: styles_DietTemplatesPageComponent>)
    4: checkLVal [c:\dev\FitRockApp\node_modules\acorn\dist\acorn.js:1749] [bytecode=0000036F39CCC539 offset=325](this=0000016629E387F9 <Parser map = 000...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node_module_register
 2: v8::internal::FatalProcessOutOfMemory
 3: v8::internal::FatalProcessOutOfMemory
 4: v8::internal::Factory::NewTransitionArray
 5: v8::internal::EhFrameIterator::DecodeSLeb128
 6: v8::internal::JSReceiver::GetOwnPropertyDescriptor
 7: v8::internal::JSReceiver::GetOwnPropertyDescriptor
 8: v8::internal::JSReceiver::GetOwnPropertyDescriptor
 9: v8::internal::JSReceiver::class_name
10: v8::internal::JSReceiver::GetOwnPropertyDescriptor
11: v8::internal::LookupIterator::PrepareTransitionToDataProperty
12: v8::internal::JSReceiver::class_name
13: v8::internal::ParserBase<v8::internal::Parser>::MarkLoopVariableAsAssigned
14: v8::internal::ParserBase<v8::internal::Parser>::MarkLoopVariableAsAssigned
15: 000000DA23D847A1

Any ideas how to fix these? It works fine when aot is disabled.

@Enngage

@Enngage
You can replace this line:

ng serve myapp --prod

with one of the following alternatives

Alternative 1:
Create this npm script entry:

"ng-high-mem": "node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng",

You can then in your console write:

npm run ng-high-mem -- serve myapp --prod

Alternative 2:
Run this in the console:

node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng serve myapp --prod

@Koslun

Thank you @Koslun for this complete example. I went with the 1st approach and works well! I'm curious as to why this isn't mentioned anywhere in docs. This seems like any reasonably sized project would have to do anyway.

@Enngage

@Enngage think it's cause the goal is that this is never really supposed to happen. Where having to use this can often also instead be the result of some regression in angular-cli, Webpack or even Node, such as this fixed but unreleased regression in Node: nodejs/node#19769.

Given that this issue itself has the tag FAQ and the traffic it's garnered I agree that it might be worthwhile to add it to some FAQ in the documentation.

Have the same issue and sudo node --max-old-space-size=4096 /usr/local/bin/ionic cordova build android --prod didn't help. I'm using MacOs. Any advice ?

I am following this way: Inspect the bundles and I have the same error:
"devDependencies": { "@angular/cli": "^1.7.2", "@angular/compiler-cli": "^5.2.9",

ng build --prod --sourcemaps
92% chunk asset optimization
<--- Last few GCs --->
[6360:0000000000398AE0] 1741315 ms: Mark-sweep 1399.2 (1647.1) -> 1398.3 (1648.6) MB, 1257.4 / 0.0 ms allocation failure GC in old space requested
[6360:0000000000398AE0] 1742847 ms: Mark-sweep 1398.3 (1648.6) -> 1398.1 (1603.1) MB, 1530.9 / 0.0 ms last resort GC in old space requested
[6360:0000000000398AE0] 1744175 ms: Mark-sweep 1398.1 (1603.1) -> 1398.1 (1595.1) MB, 1328.2 / 0.0 ms last resort GC in old space requested
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 0000018821D25EE1
1: exec(this=00000156D3AF9AA9 <JSRegExp <String[53]: /** PURE_IMPORTS_START (\S+) PURE_IMPORTS_END */>>,000003A248D4D541 <Very long string[6384078]>)
3: getMatches(aka getMatches) [C:\Users\Utente\Desktop\Workspace\rebus5\node_modules@angular-devkit\build-optimizer\src\purify\purify.js:48] [bytecode=000003F790876209 offset=16](this=000000FCE1C02311 ,str=000003A248D4D54...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
1: node_module_register
2: v8::internal::FatalProcessOutOfMemory
3: v8::internal::FatalProcessOutOfMemory
4: v8::internal::Factory::NewRawTwoByteString
5: v8::internal::Smi::SmiPrint
6: v8::internal::AllocationSpaceName
7: v8::internal::RegExpImpl::Exec
8: v8::internal::RegExpImpl::Exec
9: v8::internal::ParserBasev8::internal::Parser::MarkLoopVariableAsAssigned
10: 00000231754047A1

@lippomano Try this. It solved the issue.

My angular version is 5.1.1
Node version : 8
Npm version: 5

I have tried these command for AOT build even though i'm getting this ERROR JavaScript heap out of memory

ng build --prod
ng build --aot
"build": "node --max_old_space_size=5048 ./node_modules/@angular/cli/bin/ng build --prod",[I have play round the size also]

Can you please any one knows how to solve this bug.

I've had the same issue and the only way I have solved it is to unfortunately use this flag: --build-optimizer=false

@Marudhuraj

@Marudhuraj Other than turning off build-optimizer, turning off source maps can also help. Would otherwise also in general recommend updating to latest angular-cli to get the best performance as well as ensure you're on Node version 8.11.2 or higher as there's a performance regression affecting Webpack builds of some versions below that in the 8.x series.

@joshuwhi

@joshuwhi @Koslun My personal experience was I was encountering this issue after 5 or more builds of the same app in succession on a team city agent. I have an opportunity to set up my CI on the latest Node, NPM, and Angular and will find some time in the next week or so to set up just the boilerplate ng new app building periodically throughout the day to see if the suggested dev environment versions mentioned here actually no longer reproduce the issue.

@Marudhuraj

@Marudhuraj
I solved this issue by doing the following step:

I used the command "npm run build" which internally uses "ng build"
I update my "ng.cmd" file at following location "\UI\node_modules.bin" (UI being the project folder) by this code
=================
@if EXIST "%~dp0\node.exe" (
"%~dp0\node.exe" --max_old_space_size=8192 "%~dp0..@angular\cli\bin\ng" %*
) ELSE (
@SETLOCAL
@set PATHEXT=%PATHEXT:;.JS;=;%
node --max_old_space_size=8192 "%~dp0..@angular\cli\bin\ng" %*
)
================

this is basically adding more memory for node to execute
3. Update the package.json file, by doing following steps:
replace
"build": "ng build",
by this:
"build": "ng build --prod --build-optimizer",

Thanks
Vijay

@aryavijay

Hi @aryavijay ,
Now i'm getting this error, how to resolve the app module factory error

ERROR in ./src/app/app.module.ngfactory.js
Module not found: Error: Can't resolve 'ngx-store/dist/src/service/local-storage.service' in 'C:\Users\a811891\taskmanagementv2ui\src\app' resolve 'ngx-store/dist/src/service/local-storage.service' in 'C:\Users\a811891\taskmanagementv2ui\src\app' Parsed request is a module using description file: C:\Users\a811891\taskmanagementv2ui\package.json (relative path: ./src/app) Field 'browser' doesn't contain a valid alias configuration after using description file: C:\Users\a811891\taskmanagementv2ui\package.json (relative path: ./src/app) resolve as module C:\Users\a811891\taskmanagementv2ui\src\app\node_modules doesn't exist or is not a directory C:\Users\a811891\taskmanagementv2ui\src\node_modules doesn't exist or is not a directory C:\Users\a811891\node_modules doesn't exist or is not a directory C:\Users\node_modules doesn't exist or is not a directory C:\node_modules doesn't exist or is not a directory looking for modules in C:\Users\a811891\taskmanagementv2ui\node_modules using description file: C:\Users\a811891\taskmanagementv2ui\package.json (relative path: ./node_modules) Field 'browser' doesn't contain a valid alias configuration after using description file: C:\Users\a811891\taskmanagementv2ui\package.json (relative path: ./node_modules) using description file: C:\Users\a811891\taskmanagementv2ui\node_modules\ngx-store\package.json (relative path: ./dist/src/service/local-storage.service) no extension Field 'browser' doesn't contain a valid alias configuration C:\Users\a811891\taskmanagementv2ui\node_modules\ngx-store\dist\src\service\local-storage.service doesn't exist .ts

I'm a noob, but this solved my problem,

Instead of:
ng build --prod

I wrote:
ng build --env prod

and it worked...

Please inform me if this answere is not good an why so i can expand my knowledge :)
Thanks.

@yaadm

@yaadm I think the --env only sets the environment.ts file, it doesn't set all the other production mode settings that --prod sets.

With Angular 6 the build time up from 600 seconds to 900 😞

I have the same issue.

ng build --configuration=production

with a production configuration that looks like this

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

fails with

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

But setting the flag: --max_old_space_size=8192 makes it work.

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

Node version: v8.11.3
Npm version: 6.3.0

any solution to this ? ....

read my comment or screenshare.....

@aryavijay

@aryavijay I feel like setting max_old_space_size in various places is not really a solution, but rather a workaround.
This was not an issue before I upgraded the project and cli to angular 6.

I am having the same issue, but it only occurs if I have "sourceMap": true, in angular.json, otherwise it builds just fine.

I've just hit into this issue as well after upgrading to v6. It was working fine before. ):

Is anyone else having problem with the build in 79% ModuleConcatenationPlugin? It's taking a long time and consuming a lot of memory.

This issue makes us unable to upgrade @angular-devkit/build-angular from 0.6 to either 0.7 or 0.8.

What is even worse, all mentioned workarounds (buildOptimizer: false, sourceMap: false, --max_old_space_size=8192) do not work for our project.

On "@angular-devkit/build-angular": "0.6.3" everything works fine.

I successfully build and serve with

node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng serve --aot

but when i open my browser i got an error

ERROR Error: Uncaught (in promise): Error: Cannot find module 'app/pages/login/login.module'.
Error: Cannot find module 'app/pages/login/login.module'

with this version
Angular CLI: 1.5.2
Node: 6.10.3
@angular/.DS_Store: error
@angular/cdk: 5.2.5
@angular/cli: 1.5.2
@angular-devkit/build-optimizer: 0.0.42
@angular-devkit/core: 0.8.1
@angular-devkit/schematics: 0.0.52
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.8.2
@schematics/angular: 0.1.17
typescript: 2.4.2
webpack: 3.8.1

i am tired with changing url in modules and changing versions last 48 hours. please help me.

@iyashiyas

@iyashiyas your issue seems unrelated to memory issues.

@iyashiyas

@iyashiyas your issue seems unrelated to memory issues.

without node --max_old_space_size=8192 am getting
error JavaScript heap out of memory

@iyashiyas

@iyashiyas yes, so the workaround works well in your case and the "Cannot find module" error has nothing to do with this.

Run the command through Node.js. That fixed my issue.

For anyone experiencing "JavaScript heap out of memory" when running a build:

I just upgraded to Angular 6 from 5 today and started getting these when building my universal server. I was on @nagular-devkit/angular-build: 0.8.0-rc8 and it kept failing. Downgrading to 0.6.3 worked as per: #5618 (comment)

Reverting sourcemaps as it now fails on out of memory:

@filipesilva

@filipesilva Any debug way for us to figure out which big files cause huge memory use?

This issue was fixed - at least for our project - in Angular 7.0.0-rc.0. I guess the CLI consumes less memory in that version...

If you are still on Angular 6 and using Docker:

RUN node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build -- configuration=${NG_CONFIGURATION};

This worked for my team's project. We may consider using 4096 or even 2048 if that works for us.

@jiminikiz

@jiminikiz You can check how much memory the build process takes to determine how much memory you need to allocate to it.

For example, if the process takes at max 3GB RAM, then you can allocate 4GB instead of the 8GB you're allocating now.

Hi guys,

I am working in an app that is being developed with Visual Studio. How can I set --max_old_space_size=8192 and where?

I am publishing the project with publish option so I don't know where to set it.

Please any help?

p.s. If I comment

"aot": true

(and "buildOptimizer": true because it depends on aot) I can publish the project.

before i face problem with java heap out of memory
and i run code with increasing memory but i failed with module error..
and i upgraded to angular 6 and successfully build with --prod mode

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

Else you can set your angular.json
"build-prod": "node --max_old_space_size=8192 'node_modules/@angular/cli/bin/ng' build --prod ",

and call build-prod in u r command

now i am using --prod its more power full other than aot

Hi guys,

I am working in an app that is being developed with Visual Studio. How can I set --max_old_space_size=8192 and where?

I am publishing the project with publish option so I don't know where to set it.

Please any help?

p.s. If I comment

"aot": true

(and "buildOptimizer": true because it depends on aot) I can publish the project.

I want to test my prod version with

"serve-prod": "ng serve --prod --build-optimizer",

Where can I add --max_old_space_size=819 because right now Im getting

The option '--max_old_space_size' is not registered with the serve command. Run `ng serve --help` for a list of supported options.

Really need some help

Thx

Does this not work for you?
node --max_old_space_size=8192 'node_modules/@angular/cli/bin/ng' build --prod --build-optimizer

The --max_old_space_size argument is for node, not ng

Just want to highlight something I said in #6795 (comment) because it happlies here as well:

Increasing the memory limit is not a hack, and something you should expect to do at some point. Node processes have a default memory limit of about 1.7gigs. When a node process starts getting close to the memory limit it needs to spend more and more time doing garbage collection to free up memory, which in turn makes it run more slowly.

Bigger projects will use up more memory than smaller projects so at some point a project will hit the memory limit. I personally use a npm script for this:

"ng-high-memory": "node --max_old_space_size=8000 ./node_modules/@angular/cli/bin/ng",

It's hard to act on many of these reports since there is no objective reproduction that we can follow. It's not that we don't believe that builds can be slow. But builds can be slow for many reasons. It's exceedingly likely that the projects that are seeing the most dramatic build times are suffering from some odd problem somewhere in the pipeline that is not a general problem, and for those we really need to reproduce it to fix it.

General performance improvements are of course always helpful, and we try to do them as much as possible. But the absolute best way of getting us to fix issues, especially hard to fix ones, is to offer concrete repros.

@filipesilva

@filipesilva everybody says that we have to use "hack" and solutions, but not where we can put that in an automated publishing file.

Can we use that in angular.json and where?

this is my angular.json right now:

{
  "$schema": "./node_modules/@angular/cli/lib/config/schema.json",
  "version": 1,
  "newProjectRoot": "projects",
  "projects": {
    "ClientApp": {
      "root": "",
      "sourceRoot": "src",
      "projectType": "application",
      "prefix": "app",
      "schematics": {},
      "targets": {
        "build": {
          "builder": "@angular-devkit/build-angular:browser",
          "options": {
            "outputPath": "dist",
            "index": "src/index.html",
            "main": "src/main.ts",
            "polyfills": "src/polyfills.ts",
            "tsConfig": "src/tsconfig.app.json",
            "assets": [
              "src/favicon.ico",
              "src/assets"
            ],
            "styles": [
              "src/styles.css"
            ],
            "scripts": []
          },
          "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
            }
          }
        },
        "serve": {
          "builder": "@angular-devkit/build-angular:dev-server",
          "options": {
            "browserTarget": "ClientApp:build"
          },
          "configurations": {
            "production": {
              "browserTarget": "ClientApp:build:production"
            }
          }
        },
        "extract-i18n": {
          "builder": "@angular-devkit/build-angular:extract-i18n",
          "options": {
            "browserTarget": "ClientApp:build"
          }
        },
        "test": {
          "builder": "@angular-devkit/build-angular:karma",
          "options": {
            "main": "src/test.ts",
            "polyfills": "src/polyfills.ts",
            "tsConfig": "src/tsconfig.spec.json",
            "karmaConfig": "src/karma.conf.js",
            "styles": [
              "src/styles.css"
            ],
            "scripts": [],
            "assets": [
              "src/favicon.ico",
              "src/assets"
            ]
          }
        },
        "lint": {
          "builder": "@angular-devkit/build-angular:tslint",
          "options": {
            "tsConfig": [
              "src/tsconfig.app.json",
              "src/tsconfig.spec.json"
            ],
            "exclude": [
              "**/node_modules/**"
            ]
          }
        }
      }
    },
    "ClientApp-e2e": {
      "root": "e2e/",
      "projectType": "application",
      "targets": {
        "e2e": {
          "builder": "@angular-devkit/build-angular:protractor",
          "options": {
            "protractorConfig": "e2e/protractor.conf.js",
            "devServerTarget": "ClientApp:serve"
          },
          "configurations": {
            "production": {
              "devServerTarget": "ClientApp:serve:production"
            }
          }
        },
        "lint": {
          "builder": "@angular-devkit/build-angular:tslint",
          "options": {
            "tsConfig": "e2e/tsconfig.e2e.json",
            "exclude": [
              "**/node_modules/**"
            ]
          }
        }
      }
    }
  },
  "defaultProject": "ClientApp"
}

where can I put that to make it build?

Thank you very much.

@dobrinsky

@dobrinsky the code sample I showed was an npm script. Those scripts go into the package.json file, under the scripts key:

{
  "name": "my-project",
  "version": "0.0.0",
  "scripts": {
    "ng-high-memory": "node --max_old_space_size=8000 ./node_modules/@angular/cli/bin/ng",
    "ng": "ng",
    "start": "ng serve",
    "build": "ng build",
    "test": "ng test",
    "lint": "ng lint",
    "e2e": "ng e2e"
  },

When you use have that script, you can use npm run ng-high-memory -- followed by the arguments instead of ng inside that project. Always use the double dash before arguments, otherwise they might not be parsed correctly.

@filipesilva

Thank you very much @filipesilva

It still won't work

0 info it worked if it ends with ok
1 verbose cli [ 'C:\\Program Files\\nodejs\\node.exe',
1 verbose cli   'C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js',
1 verbose cli   'run',
1 verbose cli   'build',
1 verbose cli   '--',
1 verbose cli   '--prod' ]
2 info using npm@6.4.1
3 info using node@v10.10.0
4 verbose run-script [ 'prebuild', 'build', 'postbuild' ]
5 info lifecycle client-app@0.0.0~prebuild: client-app@0.0.0
6 info lifecycle client-app@0.0.0~build: client-app@0.0.0
7 verbose lifecycle client-app@0.0.0~build: unsafe-perm in lifecycle true
8 verbose lifecycle client-app@0.0.0~build: PATH: C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin;C:\Users\Andrei\PROJECTS\Angular 6\SIGAD\SIGAD\ClientApp\node_modules\.bin;C:\Python34\;C:\Python34\Scripts;C:\Users\Andrei\algs4\java\bin;C:\ProgramData\Oracle\Java\javapath;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Users\Andrei\.dnx\bin;C:\Program Files\Microsoft DNX\Dnvm\;C:\Program Files\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files (x86)\MiKTeX 2.9\miktex\bin\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files\Microsoft SQL Server\120\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\ManagementStudio\;C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\;C:\Program Files\MATLAB\R2016a\runtime\win64;C:\Program Files\MATLAB\R2016a\bin;C:\Program Files\MATLAB\R2016a\polyspace\bin;C:\Program Files (x86)\Microsoft Emulator Manager\1.0\;C:\Program Files\Microsoft\Web Platform Installer\;C:\Program Files\Common Files\Autodesk Shared\;C:\Program Files\dotnet\;C:\Program Files (x86)\GtkSharp\2.12\bin;C:\Program Files (x86)\Skype\Phone\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\dotnet\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\nodejs\;C:\Program Files (x86)\Microsoft VS Code\bin;C:\Program Files\Git\cmd;C:\Users\Andrei\algs4\bin;C:\Users\Andrei\AppData\Local\Microsoft\WindowsApps;C:\Users\Andrei\AppData\Local\GitHubDesktop\bin;C:\Users\Andrei\AppData\Roaming\npm;C:\Users\Andrei\.dotnet\tools;%USERPROFILE%\AppData\Local\Microsoft\WindowsApps;C:\Users\Andrei\.nuget\packages\nuget.commandline\4.6.2\tools;C:\Users\Andrei\.nuget\packages\microsoft.codeanalysis.analyzers\1.1.0\tools;C:\Users\Andrei\.nuget\packages\microsoft.entityframeworkcore.tools\2.1.3\tools;C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.razor.design\2.1.1\tools;C:\Users\Andrei\.nuget\packages\microsoft.applicationinsights.windowsserver\2.7.2\tools
9 verbose lifecycle client-app@0.0.0~build: CWD: C:\Users\Andrei\PROJECTS\Angular 6\SIGAD\SIGAD\ClientApp
10 silly lifecycle client-app@0.0.0~build: Args: [ '/d /s /c', 'ng build "--prod"' ]
11 silly lifecycle client-app@0.0.0~build: Returned: code: 134  signal: null
12 info lifecycle client-app@0.0.0~build: Failed to exec build script
13 verbose stack Error: client-app@0.0.0 build: `ng build "--prod"`
13 verbose stack Exit status 134
13 verbose stack     at EventEmitter.<anonymous> (C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\index.js:301:16)
13 verbose stack     at EventEmitter.emit (events.js:182:13)
13 verbose stack     at ChildProcess.<anonymous> (C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\lib\spawn.js:55:14)
13 verbose stack     at ChildProcess.emit (events.js:182:13)
13 verbose stack     at maybeClose (internal/child_process.js:962:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:251:5)
14 verbose pkgid client-app@0.0.0
15 verbose cwd C:\Users\Andrei\PROJECTS\Angular 6\SIGAD\SIGAD\ClientApp
16 verbose Windows_NT 10.0.17763
17 verbose argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "run" "build" "--" "--prod"
18 verbose node v10.10.0
19 verbose npm  v6.4.1
20 error code ELIFECYCLE
21 error errno 134
22 error client-app@0.0.0 build: `ng build "--prod"`
22 error Exit status 134
23 error Failed at the client-app@0.0.0 build script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 134, true ]

I started seeing this on my Azure DevOps Build server after upgrading to Angular 7.

Adding the following to package.json and then calling this from my build task fixed it.

"build-prod": "node --max_old_space_size=8000 ./node_modules/@angular/cli/bin/ng build --prod

If you have this problem with quagga js library , pay attention that "@angular/service-worker" is installed before "quagga": "^0.12.1" package.

i could run with optimizejs using node --max-old-space-size=8192 ./node_modules/@ionic/app-scripts/bin/ionic-app-scripts.js build --release --prod --minifyjs --minifycss --optimizejs

@dakotamurphyucf

For people who missed @dakotamurphyucf like I did:
using increase-memory-limit package after running npm install will reduce all need to know where binary files are and will do it for all the files - which in my case is very useful since I'm running both regular build and cordova build.
I'm using it only in my CI build script since locally it runs well.
basically: npm install increase-memory-limit -g
And run the command increase-memory-limit.
Pain is gone! No more suffering (for me at least)...

Or just use export NODE_OPTIONS=--max_old_space_size=4096 which should fix it as well.

@marcj

@marcj this solution worked for me.

I set NODE_OPTIONS for windows with following command:
set NODE_OPTIONS=--max_old_space_size=4096

Installing increase-memory-limit, did not work for me on windows. I have not tried on linux/ubuntu or other OS.

@jatinderkumargupta

@jatinderkumargupta Please note that it's not enough to install increase-memory-limit, you need to run it also after npm installation of all packages has completed. I'm using windows and it worked for me.

@HarelM

Thanks @HarelM, I run that like you mentioned, but it did not work for me. May be some other problem then.

In Azure Devops I added a command line task which executes the command below prior to the ng build:

node --max-old-space-size=8192

This seems to have resolved the issue for now..

@ImranAhmed

"build-prod": "node --max_old_space_size=8000 ./node_modules/@angular/cli/bin/ng build --prod

@ImranAhmed thanks for the suggestion. However where abouts do you add it in angular.json? If I add it I get an 'Property build-prod' not allowed?

@bkarv

@bkarv

Add it to package.json under the 'scripts' section not angular.json.

If you are facing the issue with your Azure DevOps build you can then call this new script command that you just added from your AzureDevops build task.

I tried scripts but got errors. I ended up following the suggestion to export NODE_OPTIONS in OS and it worked. Many thanks

Hi all,

This thread was opened a while ago, and over time new memory problems have arisen and been solved. Meanwhile a lot of reports still appear here as comments.

Having all the feedback in a single thread makes it hard to get meaningful reports, or to inform people of what versions the regressions that affect them were fixed.

At the time of writing, there are 450 hidden comments:

Having so many hidden comments makes it hard for people to find information in anything but the latest comments. But on the other hand I don't think most people would go through all of the comments anyway. New users that see this thread mostly read the first and latest comments and lose things said in between.

So for the reasons stated above (high volume of comments, hidden comments, hard to report and inform people) I'm also locking this issue to prevent this comment from being lost as new comments come in.

Thank you to everyone that reported and helped diagnose these memory problems. If you encounter any new ones, please open a new issue so we can give that specific regression our full attention and provide a resolution for it.

So I'd like to leave the last comment in this thread as reiterating what I said in #5618 (comment), as I think that is what will help most people that find this issue:

Increasing the memory limit is not a hack, and something you should expect to do at some point. Node processes have a default memory limit of about 1.7gigs. When a node process starts getting close to the memory limit it needs to spend more and more time doing garbage collection to free up memory, which in turn makes it run more slowly.

Bigger projects will use up more memory than smaller projects so at some point a project will hit the memory limit. I personally use a npm script for this:

"ng-high-memory": "node --max_old_space_size=8000 ./node_modules/@angular/cli/bin/ng",

npm scripts scripts go into the package.json file, under the scripts key:

{
  "name": "my-project",
  "version": "0.0.0",
  "scripts": {
    "ng-high-memory": "node --max_old_space_size=8000 ./node_modules/@angular/cli/bin/ng",
    "ng": "ng",
    "start": "ng serve",
    "build": "ng build",
    "test": "ng test",
    "lint": "ng lint",
    "e2e": "ng e2e"
  },

When you use have that script, you can use npm run ng-high-memory -- followed by the arguments instead of ng inside that project. Always use the double dash before arguments, otherwise they might not be parsed correctly.

Navigation Menu

Repository navigation

AOT build fails due to "JavaScript heap out of memory" #5618

Bug Report or Feature Request (mark with an `x`)

Versions.

Repro steps.

The log given by the failure.

Desired functionality.

Mention any other details that might be useful.

Can you please any one knows how to solve this bug.

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

AOT build fails due to "JavaScript heap out of memory" #5618

Description

Bug Report or Feature Request (mark with an x)

Versions.

Repro steps.

The log given by the failure.

Desired functionality.

Mention any other details that might be useful.

Activity

filipesilva commented on Jan 3, 2018

pleerock commented on Jan 3, 2018

aminebizid commented on Jan 3, 2018

TheLarkInn commented on Jan 4, 2018

pleerock commented on Jan 5, 2018

filipesilva commented on Jan 5, 2018

sabeersulaiman commented on Jan 8, 2018

filipesilva commented on Jan 8, 2018

sabeersulaiman commented on Jan 9, 2018

pleerock commented on Jan 12, 2018

pleerock commented on Jan 12, 2018

clydin commented on Jan 12, 2018

dragonflypl commented on Jan 12, 2018

sabeersulaiman commented on Jan 13, 2018

pleerock commented on Jan 13, 2018

rainstormza commented on Jan 16, 2018

Sarfarazsajjad commented on Jan 18, 2018

rafiwardak2003 commented on Jan 19, 2018

Satyadatla commented on Jan 19, 2018

nadhir-falta commented on Jan 19, 2018

JaapMosselman commented on Jan 23, 2018

mcherb commented on Feb 7, 2018

smiera commented on Feb 12, 2018

kanji-keraliya commented on Feb 15, 2018

warmans commented on Feb 15, 2018

PsyGik commented on Feb 15, 2018

swftvsn commented on Feb 15, 2018

kdubious commented on Feb 15, 2018

swftvsn commented on Feb 15, 2018

warmans commented on Feb 15, 2018

ZgjimDida commented on Feb 15, 2018

kanji-keraliya commented on Feb 16, 2018

FOSSKolkata commented on Feb 16, 2018

vasanthm-bx commented on Feb 16, 2018

ZgjimDida commented on Feb 16, 2018

jobnte commented on Feb 21, 2018

pavildon commented on Mar 6, 2018

joshvito commented on Mar 7, 2018

roymj88 commented on Mar 12, 2018

pavildon commented on Mar 12, 2018

Koslun commented on Mar 13, 2018

roymj88 commented on Mar 16, 2018

DenysVuika commented on Mar 16, 2018

roymj88 commented on Mar 16, 2018

Koslun commented on Mar 16, 2018

Flexicon commented on Mar 22, 2018

joshvito commented on Mar 22, 2018

pavildon commented on Mar 26, 2018

makdeniss commented on Mar 27, 2018

awerlang commented on Mar 28, 2018

jarodsmk commented on Apr 10, 2018

ar53n commented on Apr 11, 2018

jarodsmk commented on Apr 11, 2018

mast3rd3mon commented on Apr 11, 2018

jarodsmk commented on Apr 11, 2018

mast3rd3mon commented on Apr 11, 2018

Flood commented on Apr 11, 2018

swftvsn commented on Apr 11, 2018

jarodsmk commented on Apr 11, 2018

makdeniss commented on Apr 11, 2018

mast3rd3mon commented on Apr 11, 2018

jarodsmk commented on Apr 11, 2018

jarodsmk commented on Apr 11, 2018

makdeniss commented on Apr 11, 2018

swftvsn commented on Apr 11, 2018

makdeniss commented on Apr 11, 2018

jarodsmk commented on Apr 11, 2018

makdeniss commented on Apr 11, 2018

jarodsmk commented on Apr 11, 2018

makdeniss commented on Apr 11, 2018

Ericdowney commented on Apr 17, 2018

Bug Report or Feature Request (mark with an `x`)