max_old_space_size no longer propagated to angular build since 17.3.0

[hschmidtchen]

Current Behavior

Larger angular projects require to increase the value of the heap allocation limit beyond the default limit of ~4GB.

Up until nx version 17.2.8 it was possible to do this by using an alias for the nx executable in the package.json:

 {
  ...
  "scripts": {
    "nx": "node --max_old_space_size=8192 ./node_modules/nx/bin/nx"
  }

Migrating to nx version 17.3.0, the value is no longer propagated to the angular build process and the build fails.

Expected Behavior

The angular build process should inherit the increased heap allocation limit and should allow the build to succeed.

GitHub Repo

https://github.com/hschmidtchen/nx-reproduce-memory-issue

Steps to Reproduce

1. clone the provided repository (its based on https://github.com/nrwl/nx-recipes.git)
2. navigate to the angular-monorepo project
3. run yarn install
4. insert the following lines into node_modules/nx/bin/nx.js after the imports

const v8 = require("v8");
console.log(`NX HEAP LIMIT: ${v8.getHeapStatistics().heap_size_limit/(1024*1024)}`);

5. insert the following lines into node_modules/@angular-devkit/build-angular/src/tools/esbuild/angular/compiler-plugin.js after the imports

const v8 = require("v8");
console.log(`NG HEAP LIMIT: ${v8.getHeapStatistics().heap_size_limit/(1024*1024)}`);

6. run yarn nx build angular-store --skip-nx-cache --verbose
7. check the command logs

--> NX HEAP LIMIT will be ~8GB
--> NG HEAP LIMIT will be ~4GB indicating that the value was not propagated

8. (Optional) change all the nx dependency versions from 17.3.0 to 17.2.8 and repeat the steps above

--> NX HEAP LIMIT will be ~8GB
--> NG HEAP LIMIT will be ~8GB indicating that the value was correctly propagated

Nx Report

Node   : 18.19.0
   OS     : linux-x64
   yarn   : 1.22.21
   
   nx                 : 17.3.0
   @nx/js             : 17.3.0
   @nx/jest           : 17.3.0
   @nx/linter         : 17.3.0
   @nx/eslint         : 17.3.0
   @nx/workspace      : 17.3.0
   @nx/angular        : 17.3.0
   @nx/cypress        : 17.3.0
   @nx/devkit         : 17.3.0
   @nx/eslint-plugin  : 17.3.0
   @nx/express        : 17.3.0
   @nx/nest           : 17.3.0
   @nx/node           : 17.3.0
   @nrwl/tao          : 17.3.0
   @nx/web            : 17.3.0
   @nx/webpack        : 17.3.0
   typescript         : 5.3.3

Failure Logs

NX HEAP LIMIT: 8048
[NX CLOUD] Verifying current cloud bundle
[NX CLOUD] A local bundle currently exists:  {
  version: '2403.05.3.hotfix1',
  fullPath: '.../nxtest/angular-monorepo/.nx/cache/cloud/2403.05.3.hotfix1'
}
[NX CLOUD] Last verification was within the past 30 minutes, will not verify this time
[NX CLOUD] Done:  /.../nxtest/angular-monorepo/.nx/cache/cloud/2403.05.3.hotfix1

 >  NX   --skip-nx-cache disables the connection to Nx Cloud for the current run.

   The remote cache will not be read from or written to during this run.


> nx run angular-store:build:production

⠋ Building...
NG HEAP LIMIT: 4144
...

Package Manager Version

yarn v1.22.21 (but also happens with yarn 4.1.0)

Operating System

• macOS
• Linux
• Windows
• Other (Please specify)

Additional Information

The issue also appears in nx 18.0.0 which is blocking us from upgrading to the latest version (the test with v17.3.0 was just to narrow it down on a specific version change).

In case the described behavior is intended and there would be a new way of passing the increased heap allocation limit to the build process, learning about how this could be done would also be a solution.

Thanks in advance!

[montella1507]

We have the same problem. 17.2.3 works.

[ctusch]

As a workaround you can use environment variables. Nx supports .env files. To apply the option to all nx commands put an .env file in your project root with the following content: NODE_OPTIONS='--max_old_space_size=8192'

[hschmidtchen]

As a workaround you can use environment variables. Nx supports .env files. To apply the option to all nx commands put an .env file in your project root with the following content: NODE_OPTIONS='--max_old_space_size=8192'

@ctusch thanks for the hint. I can confirm that this workaround is a possible solution and generates the expected behavior in the test case outlined above!

[github-actions]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.