Angular CLI: 6.0.3
Node: 8.11.1
OS: darwin x64 (MacBook Pro 8Go RAM)
Angular: 6.0.2
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router, upgrade
聽
Package 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 Version
-----------------------------------------------------------
@angular-devkit/architect 聽 聽 聽 聽 0.6.3
@angular-devkit/build-angular 聽 聽 0.6.3
@angular-devkit/build-optimizer 聽 0.6.3
@angular-devkit/core 聽 聽 聽 聽 聽 聽 聽0.6.3
@angular-devkit/schematics 聽 聽 聽 聽0.6.3
@angular/cli 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽6.0.3
@ngtools/webpack 聽 聽 聽 聽 聽 聽 聽 聽 聽6.0.3
@schematics/angular 聽 聽 聽 聽 聽 聽 聽 0.6.3
@schematics/update 聽 聽 聽 聽 聽 聽 聽 聽0.6.3
rxjs 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽6.1.0
typescript 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽2.7.2
webpack 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 聽 4.8.3
ng build --prod
92% chunk asset optimization UglifyJSPlugin
[.. waiting for long time]
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
Build works
Back to 6.0.1 and 0.6.1 like few days ago works. For the moment I didn't change the default memory allocate to node.
I experience the same issue in some kind:
Angular CLI: 6.0.3
Node: 9.2.0
OS: linux x64
Angular: 6.0.1
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, platform-server, router
Package Version
------------------------------------------------------------
@angular-devkit/architect 0.6.1
@angular-devkit/build-angular 0.6.1
@angular-devkit/build-optimizer 0.6.1
@angular-devkit/core 0.6.3
@angular-devkit/schematics 0.6.3
@angular/cdk 6.0.2
@angular/cli 6.0.3
@angular/flex-layout 6.0.0-beta.15
@angular/material 6.0.2
@angular/material-moment-adapter 6.0.2
@ngtools/webpack 6.0.1
@schematics/angular 0.6.3
@schematics/update 0.6.3
rxjs 6.1.0
typescript 2.7.2
webpack 4.8.3
The command to build:
node --max_old_space_size=12000 ./node_modules/.bin/ng build --configuration=$ENV \
--prod --source-map=$useSourceMaps \
--i18nFile=src/locale/messages.$lang.xtb \
--i18nFormat=xtb \
--i18n-locale=$locale \
--baseHref=/$lang/ \
--outputPath=dist/$ENV/$lang \
--deployUrl=$deployUrl/$lang
I assigned a lot of memory but it hangs at building 67%.. Also I saw using it up to 10GB of RAM when manually monitoring with htop.. This is not very accurate ofcourse but indicates a problem if you ask me.
This issue makes it impossible to deploy... Is there a downgrade guide back to angular 5 or did I end up in a new angular "adventure"?
Can you try with node v10? There are known nodeJS performance issues with Map/Set (used heavily within webpack internally) in versions higher than v8.9.4 and less then v10.
A part of my issue seems related to https://github.com/angular/angular-cli/issues/9779
When I set extractCss to false within angular.json it continues but then gets stuck at UglifyJSPlugin...
Also installing v10 doesnt make a difference. Downgrading to angular 5 again.
~It never ceases to amaze me that this javascript community produces a package that upgrades a dependency with a major version without bumping their own major version. Angular may be a nice project and well maintained and follow best practices like semversioning AND stick by the rules that come with the convention but depending on packages that dont follow these practices makes it just as unstable as any other average javascript package..~
After few tests I downgrade to 6.0.0 and set sourceMap to false. And in fact upgrading to node 10 helped, but I still see a 2x to 3x times increase in build time between 6.0.0 and 6.0.1.
Same issue here: after upgrading Angular from v5.2.8 to v6.0.3 production bundle (aot, unminified) build time/peak memory usage changed from 1.22gb / 54 seconds to 2.91gb / 114 seconds (+138% in memory usage and +111% of build time). I even had to add --max_old_space_size=8192 node flag because compilation process started failing with out of memory error.
Here is the package.json diff:
- "@angular/animations": "5.2.8",
+ "@angular/animations": "6.0.3",
- "@angular/common": "5.2.8",
+ "@angular/common": "6.0.3",
- "@angular/compiler": "5.2.8",
+ "@angular/compiler": "6.0.3",
- "@angular/compiler-cli": "5.2.8",
+ "@angular/compiler-cli": "6.0.3",
- "@angular/core": "5.2.8",
+ "@angular/core": "6.0.3",
- "@angular/forms": "5.2.8",
+ "@angular/forms": "6.0.3",
- "@angular/http": "5.2.8",
+ "@angular/http": "6.0.3",
- "@angular/platform-browser": "5.2.8",
+ "@angular/platform-browser": "6.0.3",
- "@angular/platform-browser-dynamic": "5.2.8",
+ "@angular/platform-browser-dynamic": "6.0.3",
- "@angular/router": "5.2.8",
+ "@angular/router": "6.0.3",
- "@angular/upgrade": "5.2.8",
+ "@angular/upgrade": "6.0.3",
- "@ngtools/webpack": "1.10.2",
+ "@ngtools/webpack": "6.0.3",
- "ngx-infinite-scroll": "0.8.3",
+ "ngx-infinite-scroll": "6.0.0",
- "rxjs": "5.5.6",
+ "rxjs": "6.2.0",
- "typescript": "2.6.2",
+ "typescript": "2.7.2",
- "@angular/cli": "1.7.4",
+ "@angular/cli": "6.0.3",
+ "@angular-devkit/build-angular": "0.6.3"
We're using custom webpack configuration with AngularCompilerPlugin from @ngtools/webpack.
Node version is 8.11.2.
Webpack version is 4.8.3.
@th0r Can you try with webpack 4.6?
@clydin same out of memory error with Webpack 4.6.
Notice that I used webpack 4.8.3 in both cases previously - it worked fine before Angular upgrade.
@clydin by the way I used Node v8.11.2. After upgrading to Node v10.1.0 results are 2.45gb / 53 seconds i.e. memory consumption is still very high (+101%) but build time became almost identical to what I had before.
@th0r That's good to hear at least the build time is better. Is that with webpack 4.6 or 4.8.3?
This is with webpack 4.8.3. Downgrading to 4.6.0 doesn't reduce memory consumption.
@th0r can you also try with Build Optimizer turned off in CLI 1.x versus 6.x please?
with Build Optimizer turned off
How can I turn if off?
If the webpack config uses this loader: @angular-devkit/build-optimizer/webpack-loader; then try removing it.
If the webpack config uses this loader: @angular-devkit/build-optimizer/webpack-loader; then try removing it.
Hmm, I didn't know it exists, so it wasn't turned on 馃槈
@clydin could you point to the line in @angular/cli webpack config that turns it on?
We do it here for general JS files https://github.com/angular/devkit/blob/0be99d3e3f5bc96ea57fd72b835ca83f95f4fe5f/packages/angular_devkit/build_angular/src/angular-cli-files/models/webpack-configs/common.ts#L162-L182
And here for application files https://github.com/angular/devkit/blob/0be99d3e3f5bc96ea57fd72b835ca83f95f4fe5f/packages/angular_devkit/build_angular/src/angular-cli-files/models/webpack-configs/typescript.ts#L98-L103
But it will only make it slower if you don't use it already. Makes for smaller bundles though.
Also, did I think the change might be unrelated to either Angular or ngtools/webpack. Probably only one of those is affecting things.
If you use the 1.x ngtools/webpack, do you get the lower memory usage?
If you use the 1.x ngtools/webpack, do you get the lower memory usage?
@filipesilva @ngtools/webpack v1.10.2: 2.58gb / 51 seconds
That's... odd.... so it sounds like the increased memory usage was due to updating Angular libraries (outside of Angular CLI)?
Here is the package.json diff: https://github.com/angular/angular-cli/issues/10897#issuecomment-391372964
Maybe it's somehow related to update of rxjs and it's new importing rules? Maybe it adds more work to webpack?
I wouldn't expect that, but maybe. I'll be doing some performance benchmarking soon and be sure to keep an eye out on the memory usage.
@filipesilva I've found an issue...but I don't have words...
That was because of updated lodash types...
After reverting them back from 4.14.109 to 4.14.70 memory usage went down to ~1.4gb and there is no "out of memory" error anymore.
I can't believe it! I didn't even include it in the diff I posted above because I thought it doesn't matter at all! WTF?!
My only assumption is that they added a few recursive types like PartialDeep that consume a lot of memory but I'm not sure about anything in this world anymore.
Well that's odd. But also interesting. Can you give me the lodash before and after versions? Maybe we can come up with a simple repro and pinpoint the problem. A lot of people might be suffering from this. Used lodash imports would also be useful.
You can find before/after versions in the comment above. We import the whole lodash and use quite a lot of it's methods including _.chain.
@filipesilva to summ up:
Node.js v10.1.0 with --max_old_space_size=8192 / webpack v4.8.3 / AoT build without minification:
@types/lodash v4.14.109 - 2.72gb / ~50 seconds@types/lodash v4.14.70 - 1.62gb / ~50 secondsWithout max_old_space_size set:
@types/lodash v4.14.109 - out of memory error after ~20 minutes@types/lodash v4.14.70 - 1.33gb / ~52 secondsP.S. lodash v4.14.70 is not compatible with TS 2.7 out of the box - TS throws error node_modules/@types/lodash/index.d.ts(13154,53): error TS2344: Type 'T' does not satisfy the constraint 'object'. To fix it replace this line with isWeakSet<T extends object>(value?: any): value is WeakSet<T>;.
I have the same problems like @ArnaudBarre . But even with the Update to node v10 our travis prod build with angular 6 fails https://travis-ci.org/utetrapp/geli/builds/395360885#L1108. If anybody has an Idea that would be great!
@PatrickSkowronek try to increase the Node.js heap size using --max_old_space_size flag.
@th0r yes I did, I gave it 4096 Mb which should be enough.
@filipesilva After upgrade to Angular v6, my builds are always out of memory when execute ng build --prod.
But after i remove @types/lodash, the build can be passed. So much thanks for @th0r .
But the build time is still much slower than using Angular v5.(About double times). And I have already closed the build optimizer and using Node.js 10.
My Angular version is 6.0.6. Cli version is 6.0.8. It seems the production build time is the main reason which blocking many users upgrade to new Angular version. About half year ago when i try to upgrade to Angular5, i met out of memory issue when i'm using the production build with AOT. I can't find a solution so i can only wait. I wait for about 2 month and update to the latest Angular cli version, the AOT build works.
BTW, currently if i build the production version in my local, it works. But when i try to build it in the CI(I'm using Appveyor), it will throw out of memory error until i remove @types/lodash as i mentioned above. But the CI build works well with Angular v5 and Cli version 1.7.x. For many scenarios of the deployment, the production build should be happened in the CI environment which means it may not have a very good hardware as your local PC. But it doesn't mean that the build should not be passed in the CI.
@lokyoung @th0r How did you determine it was @types/lodash causing your issue? I don't have those installed, but am having same issue where can build successfully on local machine with memory limit set to 8192, but on appveyor it fails with out of memory exception.
@PTC-JoshuaMatthews update part of dependencies, run build and check memory usage. If it's ok then update another part of dependencies and check memory usage etc.
turn off the sourcemap and we get very good build performance. Angular version: 6.0.6 and 6.0.9
Running NodeJs: 10.1.0 on aws CodeBuild
@angular/cli: "6.0.8",
I can confirm that the issue is when using the sourcemap: true configuration flag that causes the problem. turned it off and everything works as expected.
But what if you need source-maps in your prod build - what to do?
@dauledk i would recommend to downgrade the cli to a version where build works.
And wait for a fix in a future release.
Hi @stefan-karlsson. Could you point what cli version is working for u.
Just now, I have downgraded it to the 6.0.1 and I still have issue.
My solution was to explicitly specify in the tsconfig.ts sourcemap: false for the expected environment.
Even if it's supposed to be set at false by default.
Hi all,
Are you still seeing this with the latest versions? Does anyone have some up to date reproduction instructions that I can follow to see it too?
@filipesilva our project has grown a little and here are the latest results:
Angular CLI: 7.2.3
Node: 10.15.1
OS: darwin x64
Angular: 7.2.2
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router, upgrade
Package Version
-----------------------------------------------------------
@angular-devkit/architect 0.12.3
@angular-devkit/build-angular 0.12.3
@angular-devkit/build-optimizer 0.12.3
@angular-devkit/build-webpack 0.12.3
@angular-devkit/core 7.2.3
@angular-devkit/schematics 7.2.3
@angular/cdk 7.3.0
@angular/cli 7.2.3
@ngtools/webpack 7.2.3
@schematics/angular 7.2.3
@schematics/update 0.12.3
rxjs 6.4.0
typescript 3.1.6
webpack 4.29.0
Build (sourcemaps off, minimizer off):
max_old_space_size=8192: 1.45 mins / 3.57gb mem peakno max_old_space_size: ~1 min / JavaScript heap out of memory error So I can't see any progress here.
@th0r it is expected that at some point you need to increase the memory limit. That is not a bug. Larger projects will need more resources to build. Since NodeJS projects have a default memory limit, it will be reached at some point.
One can argue that the current memory usage is too high. I wouldn't say that 2 minutes to build a project for production is too long though. I wouldn't even say 2mins to build a large project for development is too long, as long as rebuilds are short.
I don't know the specifics of your project, but please bear in mind that it's not all just your source code. You might not have a huge amount of source TS files but still have a lot of code in imported libraries.
I wouldn't say that 2 minutes to build a project for production is too long though.
But it's not for production - both sourcemaps and minification are turned off. If I turn them on stats become 4.6 mins / ~5gb mem at peak.
I think 5gb of ram is a little bit too much.
I noticed this as well after @types/lodash was added to our project. Cranked up the mem limit and haven't looked back. I'm interested to know if there's a better way or if turning up the mem is hte suggested solution.
bump
@filipesilva @th0r I have a similar issue, I am using angular cli build with tfs build pipeline.
I use ng build --prod and the encounter the FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory.
I know i have to increase the memory size, I am unsure how to do it. if i perform from cmd:
node --max_old_space_size=4096 ./node_modules/.bin/ng build --prod, node is not valid command for ng
How do i correctly set the max_old_space_size as a global value and use ng build --prod or execute npm run
using:
Angular 7.2.0
"@angular-devkit/build-angular": "~0.11.3"
Node v8.11.3
Tried updating node to v 10.15.3 but the build times are same.
@gnagakarthik I use custom build configuration instead of ng build so the command in package.json looks like this node --max_old_space_size=8192 ./node_modules/.bin/gulp compile-scripts and it works fine.
Seems like you can set it via NODE_OPTIONS env variable.
I run since a few day's also in this issue and done my workaround as follow:

node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng serve --prod
node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build --prod
node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng serve -c myenv
node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build -c myenv
It works actually fine for my usage with the default ng server/build process. I hope not to run in it soon again...
To git raid of this issue add this
"build:prod": "node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build --prod"
line to your scripts section of package.json file. It will looks like
"scripts": {
"ng": "ng",
"start": "ng serve",
"build": "ng build",
"build:prod": "node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build --prod",
"test": "ng test",
"lint": "ng lint",
"e2e": "ng e2e"
}
and now run
npm run build:prod
Even after assigning 8gigs, my build still fails. Sourcemap is false as well. This didn't happen when I was on ng5, after ng7, it broke altogether. I cannot even run webpack stats to see what is taking up so much data..
Increase maximum memory allocated for budgets in angular.json
"budgets": [
{
"type": "initial",
"maximumWarning": "2mb",
"maximumError": "11mb"
}
]
and used this command
node --max_old_space_size=10500 'node_modules/@angular/cli/bin/ng' build --prod
We are seeing this on dev builds as well. We used ionic to create or project and it uses architect. I am wondering if this has something to do with architect not managing memory correctly. Maybe file copies as we have a lot of assets that architect is copying.
Also, we were not seeing this issue under ng 5 before the migration to ng7
Upgraded to Angular 8.1 from 7.2.15.
Immediately saw the issue, out-of-memory. Same configuration, but 8 builds for both ES2015 and ES5, I suppose this is the issue.
Solved by increasing the Node memory limit from the default 1.5GB to 2.0GB.
This might mean incurring in higher cost if you're on, e.g., AWS.
I'm getting this message with cli 8.2.1:
allocation failure scavenge might not succeed...Very long string[7203]...typescript.js...FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory.
adding --max_old_space_size=8000 didn't help
"@angular-devkit/build-webpack": "^0.802.1",
"@angular-devkit/build-angular": "^0.802.1",
"@angular-devkit/build-ng-packagr": "^0.802.1",
thoughts?
We have been seeing memory problem on Angular CLI 8 and work has been tracked in https://github.com/angular/angular-cli/issues/13734. I'll close this issue in favor of that one. Please check out the comments there, especially https://github.com/angular/angular-cli/issues/13734#issuecomment-521743839.
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
_This action has been performed automatically by a bot._
Most helpful comment
I run since a few day's also in this issue and done my workaround as follow:
It works actually fine for my usage with the default ng server/build process. I hope not to run in it soon again...