Command

build

Is this a regression?

• Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

@angular/build 21.2.13 / Angular 21.2.15 / TS 5.9.3

Description

After upgrading to Angular 22, our production build's peak memory rose from ~15.5GB to ~23.8GB (+53%), which started OOM-killing our 16GB CI runners. A/B measurement on the identical commit of a large Nx monorepo (~7,400 TS
files, ~2,250 components, single application target), cold build cache, default workers, sampling combined RSS of the full node + esbuild process tree every 3s:
Toolchain │ Peak RSS │
@angular/build 21.2.13, Angular 21.2.15, TS 5.9.3 │ 15.5GB │
@angular/build 22.0.0, Angular 22.0.0, TS 6.0.3 │ 23.8GB │
@angular/build 22.0.1, Angular 22.0.0, TS 6.0.3 │ 22.3GB │

• esbuild is 0.28.0 in both setups (unchanged).
• The application code is identical in both runs (the v21 build needed only ignoreDeprecations adjusted in tsconfig).
• 22.0.1's stylesheet-bundler leak fixes (fix(@angular/build): prevent concurrent stylesheet bundling esbuild context leaks #33318) recover ~1.5GB but the bulk of the increase remains.
• NG_BUILD_MAX_WORKERS=2 makes peak memory worse (31.8GB), not better.
• Caveat: TypeScript necessarily moved 5.9.3 → 6.0.3 with the Angular major, so we cannot separate the TS 6 share of the increase from @angular/build 22 itself.
• Symptom on constrained machines: host OOM killer fires (or esbuild dies with fatal error: all goroutines are asleep - deadlock! when Node's --max-old-space-size exceeds physical RAM).

Minimal Reproduction

Private repo, so I can't share a reproduction, but happy to run instrumented builds / --stats-json / heap profiles on request.

Exception or Error

Your Environment

Node 24.16.0, npm 11.x, macOS 27 (arm64) + Linux CI, Nx 21.3.2

Anything else relevant?

No response