An unhandled exception while Generating ES5 bundles
ronfogel opened this issue · comments
🐞 Bug report
Command (mark with an x)
- [ ] new
- [x ] build
- [ ] serve
- [ ] test
- [ ] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc
Is this a regression?
Yes, the previous version in which this bug was not present was 8.2.1, maybe 8.2.2
Description
When using ng build in circle ci, it throws an error (screenshot attached):
Generating ES5 bundles for differential loading...
An unhandled exception occurred: cancel after 1 retries!
🔬 Minimal Reproduction
Unfortunately, I cant provide a way to reproduce it as it happens only in CI and I am unable to get the logs. I think it's related to the size of my app but I cant be sure.
🔥 Exception or Error
WARNING in budgets, maximum exceeded for initial. Budget 2 MB was exceeded by 2.2 MB.
Generating ES5 bundles for differential loading...
An unhandled exception occurred: cancel after 1 retries!
See "/tmp/ng-8Tr7C1/angular-errors.log" for further details.
npm ERR! file sh
npm ERR! code ELIFECYCLE
npm ERR! errno ENOENT
npm ERR! syscall spawn
npm ERR! frontend-mallabee@2.0.1 build-dev: `ng build --configuration dev`
npm ERR! spawn ENOENT
npm ERR!
npm ERR! Failed at the frontend-mallabee@2.0.1 build-dev 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! /home/circleci/.npm/_logs/2019-08-31T09_20_07_881Z-debug.log
Exited with code 1
🌍 Your Environment
@angular-devkit/architect 0.803.2
@angular-devkit/build-angular 0.803.2
@angular-devkit/build-optimizer 0.803.2
@angular-devkit/build-webpack 0.803.2
@angular-devkit/core 8.3.2
@angular-devkit/schematics 8.3.2
@angular/cdk 8.1.4
@angular/cli 8.3.2
@angular/flex-layout 8.0.0-beta.27
@angular/material 8.1.4
@ngtools/webpack 8.3.2
@schematics/angular 8.3.2
@schematics/update 0.803.2
rxjs 6.5.2
typescript 3.5.3
webpack 4.39.2
Same issue here.
Hi @ronfogel and @xawill, can anyone of you provide the logs please and take it from there?
Most likely though we'd need a minimal repro.
You can read here why this is needed. A good way to make a minimal repro is to create a new app via ng new repro-app and adding the minimum possible code to show the problem. Then you can push this repository to github and link it here.
Dear @alan-agius4,
Thank you very much for getting back to us so quickly. Here are my logs :
> OBFUSCATED_PROJECT@0.0.0 ng OBFUSCATED_CI_PATH
> ng "build"
chunk {main} main-es2015.js, main-es2015.js.map (main) 8.59 MB [initial] [rendered]
chunk {polyfills} polyfills-es2015.js, polyfills-es2015.js.map (polyfills) 264 kB [initial] [rendered]
chunk {polyfills-es5} polyfills-es5-es2015.js, polyfills-es5-es2015.js.map (polyfills-es5) 584 kB [initial] [rendered]
chunk {runtime} runtime-es2015.js, runtime-es2015.js.map (runtime) 6.16 kB [entry] [rendered]
chunk {styles} styles-es2015.js, styles-es2015.js.map (styles) 2.09 MB [initial] [rendered]
chunk {vendor} vendor-es2015.js, vendor-es2015.js.map (vendor) 10 MB [initial] [rendered]
Date: 2019-08-27T13:16:27.208Z - Hash: cdbe70565be644ecc800 - Time: 62573ms
Generating ES5 bundles for differential loading...
An unhandled exception occurred: cancel after 1 retries!
See "/tmp/ng-EB7H6h/angular-errors.log" for further details.
npm ERR! file sh
npm ERR! code ELIFECYCLE
npm ERR! errno ENOENT
npm ERR! syscall spawn
npm ERR! OBFUSCATED_PROJECT@0.0.0 ng: ng "build"
npm ERR! spawn ENOENT
npm ERR!
npm ERR! Failed at the OBFUSCATED_PROJECT@0.0.0 ng script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
Here is what is contained in /tmp/ng-EB7H6h/angular-errors.log :
[error] ProcessTerminatedError: cancel after 1 retries!
at Farm. (OBFUSCATED_CI_PATH/node_modules/worker-farm/lib/farm.js:88:25)
at Array.forEach ()
at Farm. (OBFUSCATED_CI_PATH/node_modules/worker-farm/lib/farm.js:82:36)
at listOnTimeout (internal/timers.js:531:17)
at processTimers (internal/timers.js:475:7)
As a programmer, I totally understand why you need a way to reproduce the problem in order to solve it. Unfortunately I cannot, as it only happens when building in the CI (i.e. it doesn't happen locally even though the setup is identical) and of course I cannot give you access to my CI...
I have no clue how to help you help me for this one... But tell me if you have any idea.
Seeing the full stacktrace it might be a resource problem since CIRCLE CI will have limited resources If you are using the free plan the resources are 2CPU and 4096MB.
It's Atlassian bamboo CI, for me, but I also arrived at the conclusion that it was ressources related. I'll try to tweak the performance parameters of Bamboo.
Any particular reason why 8.3.x is more ressource-hungry than <8.3 ?
In 8.3 we are using workers farms which will spawn multiple processes at once to parallelize ES5 bundles generation.
@alan-agius4 Maybe a good way to maintain it (sounds like a good way to improve performance locally) and provide a solution to CI environments with limited resources would be adding an option to angular.json or some other place to determine whether it should run multiple processes to parallelize ES5 bundles generation or not.
This has just started happening to me after Generating ES5 bundles for differential loading... on a Mac Mini with 2.6GHZ i5 and 16GB of RAM latest MacOS 10.14.6 when I build with --debug through Ionic4 (not a CI system), or rather, ng build with no options.
Upgraded from 0.803.2 to 0.803.3 etc and still happens
(I'm not presently in a position to make a minimal repo, sorry)
Generating ES5 bundles for differential loading...
<--- Last few GCs --->
[37943:0x10263e000] 81008 ms: Scavenge 1323.3 (1422.1) -> 1322.6 (1422.6) MB, 5.6 / 0.0 ms (average mu = 0.115, current mu = 0.085) allocation failure
[37943:0x10263e000] 81017 ms: Scavenge 1323.5 (1422.6) -> 1322.8 (1423.1) MB, 6.7 / 0.0 ms (average mu = 0.115, current mu = 0.085) allocation failure
[37943:0x10263e000] 81032 ms: Scavenge 1323.6 (1423.1) -> 1323.0 (1423.6) MB, 11.6 / 0.0 ms (average mu = 0.115, current mu = 0.085) allocation failure
<--- JS stacktrace --->
==== JS stack trace =========================================
0: ExitFrame [pc: 0x2eb0f885be3d]
Security context: 0x29da7771e6e1 <JSObject>
1: SourceMapGenerator_addMapping [0x29daa22a4199] [/redacted/node_modules/@babel/generator/node_modules/source-map/lib/source-map-generator.js:~94] [pc=0x2eb0f8ed8975](this=0x29da67606c49 <SourceMapGenerator map = 0x29dacd3304b9>,aArgs=0x29da105603f1 <Object map = 0x29daef9ee9f1>)
2: argum...
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
1: 0x10003b125 node::Abort() [/usr/local/bin/node]
2: 0x10003b32f node::OnFatalError(char const*, char const*) [/usr/local/bin/node]
3: 0x1001a89a5 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
4: 0x100573dc2 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/usr/local/bin/node]
5: 0x100576895 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/usr/local/bin/node]
6: 0x10057273f v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/usr/local/bin/node]
7: 0x100570914 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/bin/node]
8: 0x10057d1ac v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/usr/local/bin/node]
9: 0x10057d22f v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/usr/local/bin/node]
10: 0x10054cb74 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/usr/local/bin/node]
11: 0x1007d4a44 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/usr/local/bin/node]
I was able to fix my build by for the moment changing the tsconfig.app.json target from es2015 back down to es5, this disabled differential loading.
See https://angular.io/guide/deployment#differential-loading
@pastcompute Can you provide the output just prior to the Generating ES5 bundles for differential loading...? Or more specifically, the sizes of the source map files? Sourcemap processing on node is unfortunately incredibly memory intensive. We've added an alternative source map processing path when the code size is beyond a certain point but the heuristics may need to be adjusted. Any information as to file size or number of source entries within the source maps would be helpful in making improvements in this area.
I was able to fix my build by for the moment changing the
tsconfig.app.jsontargetfromes2015back down toes5, this disabled differential loading.See https://angular.io/guide/deployment#differential-loading
Thanks it works for me
@clydin here ya go:
From CircleCI (failing build):
https://gist.github.com/josh-m-sharpe/864bcf6386e467f1f3218829105ff9b3
And filesizes after compiling (successfully) locally:
https://gist.github.com/josh-m-sharpe/92fd81d1f8cef6e14ca248e6466383c0
I can reproduce the problem by running ng build locally and I've tried this with CLI versions: 8.3.2, 8.2.2, 8.2.1 and 8.1.1. Our app is exceeding the budget limits of 5MB for the production builds and I have been trying to investigate with webpack-bundle-analyzer what can be removed, so that's why I needed to run ng build --stats-json locally. Right now, the only way this works is by changing the target from es2015 to es5 in tsconfig.json as @pastcompute suggested.
I'm running WSL on Windows.
Same issue here with CircleCI. Targeting es5 instead of es2015 works but it shouldn't be a viable solution.
Yeah, definitely not a viable solution. I changed it to es5 too. I'm planning to lower my bundle size to see if it fixes it, but that can't happen for a while. I wish this could be resolved without a bundle size change.
Bumping my build agents from 2GB to 8GB of RAM fixed this for me. I'm not sure if 4 or 6GB would have worked, didn't have time to spend on investigation today.
Same issue here with 4GB RAM in linux server.
@vikerman is it possible to test your change by installing @angular/cli from master somehow?
Edit: I see this: https://github.com/angular/angular-cli/tree/master/packages/angular/cli#development-hints-for-working-on-angular-cli ... but I think most folks on this thread have issues in a CI env. So installing from master via yarn/npm is probably required to fully test the update.
Snapshot releases for the relevant package can be found here: https://github.com/angular/angular-devkit-build-angular-builds
All the CLI packages have equivalent snapshot repositories as well.
Please note that these should generally only be used for testing as they represent a version in active development.
ng buildrenders a bundle report where ispolyfills-es5-es2015.[hash].jsbut if we open adistfolder there is nopolyfills-es5-es2015.[hash].jsfile.- bundle sizes in the report don't match actual file sizes on the disk, it leads to the
budgetsissue.
npx ng build --prod
chunk {0} runtime-es2015.b948044840398824f16e.js (runtime) 2.83 kB [entry] [rendered]
chunk {1} main-es2015.112ea16b17b5a46676cc.js (main) 40.3 kB [initial] [rendered]
chunk {2} polyfills-es2015.d3e61f0dd2b58e518eca.js (polyfills) 64.3 kB [initial] [rendered]
chunk {3} polyfills-es5-es2015.f8b5a32bf736d11d106f.js (polyfills-es5) 223 kB [initial] [rendered]
chunk {4} styles.09e2c710755c8867a460.css (styles) 0 bytes [initial] [rendered]
chunk {5} vendor-es2015.54fe0f200bb05726020b.js (vendor) 376 kB [initial] [rendered]
Date: 2019-09-26T11:40:10.150Z - Hash: a7854bf899dd1ecaa499 - Time: 16150ms
Generating ES5 bundles for differential loading...
ES5 bundle generation complete.
Dist folder:
26.09.2019 14:40 15 557 3rdpartylicenses.txt
26.09.2019 14:40 948 favicon.ico
26.09.2019 14:40 954 index.html
26.09.2019 13:49 38 186 main-es2015.112ea16b17b5a46676cc.js
26.09.2019 13:49 38 195 main-es5.112ea16b17b5a46676cc.js
26.09.2019 13:46 37 277 polyfills-es2015.d3e61f0dd2b58e518eca.js
26.09.2019 13:46 124 853 polyfills-es5.f8b5a32bf736d11d106f.js
26.09.2019 13:46 1 485 runtime-es2015.b948044840398824f16e.js
26.09.2019 13:46 1 485 runtime-es5.b948044840398824f16e.js
26.09.2019 14:40 0 styles.09e2c710755c8867a460.css
26.09.2019 13:49 232 482 vendor-es2015.54fe0f200bb05726020b.js
26.09.2019 13:49 258 105 vendor-es5.54fe0f200bb05726020b.js
As you can see vendor and polyfills bundle sizes are not correct.
The number of affected users seems to be quite high, in the end. Any news from the dev team ? Have you been able to precisely identify the issue ?
This seems to be resolved for me using the latest CLI.
I have updated to the latest Angular 8 (8.2.8) and CLI (8.3.6) versions with compilerOptions / target:'es2015' but unfortunately I still get the same heap error.
I have to set target back to es5 to make it work.
Although, I have tried it with my existing project and not a new one. I will check if the new CLI changed anything in the config files I need to adjust in my existing config.
For this issue, the @angular-devkit/build-angular package is the critical element. Ensure that it is at the latest version (currently 0.803.6).
Please also try to keep this issue centered on the originating issue of memory usage. Other issues should be tracked separately and may already be in the process of being fixed (#15666).
I take back my previous comment that this has been fixed. I am still seeing the issue using these packages:
"@angular/common": "~8.2.8",
"@angular/core": "~8.2.8",
"@angular/forms": "~8.2.8",
"@angular/platform-browser": "~8.2.8",
"@angular/platform-browser-dynamic": "~8.2.8",
"@angular/router": "~8.2.8",
"@angular-devkit/architect": "^0.803.6",
"@angular-devkit/build-angular": "^0.803.6",
"@angular-devkit/core": "^8.3.6",
"@angular-devkit/schematics": "^8.3.6",
"@angular/cli": "^8.3.6",
"@angular/compiler": "^8.2.8",
"@angular/compiler-cli": "^8.2.8",
"@angular/language-service": "^8.2.8",
Error:
Generating ES5 bundles for differential loading...
An unhandled exception occurred: cancel after 1 retries!
Got the same error with the local build inside docker container.
Updating packages didn't help. Switching target to es5 solve issue.
Same issue with the worker-related exception only occurring when using CI (AWS CodeBuild) versus manually building on my local computer. Bumped the CodeBuild environment from 3GB RAM/2vCPU to 7GB RAM/4vCPU, and that resolved the error.
Experiencing the same issue. Only solution is to not generate bundles for differential loading as described above ☝️#15493 (comment)
Try with this:
node_modules/@angular/cli/bin/ng build --prod
or:
node --max_old_space_size=8192 node_modules/@angular/cli/bin/ng build --prod
Same here:
An unhandled exception occurred: Call retries were exceeded
See "/private/var/folders/ms/qq0y5v_d0_q8q1sk43c87b080000gn/T/ng-xZOLD0/angular-errors.log" for further details.
event": "Allocation failed - JavaScript heap out of memory",
"trigger": "FatalError",
If it helps this solved it for me:
"build-beta": "NODE_OPTIONS=--max-old-space-size=8192 ng build --verbose --configuration beta",
prepending to the scripts part of your app build the
NODE_OPTIONS=--max-old-space-size=8192
Should increase memory size for those that this can help them
For anyone experiencing the memory issue, please ensure that the CLI is on the latest version (currently 8.3.7). Also, please ensure that the @angular-devkit/build-angular package is also at the latest (currently 0.803.7). There are also benefits to using the current version of Node.js (12.11) if possible.
For the team to provide more assistance and troubleshoot these occurrences, please provide additional information regarding your projects. An example repository that can consistently reproduce the behavior would be ideal. However, the settings used during the build are paramount (especially optimization, aot, and sourcemaps). An output of a working ES5 only build with size information would also be beneficial.
@clydin here is a repo https://github.com/jimmykane/quantified-self/ you can try to do a beta build and it will fail
Upgraded our app from 7 to 8 and ran into this today. @jimmykane solved my issue by increasing the max old space size flag.
NODE_OPTIONS=--max-old-space-size=8192 ng build --prod
Our build right now is pretty large. The largest file that is built is the main-es5.xxxx.js file at 6.2MB.
@richarddavenport , I can also confirm that the NODE_OPTIONS solution from @jimmykane is working, and in appr. 3 minutes it builds without errors. Peak memory usage exceeds 4 GB. Not too fast though on an Core i7 / 32GB / SSD machine.
And I can also see that my es5 bundle is 14MB while the es2015 bundle is 17MB. Although the polyfill for es2015 is 460KB less than es5 polyfill, the bundle size is much much more than I can save on the polyfill files. So I have a feeling that it is not mature yet - while the idea sounds really good.
@csegyud Are those numbers the on-disk sizes? The ES5 bundles are essentially the ES2015 bundles with additional code structures added to mimic ES2015 features in ES5. In development mode, large ES5 bundles are also not pretty-printed after transformation whereas the ES2015 bundles are left as-is. This can give the illusion that the ES5 bundles are smaller when optimizations are not enabled.
Faced with same issues after migration from Angular 7 to 8.
- error with CI build: "javascript heap out of memory"
Fixed via --max-old-space-size=4096 - error with local build inside Docker for Windows container: "Call retries were exceeded"
Fixed via allocating 4Gb of memory to Docker engine (it was 2Gb by default in docker settings).
@clydin, These are on disk sizes and result of a production build.
The sizes of *.js in my dist folder:
17720682 bytes main-es2015.c54c6ee19c4c250f0f9a.js
14716590 bytes main-es5.c54c6ee19c4c250f0f9a.js
132733 bytes polyfills-es2015.833fec98dca74639f6a6.js
605953 bytes polyfills-es5.12a64184cfbc85c720a9.js
6263 bytes runtime-es2015.d6c52737d4587c65265f.js
5606 bytes runtime-es5.d6c52737d4587c65265f.js
Are you sure the project has optimizations enabled? The polyfill sizes for a new application in production are as follows:
37,293 polyfills-es2015.f80ea2f8856ba3d344c6.js
126,094 polyfills-es5.1323fe914a6541b59b65.js
And for a development (with AOT) build:
132,713 polyfills-es2015.js
636,519 polyfills-es5.js
Regardless, the issue appears to be triggered by having a javascript file that is in the 10MB+ range. Work is ongoing to remedy the situation and the team will update as progress is made.
@clydin, sure, you were right, the optimization was turned off. Turning it on I get 5MB bundles for both versions (es2015 is smaller by a 200 KB) which is correct enough. BTW, the compilation took ~5:30 minutes now and the memory usage peaked almost 6 GB. :) No problem though, it just fits the budget (32GB). Thanks for the hint.
Is there a version that we can rollback to that does not have this issue?
The build procedure for a 1MB app has became a nightmare.
@jimmykane Reverting to these versions helps me
"@angular-devkit/build-angular": "~0.802.2",
"@angular/cli": "~8.2.2"
@egorkel-da14 thanks so much. Tired of waiting 30+ mins to build an app.
Differential loading was introduced in version 8.0.0. Reverting to 8.2.0 will cause production builds to be longer not shorter as two full builds of the application will be performed if differential loading is enabled. This will be even more pronounced on Windows systems where file access is more costly.
Differential loading is controlled by both the target option within the application’s tsconfig and the browserslist file. The browserslist file should ideally be tailored to the application’s browser support requirements. This allows the CLI to optimize the code/stylesheets and produce the required set of application variants for the application’s target browsers. If only browsers that support ES modules are required then the ES5 variant will not be created.
If only an ES5 variant is preferred, the tsconfig target can be set to ES5 and only an ES5 variant will be created.
Thanks for your notes, but in my case I need both builds. So 8.2.0 suits me.
8.3.x would be the preferred version in that case. It is faster than 8.2.x. As an example, an application with 3500 lazy routes (that is not a typo), performs a production build with differential loading using 8.2.2 in ~15.5 minutes. With 8.3.8, that build only takes ~6.5 minutes.
It is also important to note that the new build pipeline can perform the differential loading processing of each output file in parallel using a combination of separate processes and threads (if using Node.js 12+). For applications that leverage lazy loading (a recommended best practice), not only will the end user experience improve but build times will improve as well.
The main problem discussed in this thread is that CI systems have limited resources. So parallelism causes build to fail. That's why we revert to prev version. And I know benefits of the new version.
That's not why its failing. The parallelism adjusts based the executing system. It's failing due to the large size of the main files combined with inefficiencies in the AST traverse processing pipeline of one of the CLI's dependencies which is in the process of being corrected.
Beyond this, as a best practice, lazy loading should be strongly considered when the size of the main file becomes larger than 2MB. As this can greatly affect the initial interactivity time for end-users.
@clydin here ya go:
From CircleCI (failing build):
https://gist.github.com/josh-m-sharpe/864bcf6386e467f1f3218829105ff9b3And filesizes after compiling (successfully) locally:
https://gist.github.com/josh-m-sharpe/92fd81d1f8cef6e14ca248e6466383c0
Regarding CircleCI, in my case I pushed the button "Rerun from failed" it solved the problem.
I got same problem with 9.0.0-next.9 version & Gitlab CI
- In my project, main.js file size is 1.8mb
- 9.0.0-next.7 ~ next.9 not work
- In Gitlab CI, i use Node 10.x latest image
- tried to disable sourceMap compile but it doesn't work.
- In local build, it success. Only problem on Gitlab CI
@angular-devkit/architect 0.900.0-next.9
@angular-devkit/build-angular 0.900.0-next.9
@angular-devkit/build-ng-packagr 0.900.0-next.9
@angular-devkit/build-optimizer 0.900.0-next.9
@angular-devkit/build-webpack 0.900.0-next.9
@angular/cli 9.0.0-next.9
@ngtools/webpack 9.0.0-next.9
ng-packagr 5.6.1
typescript 3.5.3
webpack 4.41.0
Adding this to my package.json solved for me:
"browserslist" : [
],
The following package.json dependencies along with Node 12.8.1 worked for me.
{
"@angular-devkit/build-angular": "~0.803.10",
"@angular/cli": "~8.3.10",
}
Also, upgraded to Node 12.12.0 and didn't see a regression.
Fixed - But needs verification.
Angular CLI: 9.0.0-next.12
Node: 10.16.3
OS: darwin x64
Angular: 9.0.0-next.11
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router, upgrade
Package Version
-----------------------------------------------------------
@angular-devkit/architect 0.900.0-next.11
@angular-devkit/build-angular 0.900.0-next.11
@angular-devkit/build-optimizer 0.900.0-next.11
@angular-devkit/build-webpack 0.900.0-next.11
@angular-devkit/core 9.0.0-next.12
@angular-devkit/schematics 9.0.0-next.12
@angular/cdk 9.0.0-next.0
@angular/cli 9.0.0-next.12
@ngtools/webpack 9.0.0-next.11
@schematics/angular 9.0.0-next.12
@schematics/update 0.900.0-next.12
rxjs 6.5.3
typescript 3.6.4
webpack 4.41.1
I get the same error in small/medium sized project with the config above.
Generating ES5 bundles for differential loading...
An unhandled exception occurred: Call retries were exceeded
The node process memory usage grows until it crashes at 1.4xGb and then it starts all over again for some time.
ng update @angular/cli (updated to 8.3.13) appears to have solved this issue for me
Simply upgrading my Mac Mini Bamboo CI server from Node 10 -> Node 12.10 fixed my builds (cli 8.3.14)
We will spend some time investigating this trying to see if memory usage can be improved.
I tried the latest version again: ng update @angular/cli @angular/core --next but I still get the same error. The good thing is that now it produces some logs and the only thing I can understand from there is that it throws an out of memory exception, at about 2Gb of memory used. How can I help?
I can confirm that it has been fixed inside the latest release.
The latest releases of the CLI contain a variety of improvements to mitigate potential memory issues. However, as Node.js has a default memory limit of 2GB per process, very large projects may still need to increase the memory value for the Node.js process. This can be accomplished via a command similar too the following:
node --max_old_space_size=4096 node_modules/@angular/cli/bin/ng build
Note the 4096 value essentially represents a maximum memory usage value for the node process in megabytes. For this example, that would be 4GB of memory. Ensure that the system has enough physical memory to support the value chosen.
It is also recommended to use the latest version of Node 12 (currently 12.13.0) as this contains important improvements related to memory usage.
In our case, we are only supporting modern browsers and using Angular 9, so what worked for me is modifying the browserlist file to only have Chrome >= 61. See this SO answer.
Edit: I wanted to ensure that down the road other browsers were also considered so I modified my browserlist like so:
last 2 Chrome versions
last 2 ChromeAndroid versions
last 2 Safari versions
last 2 iOS versions
last 2 Firefox versions
last 2 FirefoxAndroid versions
last 2 Edge versions
@clydin and @vikerman this is still failing for me with a large project I have 6656 for memory on the node process and my project is currently using v9.0.0-rc.6 so I believe your fixes should be visible yet it's still failing the same way. I've attached one of the stack traces in case that helps.
Stacktrace gist
@paullryan Can you open a new issue describing the problem you are encountering? If possible please include the full output of ng version, the build command used, the relevant sections of the configuration file for the used build command (build options & configuration options), and also the console output of the build command with different loading disabled. You should be able to use a temporary browserslist file with only Chrome 75 for the later.
@clydin I realized it was because the prod flag was not being recognized by the build system that was failing so sorry for the the false alarm, thanks for the response but no need for a new issue.
Adding this to my package.json solved for me:
"browserslist" : [ ],
This worked in conjunction with removing the file browserslist
Hello. It happened to me after upgrading to angular/cli@8.3.21 and angular-devkit/build-angular@0.803.21. Going back to .20 "fixed" the issue.
Hello. It happened to me after upgrading to angular/cli@8.3.21 and angular-devkit/build-angular@0.803.21. Going back to .20 "fixed" the issue.
How to go back to .20. please clarify me
@Harika511
In package.json:
"devDependencies": {
"@angular-devkit/build-angular": "0.803.20",
"@angular/cli": "8.3.20",
Note missing "~" or "^" characters.
Definetely started hanging on differential loading for me after I ran npm audit fix yesterday, which updated @angular-devkit/build-angular from ^0.802.2 to ^0.803.21. If I roll back to 0.802.2 I can build again. Even 0.803.0 doesn't work.
i use angular 8.2.10, install latest nodejs solved my problem. no need to change anything :)
I use angular 8.2.10, upgrade nodejs to v12.14.0 solved my problem.
run cmd
ionic cordova run android --prod
should work ..
have a good day ;)
Hi bdiriamine,
I had so so so much errors and ionic cordova build --release android nothing helped... IONIC Should know (I am using IONIC 5) for the Mobile app to release something hassle free... Your Answer saved me from two days Work.... Thank you so so so much. The Built the APP as you said.
ionic cordova run android --prod
Happy New year Cheers.
Thank you
@Harika511
In package.json:"devDependencies": { "@angular-devkit/build-angular": "0.803.20", "@angular/cli": "8.3.20",
This worked for me also. I also noticed that removing any modules that referenced "ngx-bootstrap" caused the problem to go away.
Hello. It happened to me after upgrading to angular/cli@8.3.21 and angular-devkit/build-angular@0.803.21. Going back to .20 "fixed" the issue._
thnx mate, this worked for me.
- using newest node version (
12.14.0) didn't work for me - solution for now is to go back to old dev-deps:
"devDependencies": {
"@angular-devkit/build-angular": "0.803.20",
"@angular/cli": "8.3.20",
- increasing the memory
node --max_old_space_size=12000also works as a workaround
Updating node to 12.14.0 worked for me with the latest build-angular and cli packages. Thanks.
After updating to 8.3.21, I also have this issue but only for non production issues. When building with ng build --prod , node doesn't run out of memory. (Using node v12.14.0)
Same issue for me. Can we get this issue reopened or is there another issue tracking it? This must be affecting most users.
"@angular-devkit/build-angular": "~0.803.21",
"@angular/cli": "^8.3.21",
still happens
@dicbrus could you try this?
#16515 (comment)
I accidentally stumbled upon this thread. In my case CircleCI was failing because of displaying too much progress in the build step. A small change by running ng build --no-progress helped.
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.