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.json target from es2015 back down to es5, 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.

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

@robelcik many many thanks

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=12000 also 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.

I guess this is related (or even the same): #16515

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