feat(@angular/build): add library builder

[alan-agius4]

PR Checklist

Please check to confirm your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/angular/angular-cli/blob/main/CONTRIBUTING.md#-commit-message-guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

• Feature

What is the current behavior?

Currently, there is no native @angular/build:library builder in @angular/build.

Issue Number: N/A

What is the new behavior?

Add a new native @angular/build:library builder providing a modern, high-performance compilation and packaging pipeline.

Does this PR introduce a breaking change?

• No

Other information

[alan-agius4]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a new library builder (@angular/build:library) designed to compile, bundle, and package Angular libraries in compliance with the Angular Package Format (APF). It includes features such as incremental compilation, watch mode, asset copying, secondary entry point resolution, and package.json generation. The review feedback highlights a few critical areas for improvement: ensuring the package name is updated in options when package.json changes in watch mode, optimizing startup by avoiding redundant reads of package.json, and capturing and propagating stylesheet compilation warnings to the user.

[gemini-code-assist]

Code Review

This pull request introduces a new library builder for Angular, enabling the compilation, bundling, and packaging of libraries in accordance with the Angular Package Format (APF). The changes include the core builder logic, a dependency graph scanner for entry points, an incremental compilation pipeline, and support for secondary entry points. My review highlights performance optimizations for the dependency predicate and file change detection logic, which are critical for maintaining build speed in larger projects.

[alan-agius4]

Thanks for putting together #34127 so quickly, @thekhegay! Having a concrete implementation to look at makes evaluating the ergonomics much easier, and the data on ngwr is definitely interesting. That said, we are not sure yet if this is the direction we want to take, as there are trade offs to consider around determinism and configuration clarity. Let us keep this PR focused on landing the initial builder implementation first, and we can continue evaluating whether pattern support is something we want to pursue.

@dherges That is definitely a large part of it, but the speedup comes from several specific architectural changes beyond just removing the RxJS transform layer:

1. Shared Stylesheet Bundling:
   • In ng-packagr, each entry point instantiates its own StylesheetProcessor.
   • Here, a single ComponentStylesheetBundler is shared across all entry points, allowing esbuild state and Sass worker pool caches to be reused across the entire project and invalidated centrally.

2. Public API Invalidation via Declaration Hashing:
   • We hash the emitted .d.ts bundle (lastDtsHash). Downstream entry points are only marked dirty if the public type declarations actually changed. Internal implementation changes in an upstream entry point will not trigger recompilation of dependents.

3. Dedicated Worker Pool for Production Builds:
   • For non watch builds, entry points within each topological batch are compiled across worker threads via compilerWorkerPool.

4. Single Pass Output Emission:
   • Rather than writing files throughout individual transform steps, all output files across all entry points (bundles, declarations, sourcemaps, manifests, assets) are written in a single batched pass at the end.

5. Direct Async Pipeline:
   • Removing injection-js and the RxJS transform chain eliminates the scheduling and subscription overhead across dozens or hundreds of entry points.

[dherges]

Regarding ng update

[thekhegay]

@alan-agius4 Understood on patterns, happy to leave #34127 parked until the builder itself lands.

Meanwhile I ran the builder against ng-zorro-antd (105 entry points, same layout as ngwr: one folder per entry point with public-api.ts, a style and a less condition in exports). Median of 3 alternating runs, 14 cores / 24 GB, both builders from the same @angular/build 22.1.8 built from this PR:

Scenario	ng-packagr	@angular/build:library
Clean build	13.27s / 21.2s CPU / 1.68 GB	10.67s / 86.5s CPU / 7.78 GB
Warm build (no change)	10.25s / 16.7s CPU / 1.57 GB	9.15s / 74.6s CPU / 8.85 GB
Watch: first build	12.29s / 2.6 GB	12.76s / 2.5 GB
Watch: template edit	88ms	80ms
Watch: edit that changes the .d.ts	1.80s	1.38s

No OOM on this one, on the default heap or the 14 GB one the repo sets. Watch memory matches ng-packagr because watch doesn't create the worker pool; the non-watch gap is 13 workers by default on a 14-core machine.

Output matches closely: same 421 files, same 185 exports keys with every style / less condition, and identical export names in 206 of the 210 emitted files. The four that differ are the two bugs I filed with reductions, #34130 (a name reached through two export * paths is dropped, which reproduces in rolldown alone) and #34131 (tslib missing from the output package.json).