Angular-cli: AOT build fails due to "JavaScript heap out of memory"

[ghost]

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.

[filipesilva]

This is similar to https://github.com/angular/angular-cli/issues/1652, but seems localized to AOT compilations. There might be improvements we can do to help.

[iuristona]

I got the same issue too.

So, I tried to build the same project (@angular 4.0.0) using ng-cli 1.0.0-rc.4 and it works fine.
ng build --prod --aot

@angular/cli: 1.0.0-rc.4
node: 6.9.5
os: win32 x64
@angular/common: 4.0.0
@angular/compiler: 4.0.0
@angular/core: 4.0.0
@angular/forms: 4.0.0
@angular/http: 4.0.0
@angular/platform-browser: 4.0.0
@angular/platform-browser-dynamic: 4.0.0
@angular/router: 4.0.0
@angular/cli: 1.0.0-rc.4
@angular/compiler-cli: 4.0.0

[ghost]

I also want to add that even though I try to increase max_old_space_size by editing ng.cmd and ngc.cmd, it seems like the node.js process never uses more than 1600 MB of RAM according to the process monitor on my system, which is well within the limit i setup of 8192 MB and it still says "out of memory".

[tonny008]

I have the same issue. my project works on cli rc.4. it fails when ng build --prod after update to 1.0.0.

[aminebizid]

I'm so afraid there will be no solution for this issue.
I reverted to rc.2 because of this :(

[efstathiosntonas]

In my case, I installed [email protected] instead of @~2.2.0 and the memory issue went away. Give it a try.

There is an issue in ~2.2.0 and @angular/language-service 4.0.0 (in my case i use it)

[AngelVlc]

I've changed max_old_space_size in %AppData%npm (Windows) and it works for me when launching ng serve with 1.0.0.

[aminebizid]

@efstahiosntonas are you using ng4?

[efstathiosntonas]

@zigzag95 yes, ng4

[elvisbegovic]

same problem here

[ghost]

Thanks @AngelVlc !

Changing limit in ng.cmd under %appdata% did the trick! Now node.js uses around 4GB of RAM and the build is completed.

[chrisnicola]

I'm getting OOM errors with @ngtools/webpack 1.3.0 and @angular 4.0.0. This is on OSX and not Windows as well.

<--- Last few GCs --->

   17671 ms: Mark-sweep 1241.3 (1413.6) -> 1241.3 (1413.6) MB, 615.1 / 0.0 ms [allocation failure] [GC in old space requested].
   18286 ms: Mark-sweep 1241.3 (1413.6) -> 1241.3 (1413.6) MB, 614.2 / 0.0 ms [allocation failure] [GC in old space requested].
   18897 ms: Mark-sweep 1241.3 (1413.6) -> 1249.0 (1410.6) MB, 610.8 / 0.0 ms [last resort gc].
   19484 ms: Mark-sweep 1249.0 (1410.6) -> 1256.6 (1410.6) MB, 586.6 / 0.0 ms [last resort gc].


<--- JS stacktrace --->

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

Security context: 0x51588dcfb51 <JS Object>
    1: /* anonymous */ [/Users/chrisnicola/src/wealthbar/node_modules/webpack/node_modules/enhanced-resolve/lib/UnsafeCachePlugin.js:~28] [pc=0x33d385eb70d4] (this=0xd76ce5e1e71 <a Resolver with map 0x20b5bd9fe3f1>,request=0x3f6f1fa5ec39 <an Object with map 0x1fbc4c2b91c1>,callback=0xfd0ab9f8a9 <JS Function (SharedFunctionInfo 0x395f78d2a061)>)
    2: applyPluginsParallelBailResult1 [/Users/chri...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [/usr/local/Cellar/node/6.9.1/bin/node]
 2: node::FatalException(v8::Isolate*, v8::Local<v8::Value>, v8::Local<v8::Message>) [/usr/local/Cellar/node/6.9.1/bin/node]
 3: v8::Utils::ReportApiFailure(char const*, char const*) [/usr/local/Cellar/node/6.9.1/bin/node]
 4: v8::Utils::ApiCheck(bool, char const*, char const*) [/usr/local/Cellar/node/6.9.1/bin/node]
 5: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/usr/local/Cellar/node/6.9.1/bin/node]
 6: v8::internal::Factory::NewInternalizedStringImpl(v8::internal::Handle<v8::internal::String>, int, unsigned int) [/usr/local/Cellar/node/6.9.1/bin/node]
 7: v8::internal::InternalizedStringKey::AsHandle(v8::internal::Isolate*) [/usr/local/Cellar/node/6.9.1/bin/node]
 8: v8::internal::StringTable::LookupKey(v8::internal::Isolate*, v8::internal::HashTableKey*) [/usr/local/Cellar/node/6.9.1/bin/node]
 9: v8::internal::StringTable::LookupString(v8::internal::Isolate*, v8::internal::Handle<v8::internal::String>) [/usr/local/Cellar/node/6.9.1/bin/node]
10: v8::internal::LookupIterator::LookupIterator(v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Name>, v8::internal::LookupIterator::Configuration) [/usr/local/Cellar/node/6.9.1/bin/node]
11: 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/Cellar/node/6.9.1/bin/node]
12: v8::internal::Runtime::GetObjectProperty(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>) [/usr/local/Cellar/node/6.9.1/bin/node]
13: v8::internal::Runtime_KeyedGetProperty(int, v8::internal::Object**, v8::internal::Isolate*) [/usr/local/Cellar/node/6.9.1/bin/node]
14: 0x33d384d092a7
[1]    9536 abort      npm start

[marcalj]

Same problem here with:

@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

[Ristaaf]

