refactor(@angular/build): remove arbitrary cap from maxWorkers and localize bundling concurrency - #33994
Merged
Merged
Conversation
…calize bundling concurrency Previously, maxWorkers was clamped to a maximum of 4 globally across the entire build system. This limitation was originally introduced to mitigate memory pressure from Babel transforms, but subsequent optimizations such as the OXC linker migration, zero-copy shared memory for i18n translations, and bounded memory buffers have eliminated those memory constraints. Consequently, clamping maxWorkers artificially restricted post-bundle operations like translation inlining and route prerendering on high-core systems. This change decouples the global default of maxWorkers so that it scales with available parallelism minus one, ensuring the main thread is not starved while allowing parallel tasks to utilize full hardware capacity. When NG_BUILD_MAX_WORKERS is specified, it is safely parsed as a positive integer or falls back to the default available parallelism. To avoid CPU contention during bundling when esbuild concurrently executes its internal multi-threaded Go routine across all cores, transformation concurrency for JavaScriptTransformer is now locally capped to at most 4 unless NG_BUILD_MAX_WORKERS has been explicitly provided, tracked via the exported hasCustomMaxWorkers option.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request refactors the configuration of the maximum number of workers via the NG_BUILD_MAX_WORKERS environment variable. It introduces hasCustomMaxWorkers to identify if a custom worker count was explicitly set. The default worker count now defaults to available parallelism minus one, while the compiler plugin caps transformation concurrency to 4 by default to avoid CPU contention during bundling. Comprehensive unit tests have been added to verify the environment variable parsing. There are no review comments, so I have no feedback to provide.
clydin
added
the
action: review
alan-agius4
approved these changes
Sep 2, 2026
alan-agius4
added
action: merge
Member
Author
|
This PR was merged into the repository. The changes were merged into the following branches:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Previously,
maxWorkerswas clamped to a maximum of 4 globally across the entire build system. This limitation was originally introduced to mitigate memory pressure from Babel transforms, but subsequent optimizations such as the OXC linker migration, zero-copy shared memory for i18n translations, and bounded memory buffers have eliminated those memory constraints. Consequently, clampingmaxWorkersartificially restricted post-bundle operations like translation inlining and route prerendering on high-core systems.This change decouples the global default of maxWorkers so that it scales with available parallelism minus one, ensuring the main thread is not starved while allowing parallel tasks to utilize full hardware capacity. When
NG_BUILD_MAX_WORKERSis specified, it is safely parsed as a positive integer or falls back to the default available parallelism.To avoid CPU contention during bundling when esbuild concurrently executes its internal multi-threaded Go routine across all cores, transformation concurrency for JavaScriptTransformer is now locally capped to at most 4 unless
NG_BUILD_MAX_WORKERShas been explicitly provided, tracked via the exportedhasCustomMaxWorkersoption.