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

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.

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

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.

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?

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

@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"
}

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.

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

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?

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?

@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

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

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

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

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

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

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

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

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

I hope it will help you.

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

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

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

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

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

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.

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

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

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

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

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

• @angular/cli@1.0.1
• @angular/*@4.1.0
• node@6.10.2

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

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.

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

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.

@angular/cli@1.6.0-rc.2 is now released and includes the memory fix on Webpack’s side.

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

after update to angular/cli@1.3.0 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

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

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.

@mast3rd3mon It depends on how big your project is.

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

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

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.

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.

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.

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

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

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.

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

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.

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.

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

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.

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

@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

bump.

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

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

Now it’s time to switch to Bazel/Rollup

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

this is so java 😃)

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

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

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.

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

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.

@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

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 😉

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

 $ npm run start

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

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

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

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

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

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

@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

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

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

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

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

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.

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

@hugodes

Why isn’t this considered a severe bug ?

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

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

This worked for me

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.

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

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.

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

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.

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" %* )

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.

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

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

@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

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

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

I am also having the same issue. I can share my code to you @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).

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

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 <JS Object> 1: SparseJoinWithSeparatorJS(aka SparseJoinWithSeparatorJS) [native array.js:~75] [pc=0x1e05abc97c4a] (this=0x4353ac04241 <undefined>,w=0x1a58c504381 <JS Array[1078]>,F=0x1a58c5043a1 <JS Array[1078]>,x=1078,I=0x37d7075bc209 <JS Function ConvertToString (SharedFunctionInfo 0x4353ac5dbc9)>,J=0x4353ac4a369 <String[1]: >) 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::Localv8::Value, v8::Localv8::Message) [/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 `

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 <JSObject> 1: DoJoin(aka DoJoin) [native array.js:~95] [pc=0000002F55357679](this=00000075A3182311 <undefined>,p=0000001FB1A5B831 <JSArray[937]>,q=937,E=00000075A31823B1 <true>,A=00000185B7C6EC69 <String[1]: >,z=00000075A3182421 <false>) 2: Join(aka Join) [native array.js:~120] [pc=0000002F550C6489](this=00000075A3182311 <undefined>,p=0000001FB1A5B831 <JSArray[937]>,q=937,A=00000185B7C6EC69 <Str…

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

@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

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

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

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

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

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?

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

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” }

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

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

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.

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

I’m so afraid there will be no solution for this issue. I reverted to rc.2 because of this 😦

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

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

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

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

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

and call build-prod in u r command

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

Hi guys,

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

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

Please any help?

p.s. If I comment

"aot": true

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

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

any solution to this ? …

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 ?

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

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

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:

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

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

This is something which needs to be fixed guys.

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

update global Angular Cli

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

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

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

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

@elclanrs not here, (1.6.0)

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

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

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?

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 @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 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/cli@1.4.7 and @angular/*@4.4.5

We use gulp-uglify@3.0.0, giving us uglify-js@3.0.28, 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.

@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

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

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

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

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

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)

@zackschuster its mere existence

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

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

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"
  },

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.

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.

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.

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 2. 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 <JS Object> [INFO] 1: DoJoin(aka DoJoin) [native array.js:~97] [pc=0x168f8ea1398a](this=0x38d692102311 <undefined>,q=0x39d30737fbe1 <JS Array[2905]>,r=2905,F=0x38d6921023b1 <true>,B=0x38d692157ff9 <String[1]: >,A=0x38d692102421 <false>) [INFO] 2: Join(aka Join) [native array.js:~122] [pc=0x168f8e9b25e2](this=0x38d692102311 <undefined>,q=0x39d30737fbe1 <JS Array[2905]>,r=2905,B=0x38d692157ff9 <String[1]: >,A=0x… [INFO]

@sbabeal just go to RxJS 5.4.2

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"]
}

In my case, I installed typescript@2.1.6 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)