I have the same problem when running "ng build -w"
@angular/cli: 1.0.0
node: 7.8.0
@angular/* 4.0.2

setting --max_old_space_size=8192 works for me, but it is not really a good solution since I cannot redistribute it with the source code to my developers.

One note though, there are both a ng.cmd and an ng file (the latter one is an sh file), and if you are in windows as we are both can be used depending on if you run ng from git bash or cmd so both needs to be changed.

My solution to the problem will probably be to change the npm build command from ng build to call a copy of the ng bash file which I distribute with my code.

[omeralper]

@Ristaaf How did you change the ng file? Where did you add --max_old_space_size in this file? Can you please share your file.

[Ristaaf]

@omeralper: This is my solution, it requires people to use git bash as terminal if on windows, but it would be easy to change if needed (just use the cmd file instead):

In my project root I have a folder called scripts and in it a file called ng.sh, which is a copy from node_modules/.bin/ng but with more allowed RAM to be used

#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")

case `uname` in
    *CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac

if [ -x "$basedir/node" ]; then
  "$basedir/node" --max_old_space_size=8192 "./node_modules/@angular/cli/bin/ng" "$@"
  ret=$?
else
  node --max_old_space_size=8192 "./node_modules/@angular/cli/bin/ng" "$@"
  ret=$?
fi
exit $ret

Then in my package.json I do:

"scripts": {
    "build-prod": "bash ./scripts/ng.sh build --prod --aot --env=prod"
}

[KeithGillette]

I am experiencing a similar issue resulting in a JavaScript heap out of memory error when calling ng e2e in a project using:

• @angular/[email protected]
• @angular/*@4.1.0
• [email protected]

I was able to create a cross-platform work-around by changing the package.json e2e script entry to:

    "test-browser-e2e-cucumber": "node --max_old_space_size=4096 node_modules/@angular/cli/bin/ng e2e --webdriver-update",

[speedy32]

On windows
@IF EXIST "%~dp0node.exe" (
"%~dp0node.exe" --max_old_space_size=4096 "%~dp0node_modules@angular\cli\bin\ng" %*
) ELSE (
@SETLOCAL
@SET PATHEXT=%PATHEXT:;.JS;=;%
node --max_old_space_size=4096 "%~dp0node_modules@angular\cli\bin\ng" %*
)

[dakotamurphyucf]

check this npm package out https://github.com/endel/increase-memory-limit

[isaacplmann]

I wrote a little script that lets me control the memory limit in the config section of package.json.
https://github.com/isaacplmann/angular-cli-alias

increase-memory-limit looks pretty sweet too. It didn't exist when I wrote my script and it doesn't let you set your own memory limit.

[zackschuster]

i've been able to repro this with a minimal test case using an out-of-the-box cli app; relevant file here.

basically it seems like trying to match a wildcard without specifiers will blow up the app, which is weird since the test case is pulled almost directly from typescript documentation.

note that "*": ["*"] does not crash the app, only "*": ["*", "$dir/*"]

as a workaround, i've manually specified each of my path maps, which is annoying but lets me compile:

"paths": {
  "app.*": ["app/app.*"],
  "app-*": ["app/app-*"],
  "authentication/*": ["app/authentication/*"],
  "core/*": ["app/core/*"],
  "navigation/*": ["app/navigation/*"],
  "pages/*": ["app/pages/*"]
}

[sis0k0]

We also hit that issue in NativeScript when using the @ngtools/webpack plugin with nativescript-dev-webpack. We use tsconfig paths for mapping our tns-core-modules. They look like that:

"paths": {
  "*": [
    "./node_modules/*",
    "./node_modules/tns-core-modules/*"
  ]
}

However, the bundling fails with the mentioned error (JavaScript heap out of memory). Just like @zackschuster , as a workaround we specified each path mapping manually:

"paths": {
  "application": ["node_modules/tns-core-modules/application"],
  "application-settings": ["node_modules/tns-core-modules/application-settings"],
  "camera": ["node_modules/tns-core-modules/camera"],
  "color": ["node_modules/tns-core-modules/color"],
  "connectivity": ["node_modules/tns-core-modules/connectivity"],
  "console": ["node_modules/tns-core-modules/console"],
  "data/*": ["node_modules/tns-core-modules/data/*"],
  "fetch": ["node_modules/tns-core-modules/fetch"],
  "file-system": ["node_modules/tns-core-modules/file-system"],
  "fps-meter": ["node_modules/tns-core-modules/fps-meter"],
  "globals": ["node_modules/tns-core-modules/globals"],
  "http": ["node_modules/tns-core-modules/http"],
  "image-asset": ["node_modules/tns-core-modules/image-asset"],
  "image-source": ["node_modules/tns-core-modules/image-source"],
  "location": ["node_modules/tns-core-modules/location"],
  "platform": ["node_modules/tns-core-modules/platform"],
  "text": ["node_modules/tns-core-modules/text"],
  "timer": ["node_modules/tns-core-modules/timer"],
  "trace": ["node_modules/tns-core-modules/trace"],
  "ui/*": ["node_modules/tns-core-modules/ui/*"],
  "utils/*": ["node_modules/tns-core-modules/utils/*"],
  "xhr": ["node_modules/tns-core-modules/xhr"],
  "xml": ["node_modules/tns-core-modules/xml"]
}

[zackschuster]

@sis0k0 what do your recompile times look like with that setup? i was getting 40-50s recompiles (on an absurdly tiny project) until i dropped the path maps, at which point it dropped to ~2s.

[aminebizid]

@zackschuster
What do you mean by path maps?

[zackschuster]

@zigzag95

"paths": {
 // ...
}

[sis0k0]

@zackschuster, similar times.

[tgrosh]

https://github.com/angular/angular-cli/issues/5618#issuecomment-304545043

I tried the increase-memory-limit package, and I still get Javascript heap out of memory

[ghost]

Still a problem on 4.2.6, macOS, even when giving 8GB to node.

This is a pretty serious problem... it's time to fix this.

[elvisbegovic]

It's time to fix this !!! In real big project angular is bad because of that ! Maybe webpack problem !! Thanks

[ghost]

I wonder if the solution is to AOT per module, then a separate link-step? Not sure if it's even possible to implement... In that case, what is lost in global opts, needs to be reclaimed in an LTO.

[cassianomon]

Still nothing on this?

I am using @angular/cli 1.0.0-rc.4, if I upgrade to 1.0.0 it gives me the error of
angular cli FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

[aminebizid]

Now we understand why Google don't use webpack with ng for its apps

[cimachris]

Work Around Fix
I was able to fix the issue by changing my ng.cmd file to
@IF EXIST "%~dp0\node.exe" ( "%~dp0\node.exe" --max_old_space_size=8192 "%~dp0\node_modules\@angular\cli\bin\ng" %* ) ELSE ( @SETLOCAL @SET PATHEXT=%PATHEXT:;.JS;=;% node --max_old_space_size=8192 "%~dp0\node_modules\@angular\cli\bin\ng" %* )

[Masquer]

@cimachris this is not exactly a fix but rather a workaround that can possibly postpone the problem

[cimachris]

Is that better?

[cassianomon]

@hansl @filipesilva I am not able to upgrade my application to angular/cli 1.0.0, since I am at angular/cli 1.0.0.rc-4, don't want to make the jump to the latest version without testing my components

[ghost]

@cimachris we're well beyond the "--max_old_space_size" trick working anymore. Once the app gets large enough, aot builds are impossible due to this problem. Granted, we're an extreme case, because we have lots and lots of generated components (based on screen-scraped definitions of a legacy system), but it should still build of course. This is a very serious bug IMO.

[edmund-lee]

Have been affected by this issue since @angular/cli 1.0 was released
But currently we are able to workaround it by running
ng build --aot --sourcemaps=false --environment=prod

It's not exactly the same as the --prod parameter but at least it works.

[xnnkmd]

ng e2e also results in a similar error:

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

[2164:000002C715EFDC90]   117246 ms: Mark-sweep 1401.4 (1543.7) -> 1401.3 (1545.7) MB, 1088.0 / 0.0 ms  allocation failure GC in old space requested
[2164:000002C715EFDC90]   118473 ms: Mark-sweep 1401.3 (1545.7) -> 1401.2 (1504.2) MB, 1227.0 / 0.0 ms  last resort
[2164:000002C715EFDC90]   119591 ms: Mark-sweep 1401.2 (1504.2) -> 1401.1 (1504.2) MB, 1117.8 / 0.0 ms  last resort


<--- JS stacktrace --->

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

Security context: 000000799D9A66A1 <JS Object>
    2: addMapping(aka SourceMapGenerator_addMapping) [xxx\node_modules\source-map\lib\source-map-generator.js:~94] [pc=0000003D3772300C](this=0000022DE262CAF1 <a SourceMapGenerator with map 000000A8E17906F1>,aArgs=0000005D8F791BF9 <an Object with map 00000399007FF561>)
    3: /* anonymous */ [xxx\node_modules\source-map\l...

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

[xnnkmd]

@filipesilva This is pretty serious and the workaround does not allways work - it seems to affect all medium/large projects. Needs solved for angular + angularcli to remain a viable technology for serious web projects.

[ghost]

@edmund-lee

ng build --aot --sourcemaps=false --environment=prod

It's not exactly the same as the --prod parameter but at least it works.

Doesn't work for sufficiently large projects.

[emazv72]

@angular/cli: 1.2.3
node: 6.10.0
os: linux x64
@angular/animations: 4.3.1
@angular/common: 4.3.1
@angular/compiler: 4.3.1
@angular/core: 4.3.1
@angular/forms: 4.3.1
@angular/http: 4.3.1
@angular/platform-browser: 4.3.1
@angular/platform-browser-dynamic: 4.3.1
@angular/router: 4.3.1
@angular/cli: 1.2.3
@angular/compiler-cli: 4.3.1
@angular/language-service: 4.3.1

App with 3 modules and about 50 components, after switching @angular/cli from 1.1.x to 1.2.x

ng build -target=production

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [@angular/cli]
 2: 0x109bf8c [@angular/cli]
 3: v8::Utils::ReportApiFailure(char const*, char const*) [@angular/cli]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [@angular/cli]
 5: v8::internal::Factory::NewInternalizedStringImpl(v8::internal::Handle<v8::internal::String>, int, unsigned int) [@angular/cli]
 6: v8::internal::StringTable::LookupString(v8::internal::Isolate*, v8::internal::Handle<v8::internal::String>) [@angular/cli]
 7: v8::internal::LookupIterator::PropertyOrElement(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, bool*, v8::internal::LookupIterator::Configuration) [@angular/cli]
 8: v8::internal::Runtime::GetObjectProperty(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>) [@angular/cli]
 9: 0xed3501 [@angular/cli]
10: v8::internal::Runtime_KeyedGetProperty(int, v8::internal::Object**, v8::internal::Isolate*) [@angular/cli]
11: 0x2174585092a7
Aborted (core dumped)

[emazv72]

root cause analysis:

• OOM on CI machine ( also after adding --max-old-space-size=4096 to node ) due to broken symlink

After fixing it:

ng build --prod

ERROR in ./src/main.ts Module not found: Error: Can't resolve './$$_gendir/app/app.module.ngfactory' @ ./src/main.ts 3:0-74 @ multi ./src/main.ts
`
Upgraded @angular/cli to 1.2.4, still getting the same error ( yarn )

After looking at #7125 it looked like it was an aot related, package dependency issue.
Reverting back to npm fixed it.

[zackschuster]

i've also seen this error pop up when using @ngtools/webpack by itself. interestingly, it doesn't happen until after a few rebuilds, implying there's a huge memory leak somewhere in either webpack (doubtful) or the ngtools plugin.

[RuedigerMoeller]

this is so java :))

[baio]

Same issue. As soon as project gain size this thing happens.

[etiennetalbot]

Exact same error here, but with @ngtools/webpack
I've tried running it with Node LTS 6.11.2 and Node Latest as well 8.2.1
Tried with Typescript 2.3.2 and 2.4.2.
All my angular packages are at 4.3.3

AoT is pretty much necessary for large apps, so it's kinda ironic we can't get it so build for those.

[amikitevich]

after update to angular/[email protected] have the same issue.

@angular/cli: 1.3.0
node: 8.2.1
os: darwin x64
@angular/animations: 4.3.3
@angular/common: 4.3.3
@angular/compiler: 4.3.3
@angular/core: 4.3.3
@angular/forms: 4.3.3
@angular/http: 4.3.3
@angular/platform-browser: 4.3.3
@angular/platform-browser-dynamic: 4.3.3
@angular/router: 4.3.3
@angular/cli: 1.3.0
@angular/compiler-cli: 4.3.3

command:
ng build -prod --build-optimizer --aot=true --progress=false --sourcemap

[brunobertechini]

Just as a heads up. It turns out when I use YARN instead of NPM to RESTORE packages ng build completes successfully.

I am using

ng build --env=prod --aot

When I restore packages using npm install -- same error from this issue (out of memory)
When I restore packages using yarn install -- no error - success

[blyndcide]

Also got this error after updating to @angular/cli 1.3.0.

Problem solved after upgrading typescript both locally and globally to 2.4.2

[wojciech-wator]

Also got this error.

Locking @ngtools/webpack to version 1.5.4 helps.

[josephliccini]

I had to increase memory given to Node, as well as bump TS to 2.4.2, but after that I did get a successful build. looking forward to NG5 AoT compiler

[williangd]

Same problem here after updating to @angular/cli 1.3.0.

[ChenReuven]

@williangd also for me with 1.3.0

[jloosli]

I've also been getting the out of memory issue when running ng serve. It works fine for hours, but if I've been developing for a while (I've seen it anywhere from 2-5 hours) I will get the out of memory crash. When rerunning the serve command, I can go typically for another 2-5 hours. The first time I saw this was when updating to a beta version of 1.3, but I haven't seen an improvement with the current release.

[Dunos]

For me it also happens with the normal "ng serve" after upgrading to 1.3 version, every time the project recompiles, its takes more time than the previous (6s, 10s, 30s, 60s) and after 4 or 5 times, it goes out of memory.

[AlekBro]

Same issue.

95% emitting
<--- Last few GCs --->

160332 ms: Mark-sweep 1346.8 (1439.3) -> 1346.7 (1439.3) MB, 648.6 / 0.0 ms [allocation failure] [scavenge might not succeed].
160934 ms: Mark-sweep 1346.7 (1439.3) -> 1346.8 (1439.3) MB, 602.0 / 0.0 ms [allocation failure] [scavenge might not succeed].
161564 ms: Mark-sweep 1346.8 (1439.3) -> 1346.8 (1423.3) MB, 629.5 / 0.0 ms [last resort gc].
162181 ms: Mark-sweep 1346.8 (1423.3) -> 1346.7 (1423.3) MB, 616.9 / 0.0 ms [last resort gc].

<--- JS stacktrace --->

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

Security context: 0000009DB903FA99
1: DoJoin(aka DoJoin) [native array.js:~129] [pc=000000A40AE7FE82] (this=0000009DB9004241 ,w=00000355FBAF7F99 ,J=0
000009DB904A369 2: Join(aka Join) [native array.js:180] [pc=000000A406C83FF2] (this=0000009DB9004241 ...

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

tsc -v
Version 2.4.2

@angular/cli: 1.3.0
node: 6.11.2
os: win32 x64

[sbabeal]

How is upgrading to typescript 2.4.2 working. You will get build issues from RxJs as they 2.4 broke the typings of rxjs

[sbabeal]

This problem is happening as well for our project. Can't build aot on build server with the same javascript heap out of memory. We are also using the experimental webpack 3 support.

[josephliccini]

@sbabeal just go to RxJS 5.4.2

[chriseenberg]

For us - building locally with
ng build --target=production --environment=prod --base-href /myproject/ --aot --build-optimizer
works just fine, but when we build it on our server, we get the
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
error. However, if we remove the --build-optimizer everything runs fine.

I've tried adding the increase-memory-limit library, but without any luck.

Is there a fix to this that actually works?

Kind regards Chris

[sbabeal]

Tried latest version of typescript and still didn't help. Locally it builds but consumes 1.5 gigs of memory. Seems quite excessive.

[phamtuananh791994]

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

[3933:0x2a7d710] 355436 ms: Mark-sweep 1395.8 (1546.4) -> 1395.3 (1546.4) MB, 975.3 / 0.0 ms allocation failure GC in old space requested
[3933:0x2a7d710] 356584 ms: Mark-sweep 1395.3 (1546.4) -> 1395.3 (1546.9) MB, 976.0 / 0.0 ms allocation failure GC in old space requested
[3933:0x2a7d710] 357953 ms: Mark-sweep 1395.3 (1546.9) -> 1395.3 (1539.9) MB, 1195.7 / 0.0 ms last resort
[3933:0x2a7d710] 359143 ms: Mark-sweep 1395.3 (1539.9) -> 1395.3 (1539.9) MB, 1188.8 / 0.0 ms last resort

<--- JS stacktrace --->

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

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
1: node::Abort() [@angular/cli]
2: 0x12b717c [@angular/cli]
3: v8::Utils::ReportOOMFailure(char const, bool) [@angular/cli]
4: v8::internal::V8::FatalProcessOutOfMemory(char const, bool) [@angular/cli]
5: v8::internal::Factory::NewCode(v8::internal::CodeDesc const&, unsigned int, v8::internal::Handle, bool, bool, int, bool) [@angular/cli]
6: v8::internal::CodeGenerator::MakeCodeEpilogue(v8::internal::MacroAssembler, v8::internal::EhFrameWriter, v8::internal::CompilationInfo, v8::internal::Handle) [@angular/cli]
7: v8::internal::FullCodeGenerator::MakeCode(v8::internal::CompilationInfo, unsigned long) [@angular/cli]
8: v8::internal::FullCodegenCompilationJob::ExecuteJobImpl() [@angular/cli]
9: v8::internal::CompilationJob::ExecuteJob() [@angular/cli]
10: 0xd577dc [@angular/cli]
11: 0xd59faa [@angular/cli]
12: 0xd5b7a9 [@angular/cli]
13: v8::internal::Compiler::Compile(v8::internal::Handle, v8::internal::Compiler::ClearExceptionFlag) [@angular/cli]
14: v8::internal::Runtime_CompileLazy(int, v8::internal::Object*, v8::internal::Isolate) [@angular/cli]
15: 0x3e6ef29040c7
Aborted (core dumped)

[linkevin777]

We seem to face the error even on allocating 12GB of memory for the build.
Is there any way to debug what is causing the memory leak? also, could this be solved by implementing lazy loading of modules, since this is during build time?

Commands used:
1.node --max_old_space_size=12000 ./node_modules/@angular/cli/bin/ng build --prod --aot --env=prod

1. updated the ng to accept the --max_old_space_size parameter

The build is working only with --sourcemap=false and --aot=false; but this is causing memory leaks and page load issues in the browser due to huge application size.

StackTrace:-
[INFO]
[INFO] <--- Last few GCs --->
[INFO]
[INFO] [11944:0x2710b70] 898052 ms: Mark-sweep 11998.2 (13529.5) -> 11998.2 (13529.5) MB, 4991.9 / 0.0 ms allocation failure GC in old space requested
[INFO] [11944:0x2710b70] 903445 ms: Mark-sweep 11998.2 (13529.5) -> 11998.1 (13434.0) MB, 5366.9 / 0.0 ms last resort
[INFO] [11944:0x2710b70] 908749 ms: Mark-sweep 11998.1 (13434.0) -> 11998.1 (13378.0) MB, 5266.9 / 0.0 ms last resort
[INFO]
[INFO]
[INFO] <--- JS stacktrace --->
[INFO]
[INFO] ==== JS stack trace =========================================
[INFO]
[INFO] Security context: 0x2b8a8b3a66a1
[INFO]

[loic49]

I don't know if it can help someone but we had the same problem after upgrading to version 1.3.0. And we had others problem too : slow compilation and bad names for generated chunk.

All our problems were solved with this : https://github.com/angular/angular-cli/pull/7338

[ghost]

FTR, for one project, we abandoned Angular because of this. No amount of --max_old_space_size helps anymore.

Great work alienating enterprise users.

[Masquer]

There's always an option to eject the app.

[linkevin777]

What do you mean by ejecting the application?

On Tue, Aug 22, 2017 at 5:12 PM, Arseny E. Naryshkin <
[email protected]> wrote:

There's always an option to eject the app.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/angular/angular-cli/issues/5618#issuecomment-324021572,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADuwsXkLSkoHTg9-AMuUESUfM2sCLVbOks5satPRgaJpZM4Mn-Nn
.

[randyaa]

Still a problem for us even after CLI upgrade to 1.3.1 and @angular upgrade to 4.3.5

tried typescript 2.5 but run into some compilation problems. we're on 2.4.2.

edited:

On our local machines or our gitlab runner instances we can't reproduce the problem. For some reason the build only fails on our jenkins box. The only difference I've been able to gather is jenkins is on a slightly older version of node/npm version:

v6.9.1
3.10.8

instead of

v6.11.0
3.10.10

_fixed_ by changing our production npm build script to:

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

Not so much a _fix_ as it is a brute force work-around, but it'll at least buy time while we figure out what's eating up all the heap space.

[ghost]

@Masquer how would eject help? It's actually a webpack problem.

[Masquer]

@notsonotso oh, it will not then.

my app, however, fails to compile by ng with 'heap out of memory' error, but does as ejected.

[mgechev]

Here's a related, solved issue in angular-seed. I hope it helps someone.

[mattem]

No amount of setting max-old-space-size helped on our project. However, as we only build AOT in prod, we have temporarily disabled sourcemaps which seemed to fix it for us on our CI server.

[timwright35]

Like @mattem I have not been able to get the max-old-space-size to work either. I do not if I am fully setting it up right though since the build process I have uses webpack with "ngtools/webpack".

[bgever]

Same issue, but we've found a more reliable workaround to increase the memory limit.

Since Node 8.x, you can set a NODE_OPTIONS environment variable, and pass in the --old-max-space-size flag. We currently need 6GB.

E.g. on Windows CMD: set NODE_OPTIONS=--old-max-space-size=6411 before running the AOT build.

I wonder if there is a child process that doesn't get the arguments that are set on the node executable.

[bgever]

I know, and trust me, I'm just as much struggling with this. Not fun when the build server starts to run out of memory. It's a serious problem that should be addressed. This workaround just helped me to limp along a little farther, just like turning off the source maps. Your mileage may vary.

[Tolitech]

Hello.
this problem is serious.

On my computer I was limiting to 8Gb and the ng build was working fine.
(with old-max-space-size)

But now I've got a big big project and believe me, out of memory.

I have a code generator that builds everything perfectly.
but the new project has more than 200 entities.
The creation of modules and lazy loading depends on the settings made by the client and their entities.

I would not want to separate in several applications because there is a lot of dependency.
(200 services, 600 components)

The project runs fine with ng serve, but not with ng build.
I rented a virtual machine with 28Gb ram and believe me, did the build using 27Gb of RAM.
The service node occupied exactly 27Gb.

(I put the limit of 28gb)

Everything works fine with ng serve.

can anyone know to tell me if just separating into several lazy loading modules it will need less memory to compile with ng build? or it works only to separate the JS?

I can not rent a virtual machine whenever I need to run ng build.
And the effort of change will be very high.
So I needed to be sure of what to do.

Thanks.

[joecot]

@Tolitech Instead of depending on having enough RAM for this to build, just add swap to your machine. The build will be a little slower, but you don't need to be renting machines with 28 GB of RAM.

I too want this to be resolved ASAP, but adding swap space gets around the memory issue.

[Tolitech]

@joecot Thank you.
I'll try to do this and see if it works.
If it works, I do not see any problems if it takes 8 hours.
I leave a night job for publication without problems.

That was a good idea.
I'll try.

Thank you.

[Tolitech]

@joecot @notsonotso
It worked.
I configured 32Gb virtual memory (swap), --max_old_space_size and finally worked.
It used the 28gb (It's too high), but it worked.
Thank you very much for the idea, @joecot

[bgever]

@mhevery @bradlygreen - apologies for pulling you into this one, but with @Tolitech's extreme case above, the value proposition of Angular is starting to become seriously undermined.

Our codebase is growing rapidly, and our team is continuously running into these memory issues, where we even reach the limitations of our development and build machines. In all my years of web development there's never been a case that I would run out of the capabilities of the machine, just to compile to several 300k files for my webapp/website. It seems to be a memory optimization or architectural issue that hopefully can be avoided.

We've already lost countless hours on these problems, and the premise that Angular is a framework that scales for large enterprise applications doesn't hold up anymore.

I'd really appreciate if this issue could be prioritized, as I'm really starting to doubt whether our choice of Angular as a suitable framework was correct, considering that only the AOT builds are performant and small enough to ship to customers over the wire, and that we're struggling to get those to work. Thank you.

[xnnkmd]

@bgever Apparently google is not using angular-cli/webpack themselves, so they don't run into problems like this. I suspect this is why this problem receives so little attention from the angular developers. If this continues, the community should be publicly warned about angular being unsuitable for large projects.

[Tolitech]

You were perfect in your words, @bgever .
I'm already thinking that Angular does not work for large applications, after all I'm now needing 28 Gb of RAM and the project could grow bigger. (This is the first day of this application).

I'm already thinking about another strategy for this type of project, maybe even change technology because I'm realizing that this problem is occurring with many people and for a long time.

I believe my customer will not accept me saying that he needs 28 Gb RAM to compile his own project.
I'm very worried about this.

[Dunos]

I'm just staying in Angular CLI 1.2.7 while they fix this, hope they do it soon tho, but with 1.2.7 I have no memory problems at all.

[bjornharvold]

Same here. Running Angular CLI 1.3.2 and Angular 4.3.6. Added this based on another thread to get it to work. My app isn't very big but CLI clocked in at 4GB to build my app.

"scripts": {
    "build": "node --max_old_space_size=8192 ./node_modules/@angular/cli/bin/ng build --target production --environment prod --aot",
    "ng": "ng",
    "start": "ng serve",
    "test": "ng test",
    "lint": "ng lint",
    "e2e": "ng e2e"
  },

[elvisbegovic]

@bjornharvold @Tolitech We need 1024go ram 32ghz cpu, so 32'000'000'000 calcul per second to build angular but if you learn bazel from google it can be faster 😂

[gtarun]

https://github.com/endel/increase-memory-limit

This worked for me

[hugodes]

Same problem here.

I had to downgrade to @angular/cli 1.2.6 with TS 2.4.2 for the build to work again.

A shame I can't use the latest angular cli ... Why isn't this considered a severe bug ?

[alexzuza]

@hugodes

Why isn't this considered a severe bug ?

I think it is because of https://github.com/angular/angular/issues/19058

[phamtuananh791994]

Lastest version is the same !

[DutchKevv]

Same here, this is ridiculous. I'm using a cheap VPS server to build and it simply crashes with 2GB of memory

[hugodes]

What solved it for me was doing ng build --prod instead of ng build --aot --prod.

The --prod option already includes the --aot one, and optimises the build process and I'm not getting memory errors any more.

Hope it helps some of you guys.

[aminebizid]

Try -sm false

[jota0222]

It happens to me when the allowJS parameter is _true_ in tsconfig.json. Apparently, the javascript files are overloading the memory.

[clevagroup]

This worked for me, add to package.json scripts section. Watching the memory usage in task manager it got up to around 4gb usage. Seems a touch excessive!

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

npm run build2

[tupham]

This command works for me:
node --max-old-space-size=4096 ./node_modules/@angular/cli/bin/ng build --prod

"scripts":{
"prod": "node --max-old-space-size=4096 ./node_modules/@angular/cli/bin/ng build --prod"
}

[tossp]

try process.nextTick() ？

[marcalj]

With Node 8.x and latest cli version works without any hack :)

[ghost]

I think this issue can be closed. Not because it's fixed, but because it will NOT be fixed. Not ever.

Google is busy trying to get a Bazel-based build system in place for public consumption, and they are unlikely to spend time fixing this old crap (it's mostly webpack's fault anyway)

[zackschuster]

@notsonotso an ng team member told me this has to do with poor recursion handling in @ngtools/webpack, i'm curious what webpack's faults are?

[ghost]

@zackschuster its mere existence

[MrBlaise]

Started happening to me using macOS 10.13
On Windows it builds fine, both machines using the same configuration and have 16 gigs of ram.

[MbuelensAM]

I went back to version 1.2.x and didn't have any exceptions there.

1.3.x and 1.4.x all gave the memory exception.

[MrBlaise]

@filipesilva Is there any news regarding to this issue?
I'm curious why a semi-large project needs more than 2 gigs to build. I am not familiar with the inner workings of the compilation process, but it seems rather high to me.

EDIT:

using the --build-optimizer flag causes the issue, it was working fine, but I recently upgraded the cli and I see that it uses a newer build-optimizer (0.0.31), maybe memory leak on the optimizer?

[elvisbegovic]

@MrBlaisee you mean 20* Go

!!

[GenweiWu]

try ng build --aot --sourcemaps=false ,
it seems there is problem with sourcemaps.

[elvisbegovic]

Lol with or without sourcemap it depend how long node is working! Hope this will be fixed one day

[tupham]

I am using 6.9.4 Nodejs and Angular 4.5, Angular-cli 1.4.6 but no lucks

We need hacks above.

[muhammadsaaeed]

Got an issue resolved on one of the machine using below:

Try this out:
In "ProjectDirectorynode_modules\.bin" modify webpack.cmd to:

@if EXIST "%~dp0node.exe" (
"%~dp0node.exe --max_old_space_size=4096 " "%~dp0..\webpack\bin\webpack.js" %*
) ELSE (
@SETLOCAL
@set PATHEXT=%PATHEXT:;.JS;=;%
node --max_old_space_size=4096 "%~dp0..\webpack\bin\webpack.js" %*
)

and try to build.
Basically, its going to use --max_old_space_size=4096 with node webpack build.

See if that helps.

[ar53n]

Angular 5 and angular-cli 1.5. Have problems --aot

95% emitting
<--- Last few GCs --->

  152742 ms: Mark-sweep 1261.4 (1434.1) -> 1261.4 (1434.1) MB, 471.1 / 0.0 ms [allocation failure] [scavenge might not succeed].
  153236 ms: Mark-sweep 1261.4 (1434.1) -> 1261.4 (1434.1) MB, 493.7 / 0.0 ms [allocation failure] [scavenge might not succeed].
  153757 ms: Mark-sweep 1261.4 (1434.1) -> 1268.2 (1418.1) MB, 520.5 / 0.0 ms [last resort gc].
  154333 ms: Mark-sweep 1268.2 (1418.1) -> 1275.0 (1418.1) MB, 575.8 / 0.0 ms [last resort gc].


<--- JS stacktrace --->

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

Security context: 000003AFBC7CFB61 <JS Object>
    1: DoJoin(aka DoJoin) [native array.js:~129] [pc=00000055CD16A7F7] (this=000003AFBC704381 <undefined>,w=0000011B90EE0C21 <JS Array[539]>,x=539,N=000003AFBC
7043C1 <true>,J=000003AFBC7AE4E1 <String[1]:  >,I=000003AFBC7B46F1 <JS Function ConvertToString (SharedFunctionInfo 000003AFBC752DC9)>)
    2: Join(aka Join) [native array.js:180] [pc=00000055CD1D6A52] (this=000003AFBC704381 <undefined>...

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

[mbrookson]

Also hit this memory issue. Can be 'resolved' by using the build script node --max-old-space-size=4096 ./node_modules/@angular/cli/bin/ng build --prod but hopefully this bug will be fixed soon. Why does it need over 2GB of memory?!

[RicardoVaranda]

Also facing the same issue currently, our app has over 50 components spread across 6 modules.

[dpxxdp]

We are experiencing the same issue... eclipsing 3GB of memory in a medium-large application. We have ~20 modules each with 5-8 components.

[filipesilva]

Hey all, I'm seeing a lot of new reports of this happening after 1.5 is out. One of the changes we did for 1.5 was to use Build Optimizer by default on Angular version 5 projects. Build optimizer does indeed use a lot of memory (https://github.com/angular/devkit/issues/240).

Can you tell me if turning off build optimizer helps with your memory crashes? You can do it with --build-optimizer=false. Turning off sourcemaps can also help via --sourcemaps=false.

If these options don't help, can you post here the full failure log please, including command run?

[mscahill]

--build-optimizer=false helps in my case.

I have a large app (30 modules, 263 components).

With @angular: 4.4.6 ; @angular/cli: 1.4.9 I can get a --prod build with --max_old_space_size=6144 but with @angular: 5.0.0 ; @angular/cli: 1.5.0 I run out of memory even with --max_old_space_size=8192. I can get a build with --max_old_space_size=10240, but my CI does not support that configuration.

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


<--- Last few GCs --->

  387148 ms: Mark-sweep 4983.1 (8230.5) -> 4987.2 (8230.5) MB, 860.4 / 0.0 ms [allocation failure] [scavenge might not succeed].
  387947 ms: Mark-sweep 4987.2 (8230.5) -> 4987.3 (8230.5) MB, 798.9 / 0.0 ms [allocation failure] [scavenge might not succeed].
  388816 ms: Mark-sweep 4987.3 (8230.5) -> 5002.0 (8214.5) MB, 869.3 / 0.0 ms [last resort gc].
  389619 ms: Mark-sweep 5002.0 (8214.5) -> 5017.0 (8214.5) MB, 802.0 / 0.0 ms [last resort gc].


<--- JS stacktrace --->

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

Security context: 0x2199619cfb39 <JS Object>
    1: DoJoin(aka DoJoin) [native array.js:~129] [pc=0x29bfc23b9949] (this=0x219961904381 <undefined>,w=0x3864fdc19d1 <JS Array[537]>,x=537,N=0x2199619043c1 <true>,J=0x2199619ae4b9 <String[1]:  >,I=0x2199619b46c9 <JS Function ConvertToString (SharedFunctionInfo 0x219961952dc9)>)
    2: Join(aka Join) [native array.js:180] [pc=0x29bfc2ccdb52] (this=0x219961904381 <undefined>,w=0x3864fdc19d1 <JS ...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [/Users/*****/.nvm/versions/node/v6.11.0/bin/node]
 2: node::FatalException(v8::Isolate*, v8::Local<v8::Value>, v8::Local<v8::Message>) [/Users/*****/.nvm/versions/node/v6.11.0/bin/node]
 3: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/Users/*****/.nvm/versions/node/v6.11.0/bin/node]
 4: v8::internal::Factory::NewRawTwoByteString(int, v8::internal::PretenureFlag) [/Users/*****/.nvm/versions/node/v6.11.0/bin/node]
 5: v8::internal::Runtime_StringBuilderJoin(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/*****/.nvm/versions/node/v6.11.0/bin/node]
 6: 0x29bfae0092a7


Angular CLI: 1.5.0
Node: 6.11.0
OS: darwin x64
Angular: 5.0.0
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

@angular/cli: 1.5.0
@angular-devkit/build-optimizer: 0.0.32
@angular-devkit/core: 0.0.20
@angular-devkit/schematics: 0.0.35
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.8.0
@schematics/angular: 0.1.0
typescript: 2.4.2
webpack: 3.8.1

However, with --build-optimizer=false I can build with --max_old_space_size=6144

> node --max_old_space_size=6144 ./node_modules/@angular/cli/bin/ng build --prod  --build-optimizer=false

Date: 2017-11-04T23:08:35.111Z
Hash: afdf23d865ad76d6c3a7
Time: 252357ms
chunk {0} 0.5fdb723fb2afdf8bc41a.chunk.js (common) 657 kB  [rendered]
chunk {1} 1.9d7656022b2d3d139dc3.chunk.js () 9.23 MB  [rendered]
chunk {2} 2.0fd8e1693141dc5c5223.chunk.js () 3.15 MB  [rendered]
chunk {3} main.46f18abd9489952e107d.bundle.js (main) 3.43 MB [initial] [rendered]
chunk {4} polyfills.0acd42e0b1fa025cc794.bundle.js (polyfills) 222 kB [initial] [rendered]
chunk {5} styles.27285cfcd50901377a47.bundle.css (styles) 583 kB [initial] [rendered]
chunk {6} vendor.6b76d39b8f45ef045486.bundle.js (vendor) 1.1 MB [initial] [rendered]
chunk {7} inline.e8ad567f621efe38acfe.bundle.js (inline) 1.52 kB [entry] [rendered]

[williangd]

Tests with angular-cli 1.5

ng build --prod build-optimizer=false --sourcemaps=false (I canceled after 12 minutes running)

node --max_old_space_size=4096 node_modules/@angular/cli/bin/ng build --prod build-optimizer=false --sourcemaps=false (work after 4,2 minutes)

[dpxxdp]

@filipesilva, @hansl, Before anything, thanks so much for this project- Angular has been great for our team. We love the framework and we love the CLI so thanks for all your hard work.

This memory issue seems like it is becoming a real problem. I'm looking for some messaging from the Angular team around expectations here, and I'd be happy to give whatever data is necessary to help move it forward.

Our team is an enterprise team with a medium-large app. We ran into this memory issue a while back, and upped the max_old_space_size to 1GB and then later 2GB. Each time it solved our problem for a few months. But as the app continues to grow we've run into it again now and we can't do this forever. Our toolchain uses Bitbucket pipelines, which like many other CI's maxes out available memory (3GB is our max given our other needs), so we're beginning to run up against a wall.

I've been taking some benchmarks with our app, it looks like you're correct in your post above: 1.5.0, with --build-optimizer=false uses equivalent memory to 1.4.5.

Our app has ~180 components and ~30 services across ~22 modules. I'd like to think it is constructed in a reasonably smart manner, following best practices and general clean code design. The build --aot --build-optimizer=false --sourcemaps=false for this project using 1.5.0 now takes about 2925 GB of memory.

Two general questions for you and others, about (1) expectations and (2) short-term alleviation:

(1) Is Angular built for enterprise development? If so, this issue seems to be of the highest priority and the community deserves more frequent and clear messaging on this. If not, your users need to know this because lots of decisions across hundreds of companies ride on that.

(2) Are there any recommendations from the Angular team about ways to alleviate this issue?

• Should we split out our modules into "pre-compiled" libraries?
• Is memory usage particularly worse for high Component counts, high Service counts, etc?
• Other flags that help trade memory for build-time?

Again, I'd be happy to test any theories/provide data about our large application to help get to the bottom of this, and again, thanks for all the hard work you've done on this.

[jason-d-hobbs]

In our case, the build optimizer nor the sourcemaps flags were effective. Downgrading to @angular/cli 1.4.9 fixed it.

Worked without either flag set false:

ng build -prod

@angular/cli: 1.4.9
node: 6.9.2
os: linux x64
@angular/common: 4.4.6
@angular/compiler: 4.4.6
@angular/core: 4.4.6
@angular/forms: 4.4.6
@angular/http: 4.4.6
@angular/platform-browser: 4.4.6
@angular/platform-browser-dynamic: 4.4.6
@angular/router: 4.4.6
@angular/cli: 1.4.9
@angular/compiler-cli: 4.4.6
typescript: 2.3.4

DIDN'T Work even with both flags set false:

ng build -prod --build-optimizer=false --sourcemaps=false
Angular CLI: 1.5.0
Node: 6.9.2
OS: linux x64
Angular: 4.4.6
... common, compiler, compiler-cli, core, forms, http
... platform-browser, platform-browser-dynamic, router
... tsc-wrapped

@angular/cli: 1.5.0
 @angular-devkit/build-optimizer: 0.0.32
 @angular-devkit/core: 0.0.20
 @angular-devkit/schematics: 0.0.35
 @ngtools/json-schema: 1.1.0
 @ngtools/webpack: 1.8.0
 @schematics/angular: 0.1.0
typescript: 2.3.4
webpack: 3.8.1

...

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

We have not tried the hacks above on changing the old space memory... our application isn't apparently as big as some of the others on this thread, but yet fails on cli 1.5.0.

[danny-swimmer]

@filipesilva: --build-optimizer=false and --sourcemaps=false works for me with cli 1.5.
Without them, I was getting "JavaScript heap out of memory".
Thanks for your help!

[adamzhu-xs]

Happens for me also. Wired part is error thrown after bundle files generated.

Angular CLI: 1.5.0
Node: 8.9.0
OS: win32 x64
Angular: 5.0.0

<--- Last few GCs --->

[12192:00000000004C39A0] 236834 ms: Mark-sweep 1420.3 (2200.9) -> 1420.3 (2159.4) MB, 578.6 / 0.0 ms last resort GC in old space requested
[12192:00000000004C39A0] 237461 ms: Mark-sweep 1420.3 (2159.4) -> 1420.3 (2136.9) MB, 627.2 / 0.0 ms last resort GC in old space requested

<--- JS stacktrace --->

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

Security context: 000000B4C7AA5EC1
1: DoJoin(aka DoJoin) [native array.js:~95] [pc=0000001391AFE299](this=000001A846C82311 ,p=00000050BD62B091 ,A=000000B4C7AEEC69 ]: >,z=000001A846C82421 )
2: Join(aka Join) [native array.js:~120] [pc=0000001390C722A9](this=000001A846C82311 ,p=00000050BD62B091

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
npm ERR! code ELIFECYCLE
npm ERR! errno 3
npm ERR! [email protected] build:prod: ng build --env=prod --prod --aot --stats-json --named-chunks=true --sourcemaps=false
npm ERR! Exit status 3

==== update ======
Issue for me is --stats-json. Build is fine after remove this flag.

[swftvsn]

Optimizations are welcome, but on the other hand memory is cheap. Until optimizations are here run the build using

node --max-old-space-size=8192 ./node_modules/@angular/cli/bin/ng build

and append whatever switches you'd like to the end. To make it easier to run, edit your package.json file and add this line to "scripts":

"serve": "node --max-old-space-size=8192 ./node_modules/@angular/cli/bin/ng serve --aot"

Then you can execute it using

npm run serve

I'm an old Java dev, so this seems familiar to me somehow :)

[elclanrs]

@swftvsn, memory is cheap if you have control over it, but we deploy to a Docker swarm, and containers have limited memory. This is a pretty serious issue for us. I'd prefer a slower build if that means caching stuff to disk and not running out of memory.

[cecotw]

I am getting this issue after upgrading to cli 1.5 and angular 5.0.

I want to highlight the question above:

• Is Angular built for enterprise development?

I am so confused why any compiler would need 4 gigs of memory to compile a web app..... To get it to compile aot post upgrade I had to jack the memory up to 4 gigs. Our app has 2 feature module libraries each with about 15 modules, ~60 modules in the main app, and ~15 services. We have a lot left to build as well.

[swftvsn]

I would imagine it has to do with the obscene amount of dependencies + all the hoops that are done to statistically analyze all the dependencies and your code in order to shake the trees. Take a look at node_modules if you dare. (And source / debug maps and things I don't even know about)

Excessive memory consumption is usually caused by a lot of data and/or abstraction over abstraction over abstraction over... :) Or a bug.

For now I'm happy and I just feed the beast. I do hope it looses some of it's appetite in the coming versions though..

[dpxxdp]

I'm less concerned about "how could this possibly...?" than I am about the lack of communication.

The compilation itself is doing some pretty heavy lifting right now. It's really great actually. The entire CLI is. It bundles this thing up and serves it pretty compactly. In fact his may be a testament to just how easy Angular makes it to build large scale web apps... their size is outpacing the toolchain.

I'm just looking for the Angular team to set expectations here, that's all:

• Does the Angular team consider this a problem? (its been tagged as "required" since March)
• Is there any action being taken to fix it? (its been tagged as "investigation" since March)
• Is this a fixable issue in the next month? 6 months? year?
• If it's not a fixable issue, are there any other build configurations/toolchains they'd recommend?
• Are they still researching the answers to the above questions?

Any answer to those questions is okay... but it's important that those answers (and their progress) are communicated to the community in an iterative fashion. My team and many other teams need to make decisions based off those answers, and right now we feel frozen.

This is an open source project that we're all getting for free. It's added tremendous value already even with this issue; so some people are being awfully critical given this. At the same time, open communication is integral to the success of solid open source projects: we're looking to the Angular team for that leadership.

@filipesilva , @hansl?

[swftvsn]

That's an excellent summary @dpxxdp !

[changLiuUNSW]

Recent upgrade our project to Angular 5 and Angular CLI 1.5.
We have 100+ components and 20+ modules. The build --prod is taking forever and finally throw heap out of memory exception which is very frustrating!

[Tolitech]

As I mentioned here a few months ago, I have a very large project with several modules too, +120 pages, +500 components (pages are divided into at least 3 components like grid, form).

To get ng build -prod to work I had to test on a machine with 32 Gb of RAM, nodeJS consumed 28 Gb to compile the project. Impressive.

The solution was actually put 32 Gb as virtual memory on the machine (swap).
In addition, of the already known "--max_old_space_size".

[changLiuUNSW]

The label of this issue should be priority: 1 (urgent) rather than priority: 2 (required)

[cecotw]

@swftvsn I am still not getting it. Maybe it is because I come from .NET where the c# compiler would tear through a project with comparable amounts of classes without breaking a sweat.

@Tolitech This is exactly the main point. If we need machines with 32 GB of ram to build the project, some cloud agents won't be able to handle this/aren't configurable to upgrade the hardware. Thus, we would need to make architectural decisions to start building segmented SPAs to keep the size of a project down, catering to compiler limitations.

@dpxxdp While I do agree that it is great that it is free and open source (thanks as well team!), I don't feel that it is a criticism to report a major bug/functional limitation that requires a hardware upgrade as a work around. I don't think anyone is trying to criticize the work that was done, but rather increase the priority on this issue.

[WandererInVoids]

guys 2 workaround for heap problem

1. use custom build with webpack
   currently default build use several optimization step + minification.
2. use command like
   ng build --app app -aot=true -e=prod -sm=false -ec=true --named-chunks=false -oh=all -pr=false
   this will generate bundles without minification and general size for vendor bundle will increased in my case for 8%. Build time decreased for twice, but minification step take long time 6-7 min in CI machine (2gb). I use gulp for post build actions in my case its uglify js and postcss.

My app
~72 services (CRUD operation + some general logic)
~10 pipe
~15 directive
~170 components
~ 80 model class (data from API)
~ 15 module

as for me i want some flags to set optimization step count, tree shake deep (function, class, variable)

[filipesilva]

Hi all,

I've bumped the priority on this issue and will be working on it. We didn't consider it to be as urgent before because the solution at the time was to increase the available memory to node, which defaults to 1.7gb. So it was expected that at some point projects would need more memory than the default.

However with the release of 1.5 the memory requirements seem to have increased dramatically. Projects that didn't have any memory problems before now do. 32gb is definitely a ridiculous amount of RAM and shouldn't be needed.

At this point I'm not sure what caused the memory spike but have a few hypothesis. With CLI1.5 + Angular 5 we use a new pipeline that does better type checking by using a full TS program. Maybe there's a bad cache somewhere in there, or the TS program is taking a lot of memory. Another possibility is Uglify, which we had to upgrade as well. Or it might be something in the AOT compiler itself. We also default build optimizer to true now and it's not really optimized for neither speed nor memory.

If you're running into this problem and have time, I'd appreciate if you could answer a couple questions:

• What version of the CLI and Angular are you on?
• Does this only happen on ng build --prod?
• Do you still get the memory error with these build commands:
  
  
  
  • ng build --prod --build-optimizer=false
  
  
  • ng build --aot
  
  
  • ng build --aot --build-optimizer
  
  
• If you have a project that I can look at, can you link it please?

[YeomansIII]

In response to above comment:
CLI 1.5.0, Angular 5.0.1

Project:
Services: 9
Components: 43
Models: 28
Lines of ts: 8200
Lines of sass: 5000

Heap error happens with:
ng build --prod: yes
ng build --build-optimizer=false: no
ng build --aot: no
ng build --aot --build-optimizer: no

[etiennetalbot]

@filipesilva
About 20 modules, 30 services, 80 components

• CLI 1.4.4, Angular 4.4.4
• Only happens when building with --prod, --aot, and --sourcemap (we need it in prod...)
• If settings memory to 8gb, we can actually use --prod, --aot, --sourcemap, AND --build-optimizer

Can't show the repo unfortunately

[WandererInVoids]

@filipesilva

What version of the CLI and Angular are you on?
1.5.0 angular 5.0.1
Does this only happen on ng build --prod?
yes
Do you still get the memory error with these build commands:
ng build --build-optimizer=false no
ng build --aot no
ng build --aot --build-optimizer no

[jmcclanahan]

@filipesilva
Windows 7 Pro 64-bit
12 Gigs of ram
CLI 1.5.0, Angular 5.0.0

Project details:
~120 components
15 modules

Do you still get the memory error with these build commands:
ng build --prod: yes
ng build --build-optimizer=false: no
ng build --aot: no
ng build --aot --build-optimizer: yes

[dpxxdp]

On Angular 4.3
with ~180 components
with ~30 services
with ~22 modules

With CLI 1.5
Does this only happen on ng build --prod? Yes

ng build --build-optimizer=false less than 2GB
ng build --aot --build-optimizer=false ~2.8GB
ng build --aot over 3 GB

With CLI 1.4.5
Does this only happen on ng build --prod? Yes

ng build --build-optimizer=false less than 2GB
ng build --aot --build-optimizer=false ~2.8GB
ng build --aot ~2.8 GB

Our repo is private unfortunately

[garkbit]

CLI 1.5.0, Angular 5.0.0

Modules: ~50
Services: ~110
Components: ~290

ng build --prod: fail
ng build --prod --build-optimizer=false: fail
ng build --prod --build-optimizer=false --sourcemaps=false: fail
ng build --prod --aot=false: works
ng build: works
ng build --aot=true: works
ng build --aot=true --build-optimizer=true: fail

[AntonisFK]

What version of the CLI and Angular are you on?
@angular/[email protected] , @angular 5.0

Does this only happen on ng build --prod?
yes

Do you still get the memory error with these build commands:
ng build --build-optimizer=false : NO
ng build --aot : NO
ng build --aot --build-optimizer: NO

[elvisbegovic]

Under cli1.5 & angular5

Ng build —prod : YES
Ng serve —aot : first time NO but after editing file YES it throw error out of memory... blockin at 0%

Ng serve : NO all’s okay and fast (but wait a lot to show result in browser because of JiT compiler)

Cc @filipesilva

[Satyadatla]

The versions I am using
CLI - 1.2.0 and Angular 4.2.5
Modules: ~ 130
Components: ~ 200
Services: ~ 70

getting the build issues with below options.

ng build --prod: fail
ng build --aot=true: fail
ng build --aot=true --sourcemaps=false : Works most of the times and very often it is failing.
ng build --prod --aot=false : works

[swftvsn]

@cecotw sarcasm is sometimes misinterpreted. And I'm not here to fire up any flamewars, your ecosystem is obviously the better :)

[rejayi-experion]

I had experienced the issue FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory with ng build --prod. I have solved the problem by using
node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build --prod

You can add also in

package.json

as

"scripts": {
    "prod": "node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng  build --prod",
}
npm run prod

[magemello]

What version of the CLI and Angular are you on?

Angular CLI: 1.5.0
Node: 8.5.0
OS: darwin x64
Angular: 5.0.0
... animations, common, compiler, core, forms, http
... platform-browser, platform-browser-dynamic, router

@angular/cdk: 5.0.0-rc0
@angular/cli: 1.5.0
@angular/compiler-cli: 5.0.1
@angular/flex-layout: 2.0.0-beta.10
@angular/language-service: 5.0.1
@angular/material: 5.0.0-rc0
@angular-devkit/build-optimizer: 0.0.32
@angular-devkit/core: 0.0.20
@angular-devkit/schematics: 0.0.35
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.8.0
@schematics/angular: 0.1.2
typescript: 2.4.2
webpack: 3.8.1

Does this only happen on ng build --prod? NOT SURE
Do you still get the memory error with these build commands:

• ng build --build-optimizer=false WORKS
• ng build --aot FAILS
• ng build --aot --build-optimizer FAILS

also:

• ng build --aot=true --sourcemaps=false WORKS
• ng build --prod -sourcemaps=false FAILS
• ng build --prod FAILS
• ng build --prod --aot=flase --sourcemaps=false FAILS

If you have a project that I can look at, can you link it please?

• https://github.com/Alfresco/alfresco-ng2-components/tree/development

we have a gitter channel if you need help to build our project and have a look:

• https://gitter.im/Alfresco/alfresco-ng2-components

[JonathanYates]

Same issue. Upgraded to A5. ng build --prod results in out of memory error below. The error does not occur without --prod. Increasing the --max_old_space_size is not really the answer, something is fundamentally wrong and has stopped our A5 upgrade going anywhere.

Please fix!

<--- Last few GCs --->

243344 ms: Mark-sweep 1000.9 (1434.4) -> 1003.2 (1434.4) MB, 452.4 / 0.0 ms [allocation failure] [scavenge might not succeed].
243760 ms: Mark-sweep 1003.2 (1434.4) -> 1003.2 (1434.4) MB, 416.3 / 0.0 ms [allocation failure] [scavenge might not succeed].
244187 ms: Mark-sweep 1003.2 (1434.4) -> 1012.9 (1418.4) MB, 427.0 / 0.0 ms [last resort gc].
244591 ms: Mark-sweep 1012.9 (1418.4) -> 1022.8 (1418.4) MB, 403.8 / 0.0 ms [last resort gc].

<--- JS stacktrace --->

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

Security context: 0x957966cfb39
1: DoJoin(aka DoJoin) [native array.js:~129] [pc=0xbe4173aee59] (this=0x95796604381 ,w=0x1ca9328ff671 ,J=0x957966ae4b9 2: Join(aka Join) [native array.js:180] [pc=0xbe419f08ab2] (this=0x95796604381 ,w=0x1ca9328ff671

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::Local) [/usr/local/bin/node]
3: v8::internal::V8::FatalProcessOutOfMemory(char const, bool) [/usr/local/bin/node]
4: v8::internal::Factory::NewRawTwoByteString(int, v8::internal::PretenureFlag) [/usr/local/bin/node]
5: v8::internal::Runtime_StringBuilderJoin(int, v8::internal::Object*, v8::internal::Isolate) [/usr/local/bin/node]
6: 0xbe4066092a7
Abort trap: 6

[radoslavpetranov]

What version of the CLI and Angular are you on?

@angular/cli: 1.4.9
node: 6.11.0
os: win32 x64
@angular/animations: 4.4.6
@angular/cdk: 2.0.0-beta.12
@angular/common: 4.4.6
@angular/compiler: 4.4.6
@angular/core: 4.4.6
@angular/flex-layout: 2.0.0-beta.9
@angular/forms: 4.4.6
@angular/http: 4.4.6
@angular/material: 2.0.0-beta.12
@angular/platform-browser: 4.4.6
@angular/platform-browser-dynamic: 4.4.6
@angular/router: 4.4.6
@angular/cli: 1.4.9
@angular/compiler-cli: 4.4.6
typescript: 2.6.1

ng build --prod - Success
ng build --build-optimizer=false - Success
ng build --aot - Success
ng build --aot --build-optimizer - OOME

A sanity-check local run of ng serve --prod --aot gave me failure at a later time

Date: 2017-11-12T22:52:55.879Z
Hash: 456f57f84be9de32704e
Time: 185523ms
chunk {0} polyfills.5dbd24b37bdff70c0320.bundle.js (polyfills) 66.1 kB {4} [initial] [rendered]
chunk {1} main.a2ba9af755957e20aa31.bundle.js (main) 1.98 MB {3} [initial] [rendered]
chunk {2} styles.2dfc00976daefa57d973.bundle.css (styles) 80.3 kB {4} [initial][rendered]
chunk {3} vendor.c5146d2ca93aff011cac.bundle.js (vendor) 1.51 MB [initial] [rendered]
chunk {4} inline.7e6f8c72074764ba2a48.bundle.js (inline) 1.45 kB [entry] [rendered]

webpack: Compiled successfully.

<--- Last few GCs --->

  277448 ms: Mark-sweep 1225.3 (1434.4) -> 1225.3 (1434.4) MB, 1086.6 / 0.1 ms [allocation failure] [scavenge might not succeed].
  278456 ms: Mark-sweep 1225.3 (1434.4) -> 1225.3 (1434.4) MB, 1008.4 / 0.1 ms [allocation failure] [scavenge might not succeed].
  279488 ms: Mark-sweep 1225.3 (1434.4) -> 1236.2 (1418.4) MB, 1030.8 / 0.1 ms [last resort gc].
  280607 ms: Mark-sweep 1236.2 (1418.4) -> 1247.1 (1418.4) MB, 1117.0 / 0.1 ms [last resort gc].

<--- JS stacktrace --->

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

Security context: 00000126BFCCFB49 <JS Object>
    1: DoJoin(aka DoJoin) [native array.js:~129] [pc=000003FAD779BBD7] (this=00000126BFC04381 <undefined>,w=0000033E0E885D01 <JS Array[334]>,x=334,N=00000126BFC043C1 <true>,J=00000126BFCAE4C9 <String[1]:  >,I=00000126BFCB46D9 <JS Function ConvertToString (SharedFunctionInfo 00000126BFC52DC9)>)
    2: Join(aka Join) [native array.js:180] [pc=000003FAD73F9FB2] (this=00000126BFC04381 <undefined>...

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

In my project everything was working fine in --prod --aot mode up until a day ago when I decided to migrate to HttpClient to prepare for the Angular 5 / CLI 1.5 switch. No version changes, no CLI changes were involved.

I upgraded my services and moved some error/auth logic to a couple of interceptors. My vendor dev bundle went from 15MB to 6MB and I was all impressed. Then I decided to sanity check my prod aot build with ng serve --prod --aot and I started getting the OOME.

[jayhamilton]

Seeing the same issue after upgrading to cli 1.5, Angular 1.5 and HttpClient

$ ng build --aot --prod
95% emitting
<--- Last few GCs --->

224719 ms: Mark-sweep 1304.7 (1434.7) -> 1304.7 (1434.7) MB, 485.6 / 0.0 ms [allocation failure] [scavenge might not succeed].
225206 ms: Mark-sweep 1304.7 (1434.7) -> 1304.7 (1434.7) MB, 487.0 / 0.0 ms [allocation failure] [scavenge might not succeed].
225685 ms: Mark-sweep 1304.7 (1434.7) -> 1304.7 (1418.7) MB, 479.3 / 0.0 ms [last resort gc].
226180 ms: Mark-sweep 1304.7 (1418.7) -> 1304.7 (1418.7) MB, 494.5 / 0.0 ms [last resort gc].

<--- JS stacktrace --->

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

Security context: 0x3e4edad3fa99
1: DoJoin(aka DoJoin) [native array.js:~129] [pc=0xd5adf91512e] (this=0x3e4edad04241 ,w=0x21eed50e5b41 ,J=0x3e4edad4a369 2: Join(aka Join) [native array.js:180] [pc=0xd5ac9783c52] (this=0x3e4edad04241 ,w=0x21eed50e5b41

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::Local) [/usr/local/bin/node]
3: v8::internal::V8::FatalProcessOutOfMemory(char const, bool) [/usr/local/bin/node]
4: v8::internal::Factory::NewRawTwoByteString(int, v8::internal::PretenureFlag) [/usr/local/bin/node]
5: v8::internal::Runtime_StringBuilderJoin(int, v8::internal::Object*, v8::internal::Isolate) [/usr/local/bin/node]
6: 0xd5ac97060c7
7: 0xd5adf91512e
Abort trap: 6
Jays-MacBook-Pro:ngx-dynamic-dashboard-framework jayhamilton$ ng build --aot --prod
95% emitting
<--- Last few GCs --->

224540 ms: Mark-sweep 1305.3 (1444.7) -> 1305.3 (1444.7) MB, 476.2 / 0.0 ms [allocation failure] [scavenge might not succeed].
225007 ms: Mark-sweep 1305.3 (1444.7) -> 1305.3 (1444.7) MB, 466.7 / 0.0 ms [allocation failure] [scavenge might not succeed].
225479 ms: Mark-sweep 1305.3 (1444.7) -> 1305.3 (1428.7) MB, 471.9 / 0.0 ms [last resort gc].
225970 ms: Mark-sweep 1305.3 (1428.7) -> 1305.3 (1428.7) MB, 491.1 / 0.0 ms [last resort gc].

<--- JS stacktrace --->

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

Security context: 0x67c5bb3fa99
1: DoJoin(aka DoJoin) [native array.js:~129] [pc=0x337898eca1ce] (this=0x67c5bb04241 ,w=0x3ba9f97f5a79 ,J=0x67c5bb4a369 2: Join(aka Join) [native array.js:180] [pc=0x33787d083c52] (this=0x67c5bb04241 ,w=0x3ba9f97f5a79

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::Local) [/usr/local/bin/node]
3: v8::internal::V8::FatalProcessOutOfMemory(char const, bool) [/usr/local/bin/node]
4: v8::internal::Factory::NewRawTwoByteString(int, v8::internal::PretenureFlag) [/usr/local/bin/node]
5: v8::internal::Runtime_StringBuilderJoin(int, v8::internal::Object*, v8::internal::Isolate) [/usr/local/bin/node]
6: 0x33787d0060c7
7: 0x337898eca1ce
Abort trap: 6

PACKAGE.JSON
"dependencies": {
"@angular/animations": "^5.0.1",
"@angular/cdk": "2.0.0-beta.12",
"@angular/common": "^5.0.1",
"@angular/compiler": "^5.0.1",
"@angular/core": "^5.0.1",
"@angular/forms": "^5.0.1",
"@angular/http": "^5.0.1",
"@angular/material": "2.0.0-beta.12",
"@angular/platform-browser": "^5.0.1",
"@angular/platform-browser-dynamic": "^5.0.1",
"@angular/router": "^5.0.1",
"@swimlane/ngx-charts": "6.1.0",
"core-js": "^2.4.1",
"d3": "^4.4.0",
"jquery": "2.2.0",
"ng2-cookies": "1.0.3",
"ng2-dnd": "^2.1.1",
"reflect-metadata": "0.1.8",
"rxjs": "^5.5.2",
"semantic-ui": "2.2.2",
"socket.io-client": "^1.7.2",
"sockjs-client": "^1.1.4",
"stompjs": "^2.3.3",
"zone.js": "^0.8.4"
},
"devDependencies": {
"@angular/cli": "1.5.0",
"@angular/compiler-cli": "^5.0.1",
"@types/jasmine": "2.5.38",
"@types/node": "~6.0.60",
"codelyzer": "~2.0.0",
"jasmine-core": "~2.5.2",
"jasmine-spec-reporter": "~3.2.0",
"karma": "~1.4.1",
"karma-chrome-launcher": "~2.0.0",
"karma-cli": "~1.0.1",
"karma-coverage-istanbul-reporter": "^0.2.0",
"karma-jasmine": "~1.1.0",
"karma-jasmine-html-reporter": "^0.2.2",
"protractor": "~5.1.0",
"ts-node": "~2.0.0",
"tslint": "~4.5.0",
"typescript": "~2.6.1"
}

[hanvyj]

EDIT working with the --max_old_space_size=8192 fix above**

Also getting the exact same. Angular 4 build time, 2 minutes maybe? New angular 5 build time is 25 to fail with:

ng build --prod --output-path=dist/client

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

1327460 ms: Mark-sweep 1306.9 (1405.9) -> 1306.9 (1414.9) MB, 1826.0 / 0.0 ms [allocation failure] [GC in old space requested].
1329363 ms: Mark-sweep 1306.9 (1414.9) -> 1306.9 (1414.9) MB, 1903.1 / 0.0 ms [allocation failure] [GC in old space requested].
1331374 ms: Mark-sweep 1306.9 (1414.9) -> 1313.4 (1405.9) MB, 2010.3 / 0.0 ms [last resort gc].
1333333 ms: Mark-sweep 1313.4 (1405.9) -> 1319.9 (1405.9) MB, 1958.0 / 0.0 ms [last resort gc].

<--- JS stacktrace --->

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

Security context: 000002E7514CF791
2: with_parens [000002E751404381 :~5813] [pc=000002F02F5400F6] (this=000001E1DBFE4699 ,cont=000000E96E71C3A9 3: /* anonymous /(aka / anonymous */) [000002E751404381 :6817] [pc=000002F02FE08F44] (this=000002E751404381 ,self=00000314C2BB6571

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

[JonathanYates]

Any update on this? This issue was raised back in March and is now manifesting itself in Angular 5 (and 4) prod builds. Seems somehow to be related to HttpClient.

Please can you investigate as a priority as we can not go to production using Angular 5, which is currently not fit for purpose.

[hugodes]

@JonathanYates https://github.com/angular/angular-cli/issues/5618#issuecomment-343244854

[JonathanYates]

Yes I know, that was 5 days ago. I am asking for an update.

[MichalEmbiq]

Same issues, should build app without problems with ng build --prod

@filipesilva: I'm asking for an update date.

[etiennetalbot]

@andremarcondesteixeira we will all do what we please. This isn't the place to try to convince anybody to use another framework.

[jmcclanahan]

@JonathanYates @MichalEmbiq @andremarcondesteixeira - Have you guys tried what @filipesilva suggested in #5618 (comment)? That seems to have worked for most people and it also worked for me. Seems like a sufficient work-around until the real issue is solved.

[JonathanYates]

@jmcclanahan @filipesilva

ng serve : SUCCESS
ng build : SUCCESS

ng build --prod : FAIL
ng build --prod --build-optimizer=false : FAIL
ng build --aot : FAIL
ng build --aot --build-optimizer : FAIL

output as per https://github.com/angular/angular-cli/issues/5618#issuecomment-343765822

It also takes several 'minutes' hung at 92% before producing an error.

How do you suggest I produce a production build?

[seanlandsman]

Hi @filipesilva

• What version of the CLI and Angular are you on?
  1.5

• Does this only happen on ng build --prod?
  No, with --aot and --build-optimizer it fails too (see below)

• Do you still get the memory error with these build commands:
  For the commands that fail, it can be intermittent - ie. fail 4/5 times, but pass on the 5th
  ng build --build-optimizer=false: Passes
  ng build --aot: Passes
  ng build --aot --build-optimizer: Fails

I can get these to pass 100% of the time by increasing the amount of available memory (ie: node --stack_size=4048 node_modules/.bin/ng build --prod | OR by --build-optimizer=false)

I've created a simple repo of the problem here: https://github.com/seanlandsman/build-optimiser-issue

Steps to reproduce:
npm install
npm run prod (note: this fails most of the time, but very occasionally it will pass)

thanks

[JonathanYates]

I don't think increasing the node --stack_size is a good idea. All that will do is mask the real issue here. The build should not be gobbling up so much memory. There is a fundamental problem that needs to be fixed.

[MichalEmbiq]

Think about CI, some environments don't have so much memory. How this "feature" pass tests? Why issue is closed?

[joecot]

1) The issue is not "closed". It's both open and marked urgent.
2) No one is suggesting that increasing the stack size is a permanent solution
3) angular-cli developers have chimed in indicating they're taking the issue seriously and requested feedback on which builds were having issues.

If folks want to complain about memory requirements, they can. If folks want to say it's unreasonable this bug exists, they can. If folks want to encourage people to no longer use Angular, they can. The developers are already looking at this, no amount of vitriol will make that faster. In the mean time, add a swap volume, increase the stack size, and subscribe to the issue for updates -- which unfortunately will likely be mostly complaints for a while.

[josephliccini]

Not sure if this is just my experience or not, but in cases where I had template errors (used a non-public variable in template, used the wrong type for an @Input(), etc.) I would see the memory usage climb really high, and then crash the build. My suggestion is to make extra sure that there are no template errors. This can be done by invoking ngc directly on the project. Not sure if that will help, just sharing my experience.

[filipesilva]

Hey all,

I've been running a bunch of memory profiles on projects to try and figure out what the cause is. I'm comparing projects using CLI 1.5.0 + Angular 5.0.0 + Typescript 2.4.2 against CLI 1.4.9 + Angular 4.4.6 + Typescript 2.3.2. Special thanks to everyone that provided repros, that helps a lot.

@magemello I'm having some trouble building your project. It seems to be a couple of missing style variables (like $alfresco-typography). I assume I have to build these before the app. Can you tell me what the missing steps are? This is what I did:

git clone https://github.com/Alfresco/alfresco-ng2-components
cd alfresco-ng2-components
cd demo-shell-ng2
git checkout development
npm install
npm run ng -- build --prod --build-optimizer # errors on Undefined variable: "$alfresco-typography".

@seanlandsman I could not reproduce with the repository you linked. I got the same results with 1.4.9 as I did with 1.5.0. Builds seemed to finish in roughly the same amount of time, and consume a maximum of 500 MB of memory. Bundle sizes were also the same (more on that in a second). Can you think of anything I might be missing? I'm on Windows 10, node 8.9.1.

@teabagp using your repro (https://github.com/angular/angular-cli/issues/8457#issuecomment-344325608) I saw both a bundle size increase (500kB to 4MB) in 1.5.0 and a memory usage increase (from 580 to 1080 MB). This is the only community repro I really have at the moment, if someone else has a project I can look at please let me know.

The last repro is specially relevant because it shows this problem even in a small project. Those of you that ran into memory problems that went away after increasing the memory limit, can you tell me if your bundles also got significantly bigger?

Based on @teabagp's repro, this is what I can currently say:

• this seems to be related to the library used (devextreme and devextreme-angular),
• memory usage seems normal up until the "92% asset optimization" phase, then dramatically increases,
• switching build optimizer off doesn't change this,
• switching to the old uglify doesn't change this,
• I don't think it's directly related to the new TS compiler since that runs at the 10% building modules phase and memory usage seems normal then.

At the moment I don't think the 1.5 memory usage increase is directly related to either Build Optimizer or Sourcemaps. Both of these increase memory usage by virtue of doing more thing. So bigger projects should indeed use more memory. We should still keep this under control but for the 1.5 specific problem it doesn't seem to be the root cause.

[hanvyj]

@filipesilva

Those of you that ran into memory problems that went away after increasing the memory limit, can you tell me if your bundles also got significantly bigger?

Yes, main bundle increased by roughly 4MB. Sadly the project isn't open source, but it's pretty complex anyway the other project is a better example to try diagnose I think.

[magemello]

Hi @filipesilva,

sorry for not providing you more information on how to run it correctly:

cd scripts
./update-version.sh -v 2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432
cd ..
cd demo-shell-ng2
npm install
npm run ng -- build --prod --build-optimizer 


> [email protected] ng /Users/mromano/dev/alfresco-ng2-components/demo-shell-ng2
> ng "build" "--prod" "--build-optimizer"

 92% chunk asset optimization

[filipesilva]

@magemello I'm on windows and unfortunately that script doesn't seem to be very windows friendly even with gitbash...

kamik@T460p MINGW64 /d/sandbox/memory/alfresco-1.4/scripts (development)
$ ./update-version.sh -v 2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432
====== New version 2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432 =====
====== UPDATE COMPONENTS ======
====== clean lock file ng2-alfresco-core ======
rm: cannot remove '/d/sandbox/memory/alfresco-1.4/scripts/../ng2-components/ng2-alfresco-core/package-lock.json': No such file or directory
====== UPDATE COMPONENT ng2-alfresco-core ======
====== UPDATE PACKAGE VERSION of  to 2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432 version in all the package.json ======
sed: can't read s/"version": "[0-9]\.[0-9]\.[0-9]"/"version": "2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432"/g: No such file or directory
====== UPDATE DEPENDENCY VERSION of ng2-alfresco-core to ~2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432 in ng2-alfresco-core======
sed: can't read s/"ng2-alfresco-core": "[0-9]\.[0-9]\.[0-9]"/"ng2-alfresco-core": "2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432"/g: No such file or directory
sed: can't read s/"ng2-alfresco-core": "~[0-9]\.[0-9]\.[0-9]"/"ng2-alfresco-core": "~2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432"/g: No such file or directory
====== UPDATE DEPENDENCY VERSION of ng2-alfresco-datatable to ~2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432 in ng2-alfresco-core======
sed: can't read s/"ng2-alfresco-datatable": "[0-9]\.[0-9]\.[0-9]"/"ng2-alfresco-datatable": "2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432"/g: No such file or directory
sed: can't read s/"ng2-alfresco-datatable": "~[0-9]\.[0-9]\.[0-9]"/"ng2-alfresco-datatable": "~2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432"/g: No such file or directory
====== UPDATE DEPENDENCY VERSION of ng2-alfresco-upload to ~2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432 in ng2-alfresco-core======
sed: can't read s/"ng2-alfresco-upload": "[0-9]\.[0-9]\.[0-9]"/"ng2-alfresco-upload": "2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432"/g: No such file or directory
sed: can't read s/"ng2-alfresco-upload": "~[0-9]\.[0-9]\.[0-9]"/"ng2-alfresco-upload": "~2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432"/g: No such file or directory
====== UPDATE DEPENDENCY VERSION of ng2-activiti-diagrams to ~2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432 in ng2-alfresco-core======
sed: can't read s/"ng2-activiti-diagrams": "[0-9]\.[0-9]\.[0-9]"/"ng2-activiti-diagrams": "2.0.0-6a24c6ef754f24212bdd7120d5cdbe47b83c3432"/g: No such file or directory

Is there something I can do even if hacky to get around the need for it? Ideally without removing the global styles as I'm also investigating if style processing is using a lot of memory.

[filipesilva]

@hanvyj thanks for confirming that!

[randyaa]

@filipesilva
We started experiencing this pretty significantly in CLI 1.3 & it got worse with 1.4 and so we downgraded to 1.2.6 and haven't had any problems since. we're still running ng 4.4.6 with cli 1.2.6 and it seems fine with default settings.

I don't have a ton of time to dig into this right now so i'm sorry this won't be _super_ helpful but just wanted to let you know where the version numbers went wrong.

We are locked into the following specific versions (along with material 2.0.0-beta.12). if we change JUST cli to 1.3 or 1.4 (and presumably 1.5) we see the issue:

  "dependencies": {
    "@angular/animations": "4.4.6",
    "@angular/cdk": "2.0.0-beta.12",
    "@angular/common": "4.4.6",
    "@angular/compiler": "4.4.6",
    "@angular/core": "4.4.6",
    "@angular/forms": "4.4.6",
    "@angular/http": "4.4.6",
    "@angular/material": "2.0.0-beta.12",
    "@angular/platform-browser": "4.4.6",
    "@angular/platform-browser-dynamic": "4.4.6",
    "@angular/router": "4.4.6",
    "@ngrx/store": "4.0.3",
    "@ngrx/store-devtools": "4.0.0",
    "core-js": "2.4.1",
    "dexie": "1.5.1",
    "font-awesome": "4.7.0",
    "fs-extra": "2.0.0",
    "hammerjs": "2.0.8",
    "lodash": "4.5.0",
    "lscache": "1.0.5",
    "moment": "2.17.1",
    "net": "1.0.2",
    "ng-diff-match-patch": "2.0.6",
    "ng2-file-upload": "1.2.0",
    "ng2-select": "1.2.0",
    "ngx-infinite-scroll": "0.5.1",
    "normalizr": "2.1.0",
    "primeng": "4.1.3",
    "rxjs": "5.4.3",
    "stompjs": "2.3.3",
    "zone.js": "0.8.14"
  },
  "devDependencies": {
    "@angular/cli": "1.2.6",
    "@angular/compiler-cli": "4.4.6",
    "@compodoc/compodoc": "1.0.3",
    "@types/jasmine": "2.5.53",
    "@types/jasminewd2": "2.0.2",
    "@types/lodash": "4.14.65",
    "@types/lscache": "1.0.27",
    "@types/node": "6.0.60",
    "@types/normalizr": "2.0.16",
    "agentkeepalive": "^3.3.0",
    "codelyzer": "3.1.2",
    "jasmine-core": "2.6.2",
    "jasmine-spec-reporter": "4.1.0",
    "karma": "1.7.0",
    "karma-chrome-launcher": "2.1.1",
    "karma-cli": "1.0.1",
    "karma-coverage-istanbul-reporter": "1.2.1",
    "karma-firefox-launcher": "1.0.0",
    "karma-jasmine": "1.1.0",
    "karma-jasmine-html-reporter": "0.2.2",
    "karma-phantomjs-launcher": "1.0.2",
    "node-sass": "4.5.3",
    "phantomjs-prebuilt": "2.1.7",
    "protractor": "5.1.2",
    "suitcss-components-grid": "3.0.3",
    "suitcss-utils-size": "1.1.0",
    "ts-node": "3.2.0",
    "tslint": "5.3.2",
    "typescript": "2.4.2"
  }

We were hoping to upgrade soon so glad to see some focus on the issue. Thanks so much!

[magemello]

I have executed it for you:

git checkout dev-filipesilva 
cd demo-shell-ng2
npm install
npm run ng -- build --prod --build-optimizer 

[seanlandsman]

@filipesilva

I've just tried on a clean install and it still fails for me. I'm on OSX Sierra and am running node v7.7.3

I also note that if I run ng build --prod --build-optimizer=false it will run successfully repeatedly, whereas running just ng build --prod will fail most of the time.

I'm not sure what I can add here - is there some sort of profiling I can run on my side and provide the output?

thanks

[rajravat]

this is also affecting me, using angular 5 and cli 1.5, ive had to switch off the build optimizer to get my builds to pass without a out of memory error :(

[filipesilva]

@seanlandsman do the bundle sizes remain the same?

[seanlandsman]

@filipesilva

With "node --stack_size=4048 node_modules/.bin/ng build --prod" I get:

1.4K 14 Nov 20:43 inline.aa760cefdeaeea9e038f.bundle.js
835K 14 Nov 20:43 main.05e5301d42766024fc03.bundle.js
60K 14 Nov 20:43 polyfills.e6475d2787bb3154d59c.bundle.js
48K 14 Nov 20:43 styles.9b2fb464224d0a79781d.bundle.css

With "./node_modules/.bin/ng build --prod --build-optimizer=false" I get:

1.4K 14 Nov 20:45 inline.d7125ae6ed51e3e3af81.bundle.js
4.9K 14 Nov 20:45 main.47d0056e07ee5cb9c483.bundle.js
60K 14 Nov 20:45 polyfills.ad37cd45a71cb38eee76.bundle.js
48K 14 Nov 20:45 styles.9b2fb464224d0a79781d.bundle.css
951K 14 Nov 20:45 vendor.799da157f41ee457e4bd.bundle.js

Interestingly you can see the main.xx.js got much bigger with in the first run, but the vendor file disappeared. This might be expected?

One further bit of information - I just tried this on an older Mac running El Capitan (node version v7.7.3) that I've not used for a while. When I run "node_modules/.bin/ng build --prod" it runs just fine, repeatedly, and much faster than on my current machine. Hopefully this is helpful.

thanks

[Dunos]

@filipesilva our build also got increased by 3MB or 4MB like the last example you said, taking a long time after the 92%, and we also use the devextreme libraries. Can't share the project repo unfortunately but I could provide our package.json if neeeded.

[dzonatan]

@filipesilva try to reduce the stack_size to reproduce the @seanlandsman case.
node --stack_size=512 node_modules/.bin/ng build --prod gets me that error on my mac.

[cecotw]

@filipesilva
What version of the CLI and Angular are you on?
1.5 and 5.0.0 respectivley
Does this only happen on ng build --prod?
Only when the --aot flag is use.
Do you still get the memory error with these build commands:
ng build --build-optimizer=false
no
ng build --aot
yes
ng build --aot --build-optimizer
yes
If you have a project that I can look at, can you link it please?
Sorry, but our application is private per our corporate requirements.

[alvachien]

@jmcclanahan @filipesilva

ng serve : SUCCESS
ng build : SUCCESS

ng build --prod : FAIL
ng build --prod --build-optimizer=false : FAIL
ng build --aot : FAIL
ng build --aot --build-optimizer : FAIL

output as per #5618 (comment)

It also takes several 'minutes' hung at 92% before producing an error.

Is there any workaround to bypass it?
It is not working with the --max_old_space_size=8192

[JackArlington]

I have the same problem. I also recognized that the size of my application with ng serve drastically increased after the update to angular 5. With angular 4 the vendor.bundle.js created by ng serve used to be 10MB and with angular 5 it is now 30MB.

ng serve -> works
ng build -> works
ng build --prod -> fails
ng build --prod --build-optimizer=false -> fails
ng build --aot -> fails
ng build --aot --build-optimizer=false -> fails

[magemello]

@filipesilva we all could also help debugging the webpack build, what tool are you using to debug it?
I was trying like that, but I'm not sure is the best way:

node-nightly --inspect-brk ./node_modules/@angular/cli/bin/ng build --prod

If you give me more instructions here or on Gitter I will be more than happy to help.

[filipesilva]

Heya, using the repros you all provided I believe I've found the main problem with 1.5. It has to do with how the new pipeline moved decorator removal into Build Optimizer.

For those interested in a more detailed explanation, this is what happens:

• When you build with --aot, we use TypeScript transforms in Build Optimizer to remove Angular decorators (stuff like @Component and @NgModule) from both your app and libraries (they aren't needed after AOT).
• In 1.4 we didn't use Build Optimizer for that, we used manual removal on your app only.
• Due to a bug, decorators are removed but their imports stay in the code.
• These imports make some third party libs be wholly included, instead of only partially included.
• You can check this yourself by comparing ng build --aot when using CLI1.4.9+NG4 versus CLI1.5.0+NG5.
• In the devextreme lib case, there was almost 9megs of extra code included.
• Extra code means a lot more work for Uglify, which makes it consume a lot more memory.

There might be more factors contributing to the excessive memory usage but currently this is the approach I'm following as it's the most promising one. I hope to have a PR with a fix soon.

[radoslavpetranov]

@filipesilva awesome news! Thanks for sharing your progress - very much appreciated!

Some of us are experiencing this in non-latest-version setups and others all the way back in cli 1.2 and 1.3 setups. Do you believe this is just a natural limitation and expected behavior due to the size of the projects/dependencies? Is the default <2GB RAM allocation just naturally too small for compiling bigger projects?

[filipesilva]

@radoslavpetranov I have been thinking about that (@randyaa said the same thing as you), and trying to figure out what a good approach is.

Something that springs to mind is to split up into multiple processes. But upon further scrutiny that approach doesn't really help in the memory usage problem, since multiple process will use at least the same total memory, probably more due to inefficiencies and duplication.

The 1.5 problem highlighted how much Build Optimizer actually helps keep memory usage down by trimming imports (and thus project size). So maybe that's an overall better approach. It does imply that a project must be able to use Build Optimizer though, and there might still be problems with it (code manipulation is tricky).

Another approach might be to took a look at the Uglify memory usage in large bundles. Maybe there room for config tuning or something. But it's hard to say since those tools really rely on a semantic understanding of code bundles to work, so one does expect a lot of memory used on larger bundles.

Something else that I've been thinking about is to actually have a low memory setting, where disk/cpu/total time is traded for a smaller memory footprint. This is just a very high level idea that I haven't explored at all. It would help on limited environments like CI, whereas for dev environments you really want the tradeoffs that give you better rebuild/speeds instead.

For really large projects you just can't get around the fact there are more performant languages than JS and that build tools that can use them effectively (like Bazel) will offer a better experience.

[erlloyd]

@filipesilva - Thanks for investigating this. Here's another data point, fwiw:

What version of the CLI and Angular are you on?
1.5.0 and 5.0.0
Does this only happen on ng build --prod?
Seems to be building fine without the --prod flag

Do you still get the memory error with these build commands:

ng build --build-optimizer=false
no
ng build --aot
no
ng build --aot --build-optimizer
no

If you have a project that I can look at, can you link it please?
Sorry, private repository and project

[mattem]

@filipesilva Thanks for the update and explanation, however we experience this with our projects using cli 1.4.7 and angular 4.4.5 (and early versions too). Currently to build our production version we use the following:

ng build --environment=prod --aot --sourcemaps=false --base-href=\"/ui/\" --preserve-symlinks --output-hashing=all --extract-css=true

We then pass the output to Uglify to minify and mangle the JS and CSS. This process works correctly and we do not hit memory issues, but when we build with ng build --prod that is when we run into memory issues.

We also do not have the devextreme lib. I can't share our code, but I'm happy to install other versions of the CLI and post build results from different commands. Our application is approx 450 components and 290 modules.

[Tolitech]

Hello @filipesilva
I don't know exactly if this my comment might be useful, but I will report some tests that I did.

I have an angular-cli (1.4.1), angular (4.4.4), typescript (2.3.4) project.
This project contains approximately 200 services and more than 700 components, distributed in at least 15 modules.

When running ng build --prod I noticed a few things.
In this specific project, 0 to 1.9 GB of memory occurs up to the first 10% of the compilation.
(I'm using the saas files from bootstrap).

From the 11% up to the 89% compilation, my memory goes up to less than 3 GB.

From 90% to 92% the memory is used in 4.6 GB.

And finally at 95% the consumption goes up to the maximum limit allowed.
In my case now, up to the 6 GB of RAM I've bound.

To make it compile, I had to configure virtual memory (swap).
I have only 8 GB RAM.

I increased to 12 GB, 16 GB, until finally I was able to compile the project by setting 32 GB RAM.

Consumption of NodeJS hit 28 GB at these same 95% emitting.

Unfortunately this project is private and would not be able to make it available.

Tests requested:

ng build --build-optimizer=false works! 1.5 GB max.

ng build --aot error!

To try to help, I created a very simple project.
In it, there are 10 modules created.
In each module, there are 50 components created.
In each component there is only one HTML with output "works!".

There is no CSS, there is no third-party npm component.
A simple project like this is consuming 1.6 GB of RAM for the AOT build.

I believe that consumption is a little high because it contains absolutely nothing in the project.
If you wanted to download the repository to test, it is zipped in the link below.
http://www.codegenerator.com.br/downloads/ng-heap-memory.zip

Thanks in advance for your help.

[filipesilva]

I've put up a PR that should specifically address the memory usage regression when using 1.5 (https://github.com/angular/angular-cli/pull/8506). Once it's merged and released I'll ping you all here to see if it helped across your projects.

@Tolitech your report of how memory usage changed with build stage was very interesting and useful. Below the 92% stage what happens is TypeScript compilation and loading files into Webpack. After that it's mostly Uglify and Build-Optimizer.

But since you are on 1.4.1 you shouldn't have Build Optimizer by default with --prod. Just to double check, can you confirm that you are not using --build-optimizer?

In your report you mention using what I consider a large project (200 services and 700 components). Definitely not the largest around but still big. I'm not surprised at a 3GB memory usage for TS compilation and loading all app files.

But when it starts getting really bad is after that, when you end up needing at least 28GB at the 92% phase. This to me tells me the bottleneck is Uglify, or maybe some other part of our build pipeline that I'm not seeing right now. But it definitely bears investigating, which I'll do.

Running the small ng-heap-memory project as is I saw a maximum of 1.4GB ram being used. Using the PR this dropped to around 800MB, so it seems to be helping there. I agree that the 500 components are essentially empty, but it doesn't surprise me that just the sheer number of them causes high memory consumption on a build. It's a valuable example by the way, and thank you for making it.

@mattem that's a very interesting approach, and doubly interesting is that you don't suffer much memory issues with it. Can I ask you to give me some concrete numbers for comparison please? Maximum memory usage on a CLI prod build versus CLI non-prod plus manual Uglify. I'd also like to know your uglify version and settings please.

[Tolitech]

Hello, @filipesilva
Yes, I confirm that I'm using without --build-optimizer.
Just ng build --prod.

And thanks for the feedback.

[WandererInVoids]

@filipesilva i used same workaround i described it in my comment https://github.com/angular/angular-cli/issues/5618#issuecomment-343224021

command
ng build --app homeapp -aot=true -e=prod -sm=false -ec=true --named-chunks=false -oh=all --build-optimizer=true -vc=true

my memory usage:
0 % -18 % <= 828 mb
18% -89 <= 1140 mb
90 - 100 < 1253 mb

difference between --build-optimizer=true and false 90 mb

for uglify used gulp-uglify^3.0.0 default settings 1058 mb
also i used gulp-postcss for uglify and autoprefixer all latest version

@angular 5.0.1
@angular/cli 1.5.0

[mattem]

@filipesilva Using ng build --prod gave the OOM error, however running the CLI with node --max_old_space_size=8192 it did complete, with the following memory usage (observed from looking at Activity Monitor in MacOS):

• ~ 14% 800mb real / 5.5gb virtual
• ~ 69% 1.5gb real / 6.4gb virtual
• ~ 90% 1.8gb real / 6.65gb virtual
• ~ 92% 2.3gb real / 7gb virtual
• ~ 94% 2.6gb real / 7.12gb virtual

Running with ng build --environment=prod --aot --sourcemaps=false --base-href="/ui/" --preserve-symlinks --output-hashing=all --extract-css=true (no increasing max_old_space) tops out at 1.49gb real / 6.23gb virtual. This is running with @angular/[email protected] and @angular/*@4.4.5

We use [email protected], giving us [email protected], setting compress and mangle to true.
The output is also run though loose-envify, uglifycss, and htmlmin
The gulp task peaks at 868mb real / 5.57gb virtual.

[PeS82]

According to changelog the above mentioned fix is included in 1.5.1+. It still fails for ng build --prod with 1.5.2 :(

95% emitting
<--- Last few GCs --->

[4980:000001B75DBAB8D0] 268298 ms: Mark-sweep 1399.5 (1698.5) -> 1399.5 (1698.5) MB, 483.4 / 0.0 ms allocation failure GC in old space requested
[4980:000001B75DBAB8D0] 268868 ms: Mark-sweep 1399.5 (1698.5) -> 1399.5 (1629.5) MB, 569.7 / 0.0 ms last resort GC in old space requested
[4980:000001B75DBAB8D0] 269387 ms: Mark-sweep 1399.5 (1629.5) -> 1399.5 (1600.0) MB, 518.8 / 0.0 ms last resort GC in old space requested

<--- JS stacktrace --->

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

Security context: 00000185B7C25EC1
1: DoJoin(aka DoJoin) [native array.js:~95] [pc=0000002F55357679](this=00000075A3182311 ,p=0000001FB1A5B831 ,A=00000185B7C6EC69 )
2: Join(aka Join) [native array.js:~120] [pc=0000002F550C6489](this=00000075A3182311 ,p=0000001FB1A5B831

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

[jayhamilton]

Still encountering this issue with angular cli 1.5.2

`ng build --aot --prod
95% emitting
<--- Last few GCs --->

209426 ms: Mark-sweep 1512.7 (1406.8) -> 1512.5 (1406.8) MB, 453.1 / 0.0 ms [allocation failure] [GC in old space requested].
209905 ms: Mark-sweep 1512.5 (1406.8) -> 1513.6 (1403.8) MB, 479.5 / 0.0 ms [last resort gc].
210359 ms: Mark-sweep 1513.6 (1403.8) -> 1514.7 (1403.8) MB, 453.6 / 0.0 ms [last resort gc].

<--- JS stacktrace --->

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

Security context: 0x4353ac3fa99
1: SparseJoinWithSeparatorJS(aka SparseJoinWithSeparatorJS) [native array.js:~75] [pc=0x1e05abc97c4a] (this=0x4353ac04241 ,w=0x1a58c504381 2: DoJoin(aka DoJoin) [native array.js:~129] [pc=0x1e05abb3c1b6] (thi...

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::Local) [/usr/local/bin/node]
3: v8::internal::V8::FatalProcessOutOfMemory(char const, bool) [/usr/local/bin/node]
4: v8::internal::Factory::NewRawTwoByteString(int, v8::internal::PretenureFlag) [/usr/local/bin/node]
5: v8::internal::Runtime_SparseJoinWithSeparator(int, v8::internal::Object*, v8::internal::Isolate) [/usr/local/bin/node]
6: 0x1e0596e060c7
Abort trap: 6
Jays-MacBook-Pro:ngx-dynamic-dashboard-framework jayhamilton$ ng --version

_                      _                 ____ _     ___

/ \ _ __ __ _ _ _| | __ _ _ __ / ___| | |_ _|
/ △ \ | '_ \ / _| | | | |/ _ | '__| | | | | | |
/ ___ \| | | | (_| | |_| | | (_| | | | |___| |___ | |
/_/ __| |_|__, |__,_|_|__,_|_| ____|_____|___|
|___/

Angular CLI: 1.5.2
Node: 6.11.1
OS: darwin x64
Angular: 5.0.1
... animations, common, compiler, compiler-cli, core, forms
... http, platform-browser, platform-browser-dynamic, router

@angular/cdk: 2.0.0-beta.12
@angular/cli: 1.5.2
@angular/material: 2.0.0-beta.12
@angular-devkit/build-optimizer: 0.0.33
@angular-devkit/core: 0.0.20
@angular-devkit/schematics: 0.0.36
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.8.2
@schematics/angular: 0.1.5
typescript: 2.6.1
webpack: 3.8.1
`

[finalxcode]

@jayhamilton +1 https://github.com/swimlane/ngx-datatable/issues/1104#issuecomment-342528502

[filipesilva]

Hey all, 1.5.2 includes the fix for the 1.5 memory usage regression. This should help users that had projects that did not have memory problems on 1.4 but started having them in 1.5.

Projects that were already having memory problems in 1.4 should see no change. I'm still looking into the balooning memory requirements for the 92% bundle optimizing phase.

@PeS82 @jayhamilton @finalxcode you reported that you're still running into memory problems with 1.5.2. Was this on projects that did not have memory problems in 1.4.x?

[finalxcode]

@filipesilva With angular cli 1.4.x it used to work, then when i upgrade angular/cli to 1.5.2, it have memory problems, i have to use command node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build --prod --aot to build

[JackArlington]

@filipesilva with cli 1.5.2 my project fails at 95%. With angular cli 1.4.x it used to work.

[Shadowlauch]

@filipesilva @JackArlington same for me. Our project used to build (prod) on 1.4.x and since 1.5.0 does not anymore. 1.5.2 didnot improve the situation. When I increase the memory limit it does compile, but uses aprox 5GB on emitting.

On a side not the huge memory consuption occurs on "95% emitting"

[JackArlington]

@filipesilva @Shadowlauch I have just recognized that the machine I tested before had node 6.x upgrading it to 8.9.1 solved the problem and ng build --prod --aot works now.
Thank you for the help.

[filipesilva]

To be clear, I am not aware of any memory issue related specifically to Node 6. I have been testing with Node 8.9.1 myself because I couldn't get memory timelines using Chrome Devtools with Node 6.

Maybe that's part of the equation here... I expect newer nodes to be faster and more memory efficient but perhaps there's more to it.

For instance, I couldn't repro the problem on @seanlandsman's project. @seanlandsman what version of node were you using?

[Shadowlauch]

I had node 6.x aswell and after upgrading to 8.9.1 it works now. @JackArlington thanks for the tip!

[seanlandsman]

@filipesilva I'm on node 7.7.3

Edit: I've just upgrade the test repo to 1.5.2 and retried - it still fails I'm afraid.

Did you try running with "node --stack_size=512 node_modules/.bin/ng build --prod" to see if this helps reproduce what I'm seeing?

thanks again

[changLiuUNSW]

@filipesilva
I do not get heap out of memory error anymore with cli 1.5.2. My node version is 7.5.0.
However the build still takes about 8 - 10 minutes to finish.

[magemello]

@filipesilva I have updated the version and I'm still having the same problem :(

ng build --prod --aot

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

[70119:0x103000800]   221253 ms: Mark-sweep 1412.4 (1539.6) -> 1412.4 (1527.1) MB, 2772.9 / 0.0 ms  (+ 0.0 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 2773 ms) last resort 
[70119:0x103000800]   223828 ms: Mark-sweep 1412.4 (1527.1) -> 1412.4 (1527.1) MB, 2574.0 / 0.0 ms  last resort 


<--- JS stacktrace --->

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

Security context: 0x1174077a8799 <JSObject>
    2: add_parameter [0x35ed60282311 <undefined>:2953] [bytecode=0x2a011d5e84c1 offset=69](this=0x1dee67b6c479 <Object map = 0x13abb57fc8b1>,token=0x3e75c751c6b9 <AST_Token map = 0x2edf31c836a1>)
    4: binding_element(aka binding_element) [0x35ed60282311 <undefined>:3236] [bytecode=0x2a011d5e6669 offset=2234](this=0x35ed60282311 <undefined>,used_parameters=0x1dee67b6c479 <Object map = 0x13abb57...

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

Here are the versions which I'm using:

    _                      _                 ____ _     ___
   / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
  / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
 / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
/_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
               |___/

Angular CLI: 1.5.2
Node: 8.5.0
OS: darwin x64
Angular: 5.0.2
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

@angular/cdk: 5.0.0-rc0
@angular/cli: 1.5.2
@angular/flex-layout: 2.0.0-beta.10
@angular/material: 5.0.0-rc0
@angular-devkit/build-optimizer: 0.0.33
@angular-devkit/core: 0.0.20
@angular-devkit/schematics: 0.0.36
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.8.2
@schematics/angular: 0.1.5
typescript: 2.4.2
webpack: 3.8.1

If you give me enough instruction on how you debug the webpack build I can help find the source of the problem....

[jinder]

Can confirm that it's fixed the problem for us. Using 1.5.2 and Node 9.2.0 - no longer need to increase Node memory.

[Dunos]

With the new 1.5.2 release, my memory problem and bundle size haven been fixed, it still takes some time stuck at the 92% but works in the end.

[filipesilva]

@seanlandsman I tested your repros again with --stack_size=512 and --stack-size=8048 and only saw memory consumption in the 400-500MB range. The default seems to be --stack_size=984 btw.

I did see something else though:

kamik@T460p MINGW64 /d/sandbox/memory/aggrid-1.5 (master)
$ npm run prod

> [email protected] prod D:\sandbox\memory\aggrid-1.5
> node --stack_size=512 ./node_modules/@angular/cli/bin/ng build --prod

Date: 2017-11-17T10:46:12.052Z
Hash: db122ac832a501fd0cf8
Time: 31443ms
chunk {0} main.67d8219d9d4c87c59477.bundle.js (main) 830 kB [initial] [rendered]
chunk {1} polyfills.e6475d2787bb3154d59c.bundle.js (polyfills) 61.1 kB [initial] [rendered]
chunk {2} styles.9b2fb464224d0a79781d.bundle.css (styles) 49 kB [initial] [rendered]
chunk {3} inline.d67e755da47b31497a24.bundle.js (inline) 1.45 kB [entry] [rendered]

ERROR in ./node_modules/ag-grid/dist/lib/gridOptionsWrapper.js
Module build failed: RangeError: Maximum call stack size exceeded
    at getJSDocsWorker (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:8167:33)
    at getJSDocs (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:8163:13)
    at getJSDocTags (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:8148:27)
    at getJSDocParameterTags (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:8213:20)
    at Object.isRestParameter (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:8295:28)
    at symbolToParameterDeclaration (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:29262:41)
    at D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:29215:89
    at Array.map (<anonymous>)
    at signatureToSignatureDeclarationHelper (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:29215:55)
    at createTypeNodeFromObjectType (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:29024:49)
    at createAnonymousTypeNode (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:28988:42)
    at typeToTypeNodeHelper (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:28938:28)
    at createTypeNodesFromResolvedType (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:29177:67)
    at createTypeNodeFromObjectType (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:29035:35)
    at createAnonymousTypeNode (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:28988:42)
    at typeToTypeNodeHelper (D:\sandbox\memory\aggrid-1.5\node_modules\typescript\lib\typescript.js:28938:28)
 @ ./node_modules/ag-grid/dist/lib/columnController/columnUtils.js 11:27-59
 @ ./node_modules/ag-grid/main.js
 @ ./node_modules/ag-grid-angular/dist/ng2FrameworkFactory.js
 @ ./src/app/app.component.ngfactory.js
 @ ./src/app/app.module.ngfactory.js
 @ ./src/main.ts
 @ multi ./src/main.ts

This seems consistent with what --stack-size actually does (https://github.com/nodejs/node/issues/6360). It doesn't increase total available memory, but rather the the size of each stack region that node uses. It that increasing it can solve issues with a lot of recursion (but that code should try to not have that).

The symptoms seem to be different on OSX (memory bust) and Windows (maximum call stack size exceeded). I don't know why that is.

I think the problem you're experiencing is solely related to Build Optimizer as you posited, and is the one tracked in https://github.com/angular/devkit/issues/240. Still relevant for this thread mind you, but the specific issue is that one.

@changLiuUNSW were your build times with 1.4.x shorter, and if so, by how much?

@magemello I'll ping you on the gitter you provided and see what we can do in your project.

[changLiuUNSW]

@filipesilva
I do not have a chance to try 1.4.x because we used CLI 1.3.0 in our project before
Angular CLI 1.3.0 with Angular 4.2.4

ng build --prod
[14:08:02][Step 4/15] Time: 236558ms
[14:08:02][Step 4/15] chunk {0} polyfills.6bb91be4d06bd2c9e250.bundle.js (polyfills) 217 kB {4} [initial] [rendered]
[14:08:02][Step 4/15] chunk {1} main.71c6b1116dc39af75599.bundle.js (main) 1.59 MB {3} [initial] [rendered]
[14:08:02][Step 4/15] chunk {2} styles.21cad12ac9e3527f0f7d.bundle.css (styles) 166 kB {4} [initial] [rendered]
[14:08:02][Step 4/15] chunk {3} vendor.dfcfc494ca724bf884bf.bundle.js (vendor) 653 kB [initial] [rendered]
[14:08:02][Step 4/15] chunk {4} inline.f1134fc323101279dbaf.bundle.js (inline) 1.46 kB [entry] [rendered]

Angular CLI 1.5.2 with Angular 5.0.1

ng build --prod
[22:20:39][Step 4/15] Time: 530465ms
[22:20:39][Step 4/15] chunk {0} polyfills.953b2ea9f096cadfdccc.bundle.js (polyfills) 147 kB [initial] [rendered]
[22:20:39][Step 4/15] chunk {1} main.e2cfa60d1ec303d72a6a.bundle.js (main) 1.77 MB [initial] [rendered]
[22:20:39][Step 4/15] chunk {2} styles.b49f8f5ee25381105567.bundle.css (styles) 108 kB [initial] [rendered]
[22:20:39][Step 4/15] chunk {3} inline.2ae12ef65c8a9f6162ba.bundle.js (inline) 1.49 kB [entry] [rendered]

I understand in 1.5, --build-optimize is enable by default for production build, but 5 minutes difference between 1.5 and 1.3 is not good.

[filipesilva]

@changLiuUNSW I agree 5 minutes difference is a long time. Can you try --build-optimizer=false for now please?

[changLiuUNSW]

@filipesilva
Angular CLI 1.5.2 with Angular 5.0.1

ng build --prod --build-optimizer=false
Time: 163265ms
chunk {0} polyfills.cdff46cd9b1a8d656218.bundle.js (polyfills) 147 kB [initial] [rendered]
chunk {1} main.d1916123bd0e4aa2858f.bundle.js (main) 1.34 MB [initial] [rendered]
chunk {2} styles.d1f7c9f576103c62cb95.bundle.css (styles) 108 kB [initial] [rendered]
chunk {3} vendor.1fbdf23b6f274bb4005e.bundle.js (vendor) 639 kB [initial] [rendered]
chunk {4} inline.58b71d550a47f85197a5.bundle.js (inline) 1.5 kB [entry] [rendered]

6 minutes difference with build-optimizer=true

[magemello]

Thank you @filipesilva for your help, I did the following:

• Set Angular dependencies to 5.0.2
• Set Angular CLI to 1.5.2
• Delete node_modules & package-lock.json
• npm install

and now the result is the following:

• npm run ng -- build works
• ng build --aot fails
• node --max_old_space_size=30000 node_modules/.bin/ng build --aot works
• ng build --prod --build-optimizer=false fails
• node --max_old_space_size=30000 node_modules/.bin/ng build --prod --build-optimizer=false works
• node --max_old_space_size=30000 node_modules/.bin/ng build --prod fails

So, in general raise the max_old_space_size fix my issue at exception of the "ng build --prod", in this case my problem seems to be related to this: https://github.com/angular/angular/issues/20115.
In other words the problem seems to be the presence of ts files in my libraries and aot geting angry about it :), the solution for this point seems to be put ts file in the .npmignore and exclude it from the packages. (haven't test it yet)

I'm just reporting the finding, hopying it helps others....all the credit goes to @filipesilva.

[filipesilva]

@changLiuUNSW @Tolitech can I ask you to do some more advanced debugging if you have time? I don't have access to your projects but they seem good examples.

@changLiuUNSW Your project doesn't seem to have memory problems anymore but it is taking very long to build with Build Optimizer.

I think one of the build optimizer transformations is taking a very long time on your codebase, but I can't know which ones. I can tell you how to disable each one individually though.

You can do this in ./node_modules/@angular-devkit/build-optimizer/src/build-optimizer/build-optimizer.js. From line 63 to line 82, each transform is individually added to the getTransforms array. You can comment out each of the getTransforms.push( and that transform will not be added.

If you can do this for each one and time me how it impacts build time, I might be able to figure out which of the transforms is taking too long.

@Tolitech your project has problems with memory usage with 1.4.x, and you have already confirmed it does not use build optimizer. You reported that memory usage went up to 28gigs during a prod build.

I'd like to ask you to do a couple of things. First, can you tell me the memory usage of just ng build please?

Then, I'd like you to try to manually disable Uglify. This can be done in ./node_modules/@angular/cli/models/webpack-configs/production.js, line 111-117 (the new webpack.optimize.UglifyJsPlugin({ call). Comment those lines, and try to do a production build again (with increased memory limits). What was the maximum memory used?

I understand that debugging these things take time and appreciate that you take the time to do it. I'm doing the same things on projects I have access to but each project is different so it's very difficult to zone in on the exact issue without having access to the code. Asking you to do some tests is the next best thing.

[radoslavpetranov]

Running ng build --aot --prod yielded the following

Date: 2017-11-17T18:23:24.062Z
Hash: 7dff5d083d5a19785434
Time: 558874ms
chunk {0} polyfills.e8bddc586f67afdffd0d.bundle.js (polyfills) 65.6 kB [initial] [rendered]
chunk {1} main.ba0bc9f17d63868a89a3.bundle.js (main) 2.49 MB [initial] [rendered]
chunk {2} styles.cb450a88292b46f1511b.bundle.css (styles) 81 kB [initial] [rendered]
chunk {3} inline.0002f507274cf434cef2.bundle.js (inline) 1.45 kB [entry] [rendered]

took nearly 10 minutes but the build did complete and didn't exceed the 1.3GB RAM mark now. By the looks of it, the bundle also decreased in size. Before I was getting a main bundle of 1.98 MB and a vendor bundle of 1.51 MB and now I only seem to have a single main bundle of 2.49MB.

The dev bundle went from vendor 16MB and main 4.61MB to vendor 5.91MB and main 1.87MB and it didn't exceed the 800MB RAM mark.

This was generated with the following setup

Angular CLI: 1.5.2
Node: 6.11.0
OS: win32 x64
Angular: 5.0.2
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

@angular/cdk: 5.0.0-rc0
@angular/cli: 1.5.2
@angular/flex-layout: 2.0.0-beta.10-4905443
@angular/material: 5.0.0-rc0
@angular-devkit/build-optimizer: 0.0.33
@angular-devkit/core: 0.0.20
@angular-devkit/schematics: 0.0.36
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.8.2
@schematics/angular: 0.1.5
typescript: 2.6.1
webpack: 3.8.1

I'll update my node to the latest 8.* version and I'll see if this changes anything in terms of RAM consumption.

[markmaynard]

@filipesilva I was looking at the package.json for Angular:
"engines": { "node": ">=6.9.5 <7.0.0", "npm": ">=3.10.7 <4.0.0", "yarn": ">=1.0.2 <2.0.0" },
I've always taken the engines section to mean that those were the engines supported. Is running Node 8 officially supported or am I reading this all wrong?

[radoslavpetranov]

Well, interestingly, node 8.9.1 did complete the bundle nearly twice as fast (~5min 50 seconds) compared to node 6.11 and it did use about ~150-200MB less ram throughout the final (92%-95%) stages of the process.

Date: 2017-11-17T20:14:47.417Z
Hash: fd0232ebf712617a9dad
Time: 351019ms
chunk {0} polyfills.e8bddc586f67afdffd0d.bundle.js (polyfills) 65.6 kB [initial] [rendered]
chunk {1} main.ba0bc9f17d63868a89a3.bundle.js (main) 2.49 MB [initial] [rendered]
chunk {2} styles.cb450a88292b46f1511b.bundle.css (styles) 81 kB [initial] [rendered]
chunk {3} inline.0002f507274cf434cef2.bundle.js (inline) 1.45 kB [entry] [rendered]

Angular CLI: 1.5.2
Node: 8.9.1
OS: win32 x64
Angular: 5.0.2
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

So although the compilation time reduction was very nice, the node version doesn't seem to play a major role in the RAM consumption issue (at least on my machine/project).

EDIT:

Running ng build --aot --prod --build-optimizer=false finished 3 times faster than ng build --aot --prod but it did use about 150-200MB more RAM.

Date: 2017-11-17T20:29:38.921Z
Hash: 94cb3178b3be74bd0397
Time: 126625ms
chunk {0} polyfills.e8bddc586f67afdffd0d.bundle.js (polyfills) 65.9 kB [initial] [rendered]
chunk {1} styles.cb450a88292b46f1511b.bundle.css (styles) 81 kB [initial] [rendered]
chunk {2} main.55c058ed7857dda94b2e.bundle.js (main) 1.8 MB [initial] [rendered]
chunk {3} vendor.ba5bb536a884f0ae6767.bundle.js (vendor) 1.33 MB [initial] [rendered]
chunk {4} inline.39aa19fa644263353f85.bundle.js (inline) 1.45 kB [entry] [rendered]

So all in all build optimizer seems to actually help RAM consumption at the expense of time.

[Tolitech]

Hello @filipesilva
I've done some more tests and would like to share it with you.

To be a fair test, I restarted my laptop at all times when I changed a line in the production.js file and after running ng build -prod.

In all tests, the virtual memory added was 32 GB.
The laptop has 8 GB physical RAM.

In the ng.cmd file the configured command was --max_old_space_size = 32768 in all cases.

It is important to remember that in this test, the total memory allocated is not exactly the total memory required by Node.js, since it would be the total used by the computer in all of its processes.

However, there was no program or process running, and in all tests the computer was restarted.

Let's go to the tests:

Test 1
Configuration:

Total memory allocated by the computer: 36.5 GB

Waiting time to complete: 26 min 24 secs

Test 2
Configuration:

Total memory allocated by the computer: 34 GB

Waiting time to complete: 20 min 52 secs

Test 3
Configuration:

Total memory allocated by the computer: 7.9 GB

Waiting time to complete: 10 min 03 secs

Test 4
Configuration:

Total memory allocated by the computer: 8.8 GB

Waiting time to complete: 13 min 59 secs

Node v8.9.1
Angular CLI 1.4.1

By my tests, I have to conclude that in my specific case, it is the new webpack.optimize.ModuleConcatenationPlugin() command line that is dramatically increasing my memory need.

With this line enabled, my consumption goes from 8.8 GB to 36.5 GB as indicated by the windows task manager.

If you need more tests, just give me instructions.
I work more with .NET, but with instructions I believe I can test.

Thank you.

[filipesilva]

@Tolitech thanks lot for trying that! I think you're on to something.

The commit that introduced ModuleConcatenationPlugin was released in 1.3.0-rc.0 (https://github.com/angular/angular-cli/commit/fe85750cb7db699505faf1cc63e3d35018d47ed2).

This matches up with what @amikitevich @randyaa and @radoslavpetranov said: their memory problems started with 1.3.0.

Using ModuleConcatenationPlugin is important for two reasons:

• it makes javascript loading in the browser faster (https://medium.com/webpack/webpack-3-official-release-15fd2dd8f07b)
• it enables smaller bundles when used with Uglify and Build Optimizer

But it also seems to be causing excessive memory usage in some cases.

I'm a bit at a loss at what I can do about this now. ModuleConcatenationPlugin might use a lot of memory by design or it might just be a bug, but it's hard to tell without being able to test it myself.

To users that started having memory problems after the 1.3x update: can you try doing a build disabling ModuleConcatenationPlugin manually (same instructions as I gave @Tolitech in https://github.com/angular/angular-cli/issues/5618#issuecomment-345268174) and tell me if it helps? If it does help and your project is public, can you tell me where I can see it?

[filipesilva]

@Tolitech can you tell me which libraries you use in your app? Maybe I can try including them in a project and can reproduce it like that.

[radoslavpetranov]

running ng build --aot --prod with new webpack.optimize.ModuleConcatenationPlugin() commented out

Date: 2017-11-19T08:34:58.624Z
Hash: 9c0b60b77822f45ea9fd
Time: 158811ms
chunk {0} main.dc03843e6c0ae1671bc2.bundle.js (main) 2.61 MB [initial] [rendered]
chunk {1} polyfills.a0160642e7aef2ebb253.bundle.js (polyfills) 65.6 kB [initial] [rendered]
chunk {2} styles.cb450a88292b46f1511b.bundle.css (styles) 81 kB [initial] [rendered]
chunk {3} inline.4c5cd4d92e0d15ed3e92.bundle.js (inline) 1.45 kB [entry] [rendered]

running ng build --aot --prod with new webpack.optimize.ModuleConcatenationPlugin() activated

Date: 2017-11-19T08:42:05.090Z
Hash: 8e9b1a1739224a7ca0ad
Time: 336440ms
chunk {0} polyfills.e8bddc586f67afdffd0d.bundle.js (polyfills) 65.6 kB [initial] [rendered]
chunk {1} main.4f0ad6b15ea65c6ef0b0.bundle.js (main) 2.49 MB [initial] [rendered]
chunk {2} styles.cb450a88292b46f1511b.bundle.css (styles) 81 kB [initial] [rendered]
chunk {3} inline.9ebe9dea2365b402bb45.bundle.js (inline) 1.45 kB [entry] [rendered]

No difference in RAM consumption on my project.

[alvachien]

@filipesilva My project is public, and I am facing exactly the same issue after I upgrade Angular-CLI a few days ago. You can have a try on 'ng build -prod' via https://github.com/alvachien/achihui

[filipesilva]

@alvachien I tried your project with 1.5.2 and it ng build --prod built correctly with a peak of 1.2GB memory usage. Did you try 1.5.2? There's a fix there that isn't in 1.5.0.

@markmaynard what you're looking at is the the package.json for the angular/angular repo: https://github.com/angular/angular/blob/master/package.json#L10-L13. That repro is what we call a monorepo, where multiple packages are under the same repository. The engine requirements you see there are for the monorepro itself: the requirements to build the Angular packages. But not the requirements for using the Angular packages. If you check out package.json for @angular/core (in your node_modules for instance), there won't be any engine requirements.

@mattem @WandererInVoids I tried running a few experiments in a project with a lot of libs, to compare memory usage with and without a separate Uglify process:

• ng build --prod: peak 1.1GB memory, 4.1MB main bundle
• ng build --prod with Uglify manually commented off: peak 0.8GB memory, 10.5MB main bundle
• Uglify ran manually on main bundle: peak 0.7GB memory, 4.2MB uglified main bundle

CLI used was 1.5.2. It's important to note that I used the same Uglify we use in the CLI ([email protected], the one included by [email protected]), and that I also used the same flags we use in the CLI: --compress pure_getters,passes=3 --mangle.

Flags here are really important because these affect the memory usage and end result. See https://github.com/mishoo/UglifyJS2/issues/2113 for some conversation about memory usage in Uglify.

From the numbers I got I wouldn't say there is a problem with how we use Uglify. The difference (1.1GB vs 0.8+0.7) is larger than each process individually but is smaller than both together. I expect this to be because of all the files/sourcemaps loaded into memory.

But it's worth mentioning that by not running --prod you are also not running ModuleConcatenationPlugin. Maybe in your projects that's the actual problem and not Uglify. Can you try disabling as well? (see https://github.com/angular/angular-cli/issues/5618#issuecomment-345465395 on how to disable it).

[Tolitech]

Hello @filipesilva
I have tried to create a very similar model of what I use so that the tests can be performed with greater precision.

In this application there are basically 5 main pages (category, status, severity, project and issue) that are replicated 10 times within the same module. We have 50 pages per module. 10 modules totaling 500 pages were created.

For me, a page is composed of 3 components, the entry point, the grid and the form.
So we have 1,500 components created.

There are several other components created and used by the application, base components that are inherited via typescript, pagination, menu, security, shared module, directives, guards, models, resolvers, among other elements.

Not all npm referenced libraries are being used in this example, but I believe the model is quite useful for testing.

In this example, my maximum memory consumption hit 23 GB.
Somewhat below my actual case, because although this example has many more components, the components created in my real case are more complex.

I do not know if I exaggerated the number of elements created for the test.
Although hundreds of services have been created (one for each page), all modules and page replications call the same five Api urls (category, status, severity, project and issue).

Both the API and the angular project are published and working in:
Api: http://clientes.tolitech.com.br/ngTestApi
Api Documentation: http://clientes.tolitech.com.br/ngTestApi/api-docs
Angular: http://clientes.tolitech.com.br/ngtest/

To download the source code:
http://www.codegenerator.com.br/downloads/ng-test.zip

[filipesilva]

@Tolitech whoa this is perfect, thank you so much! I'll use it to run some benchmarks and see what I can find. Will also try and trim it down to do a webpack issue for ModuleConcatenationPlugin so we can get the ball rolling there. This is great!

[WandererInVoids]

@filipesilva due your comment i commented out that lines memory usage decreased from 5.5 gb to 2.5 gb

[filipesilva]

@WandererInVoids ok, that's a good sign. I'll keep pressing on this line of investigation.

@Tolitech using your repo (CLI 1.4.1/ Angular 4.4.6 / TS 2.3.3) :

• ng build peaks at 2.2GB ram
• ng build --prod peaks at 18.5GB ram

The memory usage per progress % looks like this:

• 0-11% - 3gb peak (ngtools/webpack)
• 11%-89% - 5.2gb peak (loading and parsing ~4.3k modules into webpack)
• 90%-94% - 8.0gb peak (module concatenation, uglify)
• 95-100% - 18.5gb peak (emitting)

I also tried to upgrade the repro to use CLI 1.5.2/ Angular 5.0.2 / TS 2.4.2.

• ng build peaks at 2.3GB ram
• ng build --prod peaks at 22.0GB ram

The memory usage per progress % looks like this:

• 0-11% - 3.3gb peak (ngtools/webpack, build-optimizer)
• 11%-89% - 4.0gb peak (loading and parsing ~4.3k modules into webpack)
• 90%-94% - 8.6gb peak (purify, module concatenation, uglify)
• 95-100% - 22.0gb peak (emitting)

Note: using CLI 1.5 + Angular 5 defaults to using Build Optimizer on prod builds. I also noticed that the 92% phase took a lot longer than before like @changLiuUNSW reported, while memory usage kinda plateaued. It makes me think that PurifyPlugin (part of Build Optimizer) is what takes so long here.

For comparison, I also tried compiling the project using ngc and it peaked at 3.3gb used memory. Comparing that to the 0-11% phase it looks like our compiler plugin doesn't add a significant overhead. tsc itself peaks 830MB used memory.

The project using Angular 5 can be found at https://github.com/filipesilva/angular-cli-test-repo.

Here's a breakdown of the project files by extension:

1551 html
   1 ico
   8 jpg
   5 json
   5 png
  46 scss
2637 ts

Looking at the peak memory usage numbers I can say a couple of things:

• Memory usage from compilation (0-11% phase) seems reasonable for project size.
• The 11%-89% phase takes a while loading everything but it's also not very surprising.
• I expected the 90%-94% phase to take the lion's share of memory usage but that wasn't the case at all.
• The 95-100% phase is where memory is being massively used up.

I'm going to follow up with the Webpack folks to see what's actually happening in that last phase.

@Tolitech you've been a massive help getting to the bottom of this, I can't thank you enough :100:

[Tragetaschen]

I don't get how 3.3 Gb memory for 1500 HTML files is reasonable. That's 2 Mb per file. Do these numbers contain collectable garbage or is this what's actually claimed until the end of the build?

[kdubious]

@filipesilva My setup is like this:
CLI 1.5.2/ Angular 5.0.2 / TS 2.4.2
I use a few 3rd party packages.

ng build --prod : fails with the JavaScript heap out of memory error
ng --env=build --aot : works

[emilio-martinez]

I ran into this issue. I was able to get a successful build with
node --max_old_space_size=8192 node_modules/.bin/ng build --prod

[AndreaBarbasso]

To add on @emilio-martinez's answer, on Windows use:
node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build --prod

[finalxcode]

```
ng build --aot --prod
95% emittingFATAL ERROR: MarkCompactCollector: semi-space copy, fallback in old gen Allocation failed - JavaScript heap out of memory

Angular CLI: 1.5.2
Node: 8.9.1
OS: win32 x64
Angular: 5.0.2
... animations, common, compiler, compiler-cli, core, forms
... http, platform-browser, platform-browser-dynamic
... platform-server, router

@angular/cdk: 5.0.0-rc0
@angular/cli: 1.5.2
@angular/material: 5.0.0-rc0
@angular-devkit/build-optimizer: 0.0.33
@angular-devkit/core: 0.0.20
@angular-devkit/schematics: 0.0.36
@ngtools/json-schema: 1.1.0
@schematics/angular: 0.1.5
typescript: 2.4.2
webpack: 3.8.1

[filipesilva]

@tolitech FYI I opened a webpack issue for the ModuleConcatenationPlugin memory usage: https://github.com/webpack/webpack/issues/5992.

@Tragetaschen it's not just the HTML files, it's all the TS and code transformations too. The amount of memory used by the plugin (which is developed in this repo) is reasonable insofar as it is not a big overhead, 3 vs 3.3gb, over the ngc compiler itself (which is developed in angular/angular).

[Tolitech]

Thanks, @filipesilva

Taking advantage of the moment, I do not know if this would be the best time, but is there any technique for development to be improved?

Example: In a large project like this, a simple change in HTML or TS ends up taking a long time to reflect the onscreen settings. (ng serve -o running).

[filipesilva]

@tolitech I'd like to talk about the different factors influencing dev rebuilds in big projects but would much prefer to do it in a separate issue. It's something that gets asked about frequently and it would be good to have discussion on it.

Can you open an issue called "Total rebuild time in medium and large projects", share your experience (rebuild time in the console but also time until app is ready in the browser), and ping me there please?

[mattem]

@filipesilva I have tried commenting out the ModuleConcaternationPlugin and rerun our builds. In short our project still runs into memory issues.

I don't know if this makes a difference, but the way our projects are currently setup we have a number of internal libraries that while in development, use npm link to link.

Memory peaks at 2.51gb real / 7.26 virtual when running with the ModuleConcaternationPlugin commented out.
Full output:

Matts-MacBook-Pro:mediator-ui matt$ node --max_old_space_size=8192 ./node_modules/.bin/ng build --prod --preserve-symlinks
 14% building modules 37/38 modules 1 active ...pace/html/mediator-ui/src/styles.scssTemplate parse warnings:
The <template> element is deprecated. Use <ng-template> instead ("      <span *ngIf="!itemTemplate">{{field ? option[field] : option}}</span>
                        [WARNING ->]<template *ngIf="itemTemplate" [pTemplateWrapper]="itemTemplate" [item]="option"></template>
        "): ng:///Users/matt/Documents/workspace/html/mediator-ui/node_modules/primeng/components/autocomplete/autocomplete.d.ts.AutoComplete.html@22:24                           Date: 2017-11-21T13:58:28.746Z                                                       Hash: 683f2d7486502f8e507a
Time: 252811ms
chunk {0} 0.3a309735936ea414db80.chunk.js (common) 581 kB {20}  [rendered]
chunk {1} 1.8caff8c57661c1307d98.chunk.js () 2.55 kB {20}  [rendered]
chunk {2} 2.b3d1517bf29cec331f56.chunk.js () 179 kB {20}  [rendered]
chunk {3} 3.dd257d4e2f9e4640b2d4.chunk.js () 164 kB {20}  [rendered]
chunk {4} 4.e2edee33bd5ed8a53124.chunk.js () 116 kB {20}  [rendered]
chunk {5} 5.13f271efca121303c5fc.chunk.js () 83.2 kB {20}  [rendered]
chunk {6} 6.08af5ef8c2fe3e09267a.chunk.js () 36.8 kB {20}  [rendered]
chunk {7} 7.8ec810fd30855fef71f7.chunk.js () 30 kB {20}  [rendered]
chunk {8} 8.15f033cf28671ef4988a.chunk.js () 29.5 kB {20}  [rendered]
chunk {9} 9.151ee32b9cc676f2034e.chunk.js () 31.1 kB {20}  [rendered]
chunk {10} 10.cb4d037fcc697b055929.chunk.js () 42.7 kB {20}  [rendered]
chunk {11} 11.f2584b57685d1109a976.chunk.js () 37.5 kB {20}  [rendered]
chunk {12} 12.fe05dccec88da4ae948c.chunk.js () 29.4 kB {20}  [rendered]
chunk {13} 13.2028975a01820ba8496f.chunk.js () 6.1 kB {20}  [rendered]
chunk {14} 14.3be6220b9707e6312847.chunk.js () 3.12 kB {20}  [rendered]
chunk {15} 15.5113d2a9539e99c7ad7f.chunk.js () 6.15 kB {20}  [rendered]
chunk {16} 16.915b0b2f0ed403ce914b.chunk.js () 5.66 kB {20}  [rendered]
chunk {17} 17.485ba9c96f0e3aa081f0.chunk.js () 3.06 kB {20}  [rendered]
chunk {18} 18.db6e52da7740aeca6bb0.chunk.js () 13 kB {20}  [rendered]
chunk {19} polyfills.efb98b65fb45848a1cc3.bundle.js (polyfills) 170 kB {23} [initial] [rendered]
chunk {20} main.4a056bb640e0da824df3.bundle.js (main) 49 kB {22} [initial] [rendered]
chunk {21} styles.e50be95f68f4bf889ab4.bundle.css (styles) 263 kB {23} [initial] [rendered]
chunk {22} vendor.f23a5bbcd6f969d5bec4.bundle.js (vendor) 5.1 MB [initial] [rendered]
chunk {23} inline.35b8b1727b921c4ee6ae.bundle.js (inline) 1.94 kB [entry] [rendered]

I then tried with the UglifyJsPlugin commented out:
Memory peaks at 1.54gb real / 6.35 virtual.

Matts-MacBook-Pro:mediator-ui matt$ ng build --prod --preserve-symlinks
 14% building modules 37/38 modules 1 active ...pace/html/mediator-ui/src/styles.scssTemplate parse warnings:
The <template> element is deprecated. Use <ng-template> instead ("      <span *ngIf="!itemTemplate">{{field ? option[field] : option}}</span>
                        [WARNING ->]<template *ngIf="itemTemplate" [pTemplateWrapper]="itemTemplate" [item]="option"></template>
        "): ng:///Users/matt/Documents/workspace/html/mediator-ui/node_modules/primeng/components/autocomplete/Date: 2017-11-21T12:31:03.567Z                                                       Hash: a93f716c1a9cd5e34227
Time: 205392ms
chunk {0} 0.7f726b90dbfda77c6fd2.chunk.js (common) 1.78 MB {20}  [rendered]
chunk {1} 1.b2415c8c032817feee41.chunk.js () 9.49 kB {20}  [rendered]
chunk {2} 2.5dbd68c68fe419faaac6.chunk.js () 20.2 kB {20}  [rendered]
chunk {3} 3.f65ad52f00741668ecea.chunk.js () 325 kB {20}  [rendered]
chunk {4} 4.c60ce468892788b134f0.chunk.js () 11.2 kB {20}  [rendered]
chunk {5} 5.0e510c127917b57b977e.chunk.js () 112 kB {20}  [rendered]
chunk {6} 6.17a1081f0b32fa32114a.chunk.js () 116 kB {20}  [rendered]
chunk {7} 7.0db6a1bd5ef8cd7389e2.chunk.js () 145 kB {20}  [rendered]
chunk {8} 8.08dea29d9d56c08ac135.chunk.js () 133 kB {20}  [rendered]
chunk {9} 9.6c20abd2e257ccb42f3a.chunk.js () 112 kB {20}  [rendered]
chunk {10} 10.245dd4aebc6e15998e11.chunk.js () 455 kB {20}  [rendered]
chunk {11} 11.3a63d64df6659b591bc7.chunk.js () 91.8 kB {20}  [rendered]
chunk {12} 12.4bdb534a025025ab67c5.chunk.js () 28.8 kB {20}  [rendered]
chunk {13} 13.58f953974b1a1cab76cd.chunk.js () 27 kB {20}  [rendered]
chunk {14} 14.a295fb06cc46ee37d6dd.chunk.js () 18 kB {20}  [rendered]
chunk {15} 15.573a4c4817db899cbaa5.chunk.js () 522 kB {20}  [rendered]
chunk {16} 16.1bef7d4db5d387785c53.chunk.js () 209 kB {20}  [rendered]
chunk {17} 17.2892448d1217c3964316.chunk.js () 10.2 kB {20}  [rendered]
chunk {18} 18.8a52fcf63d5fb567be17.chunk.js () 80.8 kB {20}  [rendered]
chunk {19} polyfills.efb98b65fb45848a1cc3.bundle.js (polyfills) 497 kB {23} [initial] [rendered]
chunk {20} main.1b1138cc3dcdfe7392ca.bundle.js (main) 174 kB {22} [initial] [rendered]
chunk {21} styles.e50be95f68f4bf889ab4.bundle.css (styles) 263 kB {23} [initial] [rendered]
chunk {22} vendor.2bca18ae1189b0ecdba1.bundle.js (vendor) 14.4 MB [initial] [rendered]
chunk {23} inline.8e041fa7d36f79764f2f.bundle.js (inline) 6.41 kB [entry] [rendered]

The build completed without the need to add additional memory to Node.

I also tried running with node --inspect and attaching the Chrome debugger to grab some heap snapshots and memory profiles, but it in my tests that caused the CLI to hang during the compilation stage with 1 module remaining.

The other part that is hammering us is the time taken by the compile for tests, we have had to continually increase timeouts in the Karma conf, and the time taken for a page refresh with tests (during development) is quite high, mainly due to that ~15mb vendor bundle.

[Tragetaschen]

@filipesilva I get that there is "stuff" that's generated, that's why I asked if these are clean numbers or if remaining garbage from the actual processing is still contained in that number.
If that's the actual number of bytes claimed, then I still don't get it: Assuming 2Kb per HTML file on average(!) (which is still much more than I would expect - I have 1 kb on average) then each single byte from those files (spaces, angular brackets, text characters, etc.) will generate 1000 bytes of transformed / generated content. I just cannot believe that's the case.

[filipesilva]

@Tragetaschen the numbers I got were just looking at the task manager and keeping track of what the maximum used memory was. I'm not sure why you are focusing on the HTML templates though. ngc does more than just compile templates.

[filipesilva]

@mattem if you're already reaching 1.54GB without Uglify/ModuleConcaternationPlugin, then it looks like your project as is needs more than the default node max memory. At how much memory does your project peak when doing just ng build?

[filipesilva]

@mattem can you open an issue called "Total rebuild test time in medium and large projects", similar to the one I asked @Tolitech to open in https://github.com/angular/angular-cli/issues/5618#issuecomment-346024634? It's a broader topic as well.

[filipesilva]

@Tragetaschen I measured tsc peak as well and it's 830MB. Bear in mind however that ngc both compiles templates, transforms code, and generate new TS files. So total TS files processed would be around double. I pinged the team about the difference between ngc and tsc.

[mattem]

@filipesilva Running ng build uses 1.31gb real / 5.99 virtual peak.

Here is the full output from the command

Matts-MBP:mediator-ui matt$ ng build
Date: 2017-11-21T18:59:28.538Z                                                            
Hash: 5c68c24623b719d5f1b0
Time: 100214ms
chunk {brand-registration-task.module} brand-registration-task.module.chunk.js, brand-registration-task.module.chunk.js.map () 17.4 kB {main}  [rendered]
chunk {common} common.chunk.js, common.chunk.js.map (common) 562 kB {main}  [rendered]
chunk {custom-report-task-module} custom-report-task-module.chunk.js, custom-report-task-module.chunk.js.map () 7.4 kB {main}  [rendered]
chunk {episode-registration-task.module} episode-registration-task.module.chunk.js, episode-registration-task.module.chunk.js.map () 17.5 kB {main}  [rendered]
chunk {feature-not-available-view.module} feature-not-available-view.module.chunk.js, feature-not-available-view.module.chunk.js.map () 4.32 kB {main}  [rendered]
chunk {home-view.module} home-view.module.chunk.js, home-view.module.chunk.js.map () 5.46 kB {main}  [rendered]
chunk {inline} inline.bundle.js, inline.bundle.js.map (inline) 5.83 kB [entry] [rendered]
chunk {job-management-dashboard-task-module} job-management-dashboard-task-module.chunk.js, job-management-dashboard-task-module.chunk.js.map () 8.61 kB {main}  [rendered]
chunk {main} main.bundle.js, main.bundle.js.map (main) 17 MB {vendor} [initial] [rendered]
chunk {material-registration-task.module} material-registration-task.module.chunk.js, material-registration-task.module.chunk.js.map () 18.4 kB {main}  [rendered]
chunk {package-editor-task-module} package-editor-task-module.chunk.js, package-editor-task-module.chunk.js.map () 18.3 kB {main}  [rendered]
chunk {placing-registration-task.module} placing-registration-task.module.chunk.js, placing-registration-task.module.chunk.js.map () 18.5 kB {main}  [rendered]
chunk {playlist-task.module} playlist-task.module.chunk.js, playlist-task.module.chunk.js.map () 23.4 kB {main}  [rendered]
chunk {polyfills} polyfills.bundle.js, polyfills.bundle.js.map (polyfills) 534 kB {inline} [initial] [rendered]
chunk {series-registration-task.module} series-registration-task.module.chunk.js, series-registration-task.module.chunk.js.map () 17.5 kB {main}  [rendered]
chunk {session.module} session.module.chunk.js, session.module.chunk.js.map () 18.4 kB {main}  [rendered]
chunk {spot-check-task-module} spot-check-task-module.chunk.js, spot-check-task-module.chunk.js.map () 6.3 kB {main}  [rendered]
chunk {styles} styles.bundle.js, styles.bundle.js.map (styles) 318 kB {inline} [initial] [rendered]
chunk {tasks.module} tasks.module.chunk.js, tasks.module.chunk.js.map () 26.2 kB {main}  [rendered]
chunk {timeline-task-module} timeline-task-module.chunk.js, timeline-task-module.chunk.js.map () 52.3 kB {main}  [rendered]
chunk {user-settings-view.module} user-settings-view.module.chunk.js, user-settings-view.module.chunk.js.map () 31.8 kB {main}  [rendered]
chunk {vendor} vendor.bundle.js, vendor.bundle.js.map (vendor) 5.07 MB [initial] [rendered]
chunk {views.module} views.module.chunk.js, views.module.chunk.js.map () 91.1 kB {main}  [rendered]
chunk {workflow-dashboard-task-module} workflow-dashboard-task-module.chunk.js, workflow-dashboard-task-module.chunk.js.map () 1.76 MB {main}  [rendered]

We don't run into memory issues (yet, I guess) when running development builds, we are generally experiencing the same as what @Tolitech has already mentioned. (I'm keeping an keen eye on the progress of the Bazel building and the work being done there, happy to be a guinea pig for any of that)

[Tragetaschen]

@filipesilva Just to be sure: It's not that I care about the HTML compilation step per se, it's that you claimed 3.3 GiB memory consumption just for HTML and NgModule processing "reasonable for project size". Using a thousand times the memory compared to the input data size while the resulting bundle (even without any further optimizations) is over an order of magnitude smaller just isn't reasonable.

Sure, there are bigger problems when it comes to memory consumption right now and I wish I could me more (well, any kind of) constructive, but the entire compilation process currently takes one or two orders of magnitude (!) more memory than I would call "reasonable".

[markmaynard]

@tragetaschen I think Felipe is commenting on your math. That step doesn't just involve the HTML file but includes the typescript and CSS files too. In order to properly uglify your entire project is brought into memory, so you can't just count the HTML. Additionally, some of your logic may cause duplication of subsets of your Dom, exploding the size. This is a complicated task that will take a good amount of RAM. We should use as little as possible, but we can't expect miracles.

[mattem]

@filipesilva Opened issue #8579 for test rebuild times

[dobrinsky]

I am also having the same issue. I can share my code to you @filipesilva

[dereklin]

My --prod build works but slow. When I added --stats-json it ran out of memory. I got it working by doing this:

"build:prod:myapp:stats": "node --max_old_space_size=4096 node_modules/@angular/cli/bin/ng build --prod --app=myapp --stats-json"

[filipesilva]

We're updating the Webpack version used in the CLI in https://github.com/angular/angular-cli/pull/8689 to include the fix for excessive memory usage in ModuleConcatenationPlugin (https://github.com/webpack/webpack/pull/5997).

This will be available in the next release of Angular CLI and should address most of the reports of excessive memory usage in 1.3.x and up.

I'd like to reiterate that it is expected that projects will reach the memory limit after a certain size. The bigger your project is, the more memory it will need to be built especially in --prod.

For those cases the recommendation is that you run the CLI with an increased memory limit via a npm script:

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

Then you can do npm run ng-high-mem -- build --prod to do a production build. Note the double dash (--), it is used in npm scripts to separate args.

In this script the limit is increased to 8gigs. You can use a bigger number if you need.

Meanwhile we will keep on making improvements to reduce the memory footprint of the Angular CLI build system.

@changLiuUNSW I've opened a separate issue to track the excessive build time increase when using --build-optimizer: https://github.com/angular/devkit/issues/305.

[radoslavpetranov]

Thanks for taking the time to look into this in such detail @filipesilva! Much appreciated!

[dobrinsky]

The problem is, this is my webpack.config:

`const path = require('path');
const webpack = require('webpack');
const AngularCompilerPlugin = require('@ngtools/webpack').AngularCompilerPlugin;
const merge = require('webpack-merge');
const CheckerPlugin = require('awesome-typescript-loader').CheckerPlugin;

module.exports = (env) => {
// Configuration in common to both client-side and server-side bundles
//const isDevBuild = !(env && env.prod);
const isDevBuild = true;
const sharedConfig = {
stats: { modules: false },
context: __dirname,
resolve: { extensions: [ '.js', '.ts' ] },
output: {
filename: '[name].js',
publicPath: 'dist/' // Webpack dev middleware, if enabled, handles requests for this URL prefix
},
module: {
rules: [
{ test: /.ts$/, include: /ClientApp/, use: isDevBuild ? ['awesome-typescript-loader?silent=true', 'angular2-template-loader'] : '@ngtools/webpack' },
{ test: /.html$/, use: 'html-loader?minimize=false' },
{ test: /.css$/, use: [ 'to-string-loader', isDevBuild ? 'css-loader' : 'css-loader?minimize' ] },
{ test: /.(png|jpg|jpeg|gif|svg)$/, use: 'url-loader?limit=25000' }
]
},
plugins: [new CheckerPlugin()]
};

// Configuration for client-side bundle suitable for running in browsers
const clientBundleOutputDir = './wwwroot/dist';
const clientBundleConfig = merge(sharedConfig, {
    entry: { 'main-client': './ClientApp/boot.browser.ts' },
    output: { path: path.join(__dirname, clientBundleOutputDir) },
    plugins: [
        new webpack.DllReferencePlugin({
            context: __dirname,
            manifest: require('./wwwroot/dist/vendor-manifest.json')
        })
    ].concat(isDevBuild ? [
        // Plugins that apply in development builds only
        new webpack.SourceMapDevToolPlugin({
            filename: '[file].map', // Remove this line if you prefer inline source maps
            moduleFilenameTemplate: path.relative(clientBundleOutputDir, '[resourcePath]') // Point sourcemap entries to the original file locations on disk
        })
    ] : [
        // Plugins that apply in production builds only
        new webpack.optimize.UglifyJsPlugin(),
        new AngularCompilerPlugin({
            tsConfigPath: './tsconfig.json',
            entryModule: path.join(__dirname, 'ClientApp/app/app.module.browser#AppModule'),
            exclude: ['./**/*.server.ts']
        })
    ])
});

// Configuration for server-side (prerendering) bundle suitable for running in Node
const serverBundleConfig = merge(sharedConfig, {
    resolve: { mainFields: ['main'] },
    entry: { 'main-server': './ClientApp/boot.server.ts' },
    plugins: [
        new webpack.DllReferencePlugin({
            context: __dirname,
            manifest: require('./ClientApp/dist/vendor-manifest.json'),
            sourceType: 'commonjs2',
            name: './vendor'
        })
    ].concat(isDevBuild ? [] : [
        // Plugins that apply in production builds only
        new AngularCompilerPlugin({
            tsConfigPath: './tsconfig.json',
            entryModule: path.join(__dirname, 'ClientApp/app/app.module.server#AppModule'),
            exclude: ['./**/*.browser.ts']
        })
    ]),
    output: {
        libraryTarget: 'commonjs',
        path: path.join(__dirname, './ClientApp/dist')
    },
    target: 'node',
    devtool: 'inline-source-map'
});

return [clientBundleConfig, serverBundleConfig];

};
`

So, I am not using ModuleConcatenationPlugin and I still get the same error. That is why I offered my code

[filipesilva]

@dobrinsky how many TS files do you have in your project? Do you know what is peak memory usage?

[dobrinsky]

I have 240. Will get up to 400 probably until I finish the project.

No, I do not know. I am a beginner...I do not know how to find that out

[filipesilva]

I usually run the build process, and then just look at the task manager to see how much memory the process is using. Peak memory usage is just the biggest number I saw for memory usage while the process was running.

[dobrinsky]

:)))) I didn't knew it was that simple. Thought I need some software or something...

Anyway, the strangest thing happened:

I started with:

Then Visual Studio started using memory in the build process:

Then of course, Node started using too:

But my peak was 68%, with just 1.67 GB of memory usage

So, this is definitely something else

[nadhir-falta]

Upgrading to Angular-CLI 1.5.5, Node to 8.9.1 and Yarn to 1.3.2 Fixed that issue for me.
And running Yarn did the fix better than npm.

[dobrinsky]

I am not using Yarn. I have Node 9.2, but Angular-CLI 1.5.4.

I will try with 1.5.5

[JasonPaape]

Thanks @filipesilva for your post above re: "ng-high-mem". I confirmed with my project that this does work and I no longer run out of memory during prod build with aot and build-optimizer on. Without this I ran out of memory.

package.json scripts:
"ng-high-mem": "node --max_old_space_size=8192 ./node_modules/@angular/cli/bin/ng"
Now this works:
npm run ng-high-mem -- build --prod --aot=true --build-optimizer=true

Note in your msg above you wrote:
"Then you can do npm run ng-high-mem -- --prod to do a production build."
But I think you missed "build" in there:
npm run ng-high-mem -- build --prod

[Jayaraj8905]

Hi @filipesilva,

In our project we are having the out of memory issue with below version
@angular/cli: 1.2.0
@angular: 4.2.5

We are near production and we expect solution for this. Due to some constraints we couldn't able to migrate to angular 5 for now.

Is there any solution will be available for this?

[filipesilva]

@dobrinsky have you tried running your webpack config with node --max_old_space_size=8192 to increase the memory limit? What is the maximum you see then? If it's just above the maximum you saw before it might just be that you need that little extra bit of memory.

@JasonPaape thanks, I added it now!

@Jayaraj8905 at this point your best bet is to either use that script (ng-high-mem) or update. 1.2.0 was a long time ago and we don't publish fixes for it anymore.

[JaapMosselman]

Using ng-high-mem option with @angular/cli 1.5.4 solved it for me.
Using @angular/cli 1.5.5, I saw 30-40% less memory usage, but still memory outage, so still ng-high-mem required for my build.

Now using ng-high-mem (with 8192) it is using a lot more memory. Is it using more when it has more memory available?

[filipesilva]

Please bear in mind that the webpack update is not in yet. It will be in either 1.5.6 or 1.6.0.

[JaapMosselman]

Hopefully that will also speed up the production build a lot. I just migrated from the old Angular 2 way (ngc aot + rollup) to angular/cli and the build time grow from 4m to about 12m. :-(

[HarelM]

I'm seeing this since the migration to angular 5 + angular-cli 1.5.5 on my CI build machine.
Thanks for the help of appveyor team I was able to use the --max_old_space_size on the node cmd file.
Relevant info can be found in the following discussion (which links here):
https://help.appveyor.com/discussions/problems/10192-out-of-memory-when-using-angular-cli-15-angular-5
And in this issue in my repository.
https://github.com/IsraelHikingMap/Site/pull/567

[kisdaniel]

I have a same issue with @angular/[email protected]

ng build -prod
 95% emitting                                                                             
<--- Last few GCs --->

  113209 ms: Mark-sweep 853.8 (1439.3) -> 857.6 (1439.3) MB, 271.2 / 0.0 ms [allocation failure] [scavenge might not succeed].
  113472 ms: Mark-sweep 857.6 (1439.3) -> 861.5 (1439.3) MB, 263.2 / 0.0 ms [allocation failure] [scavenge might not succeed].
  113756 ms: Mark-sweep 861.5 (1439.3) -> 876.5 (1423.3) MB, 284.4 / 0.0 ms [last resort gc].
  114039 ms: Mark-sweep 876.5 (1423.3) -> 891.6 (1423.3) MB, 282.5 / 0.0 ms [last resort gc].


<--- JS stacktrace --->

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

Security context: 0x31d99d6cfb51 <JS Object>
    1: DoJoin(aka DoJoin) [native array.js:~129] [pc=0xc7b98c68639] (this=0x31d99d604381 <undefined>,w=0x23bc0f2ffd31 <JS Array[590]>,x=590,N=0x31d99d6043c1 <true>,J=0x31d99d6ae4d1 <String[1]:  >,I=0x31d99d6b46e1 <JS Function ConvertToString (SharedFunctionInfo 0x31d99d652dc9)>)
    2: Join(aka Join) [native array.js:180] [pc=0xc7b9864f2b2] (this=0x31d99d604381 <undefined>,w=0x23bc0f2ffd31 <JS ...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [ng]
 2: 0x10983ec [ng]
 3: v8::Utils::ReportApiFailure(char const*, char const*) [ng]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [ng]
 5: v8::internal::Factory::NewRawTwoByteString(int, v8::internal::PretenureFlag) [ng]
 6: v8::internal::Runtime_StringBuilderJoin(int, v8::internal::Object**, v8::internal::Isolate*) [ng]
 7: 0xc7b939092a7
Aborted (core dumped)

[kisdaniel]

adding to this line
"build-prod": "node --max_old_space_size=8192 ./node_modules/@angular/cli/bin/ng build --prod",
to package.json helped me.

[alvachien]

@filipesilva I saw a new version of webpack has been release days ago which ships your performance tuning code, when will angular-cli release a new version refer to the latest version of webpack? Thank you.

[Koslun]

@alvachien In next version of Angular CLI, 1.5.6 or 1.6.0, is what he said just a little up in this thread.

Judging by latest releases I would assume that this could happen this week unless there is something in particular blocking it.

[connorsleight]

@kisdaniel 's solution/workaround seems to work fine. its sorted my issues

[wolfhoundjesse]

Increasing --max_old_space_size works for me, but after an hour or so, my RAM (32Gb) usage hits 70% or 80%, incremental builds slow down, and node or ng serve crashes.

[filipesilva]

@wolfhoundjesse are you using AOT on rebuilds?

[krassx]

Is there any ETA on release with aforementioned deps update? Fighting with this issue in our CI which doesn't have much RAM for now, so this fix is urgently required (I know I can hack package.json to point directly at master, but this is a hack I want to avoid).

[filipesilva]

It should be in this weeks release, since we usually release once per week.

[connorsleight]

@krassx for now, try @kisdaniel 's fix, works fine for an 8gb ram machine

[krassx]

@mast3rd3mon, It doesn't help that much as we have 4GB RAM on our build machine. Will try to play with the limit to make it work.

[connorsleight]

@krassx maybe try the same command but for 4gb ram? so 4096 not 8192

[krassx]

Tried that. And got that out of memory error. It does work on my local machine (macOS, 8GM RAM) but fails on build machine (Linux, 4GB).

[WandererInVoids]

@krassx try disable build optimizer and source map, can u share yours build command?

[krassx]

node --max_old_space_size=8192 ./node_modules/@angular/cli/bin/ng build --target=production --aot --output-hashing=bundles --build-optimizer=true

This is what I use locally with no errors. But it fails on CI machine as I noted before.

[WandererInVoids]

@krassx try this for production u can just use prod
node --max_old_space_size=4096 --stack_size=512 ./node_modules/@angular/cli/bin/ng build --prod -vc --build-optimizer=false
refer to this page for more option https://github.com/angular/angular-cli/wiki/build

[krassx]

Ok, will give it a try. Thank you.

[krassx]

@WandererInVoids, disabling build optimizer did the trick. Thank you for the advice.

[WandererInVoids]

@krassx your welcome

[filipesilva]

@angular/[email protected] is now released and includes the memory fix on Webpack's side.

[wolfhoundjesse]

@filipesilva I'm using node --max_old_space_size=16384 node_modules/.bin/ng serve --aot. I'll upgrade to rc.2 now.

[PeS82]

@filipesilva I am sorry , I am traveling and missed your question to me. To reply, yes, my problems started after updating to 1.5.0 and plain ng build --prod failed with any 1.5.x. I had to build, as many others, with raised memory node --max-old-space-size=8192 node_modules\@angular\cli\bin\ng build --prod.

Having said that at the same time as I updated to 1.5 I included 3rd party library that probably sent the build process over the edge.

And now the good news. I have just updated to 1.6 and the build finishes just fine with plain old ng build --prod.

Thanks.

[FrancescoBorzi]

I can confirm this issue, it looks a serious one.

It happens only when AOT is enabled.

So it will work fine if I disable AOT and run: ng build --prod --aot false

Angular CLI: 1.5.5
Node: 8.9.1
OS: linux x64
Angular: 5.0.5
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

@angular/cli: 1.5.5
@angular-devkit/build-optimizer: 0.0.34
@angular-devkit/core: 0.0.22
@angular-devkit/schematics: 0.0.39
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.8.5
@schematics/angular: 0.1.9
typescript: 2.4.2
webpack: 3.8.1

[elclanrs]

1.6.0 seems to have fixed it for us. Our app compiled _without_ extending the memory.

[calebeaires]

@elclanrs not here, (1.6.0)

[FrancescoBorzi]

apparently, upgrading to latest cli(1.6)/angular(5.1)/typescript(2.5) solved the issue

[MrBlaise]

I upgraded to cli 1.6 and angular 5.1 and now our app could build under 1.7 gigs

[seanlandsman]

@filipesilva a bit late, but I finally got around to testing ag-Grid with 1.6.0 and it all builds fine now.

Thanks for your hard work on this

[alvachien]

@filipesilva I tried the 1.6.0, it seems my project work fine, thank you.

[WandererInVoids]

@filipesilva don`t work for me but build time and memory usage decreased

[aminebizid]

Now it’s time to switch to Bazel/Rollup

[JaapMosselman]

I upgraded to cli 1.6 and angular 5.1.
The max memory the production build now using is around 1.3 GB. So no heap errors anymore.

Strange thing is that the process is 'hanging' at '92% chunk asset optimization' for 7 minutes of the total of 9 minutes buildtime.
What is happening there?

[handark]

@Ristaaf thank you very much, your solution works perfect

[pleerock]

We still have this issue. We had this issue since angular@2 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 I always have an error (after few minutes of build):

ng build
 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 [/Users/pleerock/www/yakdu/ng5.yakdu.dev/node_modules/@angular/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
-------------------------------------------------------------------------------

[filipesilva]

@pleerock have you tried using the command to increase max memory, on both prod and dev builds?

If your project is near to the maximum memory it will need a lot of GC and that slows down things. Increasing the max memory even when you're not hitting it (like in dev) should help.

[pleerock]

@filipesilva thanks, it works. Both prod and dev builds. And build time is still 1 hour. Im glad that it works this way, however having to wait 1 hour each time is a problem. Also, its a big problem to run ng serve. When we run it, it takes same 1 hour to start serving which makes development process completely impossible.

[filipesilva]

@pleerock yeah 1h for ng serve is really odd. I have never seen such a large build time in any projects I've handled.

I have reports of slow prod builds of that length (https://github.com/angular/angular-cli/issues/6795) but haven't heard of anything like that just for ng serve... I use https://github.com/filipesilva/angular-cli-test-repo as a benchmark for larger projects and it has around 2400 TS files, but still only takes a few minutes.

Is your repro public or is there a way that I can see it?

[filipesilva]

Another option would be to take a CPU profile (there's some instructions here https://github.com/angular/angular-cli/issues/8259). But I wouldn't be surprised if the devtools crash, they usually do on huge jobs. Maybe a CPU profile of just a few minutes would be feasible?

[pleerock]

Is your repro public or is there a way that I can see it?

no, its not public. If you can we can make a call and I can show you and maybe we can use teamviewer or similar things.

BTW, 76% basic chunk optimization step takes most of time (99%). If I run ng serve and change a file it takes same 1 hour to rebuild everything.

CPU profile of first 10 minutes of 76% basic chunk optimization process (ng serve):

CPU-20180103T195000.cpuprofile.zip

[filipesilva]

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?

[pleerock]

npm ls webpack

└─┬ @angular/[email protected]
  └── [email protected] 

[TheLarkInn]

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.

[pleerock]

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

CPU-20180105T160658.cpuprofile.zip

[filipesilva]

@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 https://github.com/angular/angular-cli/pull/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 [email protected]: https://github.com/webpack/webpack/blob/b545b519b2024e3f8be3041385bd326bf5d24449/lib/optimize/RemoveParentModulesPlugin.js
• in [email protected]: 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 https://github.com/webpack/webpack/issues/6248

[sabeersulaiman]

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 😕

[filipesilva]

@sabeersulaiman have you tried setting a npm script for increasing the memory available? I mentioned it in https://github.com/angular/angular-cli/issues/5618#issuecomment-348225508.

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

[sabeersulaiman]

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

[pleerock]

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.

[pleerock]

@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

[clydin]

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

[dragonflypl]

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?

[sabeersulaiman]

@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

> [email protected] 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! [email protected] start: `node --max-old-space-size=8192 ./node_modules/.bin/ng serve`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] 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 ?

[pleerock]

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

[rainstormza]

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

[Sarfarazsajjad]

updated to @angular/[email protected]
but still the same error 'FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory'

[rafiwardak2003]

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?

[Satyadatla]

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

[nadhir-falta]

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.

[JaapMosselman]

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.

[ghost]

Tested following wit cli 1.6.5

$ node --max_old_space_size=8192 node_modules/.bin/ng build --prod
Date: 2018-01-26T07:31:27.619Z
Hash: 50238294b6564c10ffb7
Time: 130002ms
chunk {0} polyfills.63eb1df6d53730045032.bundle.js (polyfills) 97.8 kB [initial] [rendered]
chunk {1} main.401dee7547b2af51d287.bundle.js (main) 1.57 MB [initial] [rendered]
chunk {2} styles.3f5700be7447a96e8808.bundle.css (styles) 50.2 kB [initial] [rendered]
chunk {3} inline.82501ecadee5847574b3.bundle.js (inline) 1.45 kB [entry] [rendered]

$ ng build --prod
Date: 2018-01-26T07:35:55.320Z
Hash: 50238294b6564c10ffb7
Time: 136006ms
chunk {0} polyfills.63eb1df6d53730045032.bundle.js (polyfills) 97.8 kB [initial] [rendered]
chunk {1} main.401dee7547b2af51d287.bundle.js (main) 1.57 MB [initial] [rendered]
chunk {2} styles.3f5700be7447a96e8808.bundle.css (styles) 50.2 kB [initial] [rendered]
chunk {3} inline.82501ecadee5847574b3.bundle.js (inline) 1.45 kB [entry] [rendered]

So 6 seconds ... not worth it ...

[mcherb]

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)

[smiera]

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

[kanji-keraliya]

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/[email protected]

update local Angular Cli
npm install @angular/[email protected]

[warmans]

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.

[PsyGik]

Using @angular/[email protected] 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.

[swftvsn]

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.

[kdubious]

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?

[swftvsn]

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 ;)

[warmans]

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:

[ZgjimDida]

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\Roamingnpm

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.

[kanji-keraliya]

@ZgjimDida its working for me for @angular/[email protected] after added --max-old-space-size=10240 in both places

[FOSSKolkata]

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

[vasanthm-bx]

Adding SWAP will help in solving this error?

[ZgjimDida]

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

[jobnte]

@FOSSKolkata
But I'm getting the warning of > @angular/[email protected] requires a peer of typescript@>=2.4.2 <2.7 but none is installed. You must install peer dependencies yourself.

[aindigo]

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.

[joshvito]

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

[roymj88]

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?

[aindigo]

it seems that they dont care about this.

[Koslun]

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

1. 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.
2. 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.
3. 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.

[roymj88]

@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

[DenysVuika]

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

[roymj88]

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

[Koslun]

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

[Flexicon]

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.

[joshvito]

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

[aindigo]

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

[makdeniss]

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

[awerlang]

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

[jarodsmk]

bump.

[ar53n]

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

[jarodsmk]

@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

[mast3rd3mon]

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.

[jarodsmk]

@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

[mast3rd3mon]

@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

[Flood]

@mast3rd3mon It depends on how big your project is.

[swftvsn]

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.

[jarodsmk]

@mast3rd3mon , regarding what @swftvsn mentioned:

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

[makdeniss]

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

[mast3rd3mon]

@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

>

[jarodsmk]

@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

[jarodsmk]

@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

[makdeniss]

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

[swftvsn]

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 ?

[makdeniss]

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

[jarodsmk]

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

[makdeniss]

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

[jarodsmk]

@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

[makdeniss]

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

[Ericdowney]

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 (_https://github.com/Microsoft/TypeScript/issues/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

[chris13524]

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.

[vandensd]

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.

[Koslun]

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

[Enngage]

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.

[Koslun]

@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

[Enngage]

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.

[Koslun]

@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: https://github.com/nodejs/node/issues/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.

[Arti3DPlayer]

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 ?

[lippomano]

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 >,000003A248D4D541 3: getMatches(aka getMatches) [C:\Users\Utente\Desktop\Workspace\rebus5node_modules@angular-devkitbuild-optimizer\src\purify\purify.js:48] [bytecode=000003F790876209 offset=16](this=000000FCE1C02311 ined>,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::ParserBase::MarkLoopVariableAsAssigned
10: 00000231754047A1

[ZgjimDida]

@lippomano Try this. It solved the issue.

[Marudhuraj]

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

1. ng build --prod
2. ng build --aot
3. "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.

[joshuwhi]

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

[Koslun]

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

[vandensd]

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

[aryavijay]

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

1. I used the command "npm run build" which internally uses "ng build"

2. I update my "ng.cmd" file at following location "\UInode_modules.bin" (UI being the project folder) by this code

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

)

this is basically adding more memory for node to execute

1. Update the package.json file, by doing following steps:
   replace
   "build": "ng build",
   by this:
   "build": "ng build --prod --build-optimizer",

Thanks
Vijay

[Marudhuraj]

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\taskmanagementv2uipackage.json (relative path: ./src/app) Field 'browser' doesn't contain a valid alias configuration after using description file: C:\Users\a811891\taskmanagementv2uipackage.json (relative path: ./src/app) resolve as module C:\Users\a811891\taskmanagementv2ui\src\appnode_modules doesn't exist or is not a directory C:\Users\a811891\taskmanagementv2ui\srcnode_modules doesn't exist or is not a directory C:\Users\a811891node_modules doesn't exist or is not a directory C:\Usersnode_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\taskmanagementv2uinode_modules using description file: C:\Users\a811891\taskmanagementv2uipackage.json (relative path: ./node_modules) Field 'browser' doesn't contain a valid alias configuration after using description file: C:\Users\a811891\taskmanagementv2uipackage.json (relative path: ./node_modules) using description file: C:\Users\a811891\taskmanagementv2uinode_modulesngx-storepackage.json (relative path: ./dist/src/service/local-storage.service) no extension Field 'browser' doesn't contain a valid alias configuration C:\Users\a811891\taskmanagementv2uinode_modulesngx-store\dist\src\service\local-storage.service doesn't exist .ts

[yaadm]

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.

[kdubious]

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

[williangd]

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

[Moulde]

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

[liangwenzhong]

any solution to this ? ....

[aryavijay]

read my comment or screenshare.....

[Moulde]

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

[paustint]

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

[alfaproject]

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

[williangd]

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

[dirkluijk]

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.

[iyashiyas]

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.

[dirkluijk]

@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

[dirkluijk]

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

[lawrencegrey]

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

[yharaskrik]

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: https://github.com/angular/angular-cli/issues/5618#issuecomment-419736226

[wilsoncook]

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

[dirkluijk]

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

[jiminikiz]

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.

[ndraiman]

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

[dobrinsky]

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.

[iyashiyas]

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.

[radjivF]

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

[Moulde]

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

[filipesilva]

Just want to highlight something I said in https://github.com/angular/angular-cli/issues/6795#issuecomment-416623841 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.

[dobrinsky]

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

[filipesilva]

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

[dobrinsky]

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 [email protected]
3 info using [email protected]
4 verbose run-script [ 'prebuild', 'build', 'postbuild' ]
5 info lifecycle [email protected]~prebuild: [email protected]
6 info lifecycle [email protected]~build: [email protected]
7 verbose lifecycle [email protected]~build: unsafe-perm in lifecycle true
8 verbose lifecycle [email protected]~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 [email protected]~build: CWD: C:\Users\Andrei\PROJECTS\Angular 6\SIGAD\SIGAD\ClientApp
10 silly lifecycle [email protected]~build: Args: [ '/d /s /c', 'ng build "--prod"' ]
11 silly lifecycle [email protected]~build: Returned: code: 134  signal: null
12 info lifecycle [email protected]~build: Failed to exec build script
13 verbose stack Error: [email protected] 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 [email protected]
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 [email protected] build: `ng build "--prod"`
22 error Exit status 134
23 error Failed at the [email protected] build script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 134, true ]

[ImranAhmed]

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

[sanidz]

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

[mariohmol]

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

[HarelM]

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

[marcj]

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

[jatinderkumargupta]

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

[HarelM]

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

[jatinderkumargupta]

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

[pdemro]

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

[bkarv]

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

[ImranAhmed]

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

[bkarv]

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

[filipesilva]

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 https://github.com/angular/angular-cli/issues/5618#issuecomment-431310735, 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.