refactor(@angular/build): Expose codeBundleCache to buildApplicationInternal

[Aukevanoost]

First off, thanks for having a look at this!

This PR exposes the codeBundleCache used in executeBuild part of the buildApplicationInternal to allow for performant multi-builder setups (because they can share the TS cache).

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

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• Other... Please describe:

What is the current behavior?

Right now the SourceFileCache is initialized locally in the executeBuild() function.

Issue Number: N/A

What is the new behavior?

The SourceFileCache is now part of the InternalOptions, allowing tools that use this builder to (optionally) provide a shared cache that can be re-used over multiple builds. As fallback it will create the default cache object.

Does this PR introduce a breaking change?

• Yes
• No

Other information

We (native-federation) need this feature to speed up our builder. This way we can share the cache between the ESBuild plugin and main builder which decreases our build time drastically:

If interested, find the changes on our end here (it's a proof-of-concept): https://github.com/native-federation/angular-adapter/pull/4/changes#diff-6508a5b483eb2d55fd58361931d864832b5ba20178c796d07be21f9e8ac327ae

[Aukevanoost]

Hi all,

I had a small question. Is this feature/fix something that could (or is) considered for ng22? Are there any potential downsides for adding this extra option? For tools that rely on the Angular builder this could be a huge decrease in build time. I'm happy to discuss the details.

Also, I realized later that adding a predefined cache is not very productive if the cache is being purged right before starting the builder.[1] Would it make sense to skip purging the old cache if a codeBundleCache is provided?

Thanks

[alan-agius4]

Thanks for putting this together and for your patience.

While the concept of sharing the cache across builds makes sense, with our transition to tsgo and other architectural improvements to the build pipeline, a lot of the internal compilation and caching infrastructure is actively evolving and will likely change significantly.

Because of this, we'd prefer not to expand or expose these internal interfaces right now. Let's reconsider this in the future once the new pipeline settles.

[Aukevanoost]

Fair answer, I appreciate you coming back to this. Our tooling pipeline revolves around multiple runs over a codebase, each touching different zones. So being able to reuse precompiled classes saves us a bunch of build time. I'd love to help around where I can on the new pipeline!

Cheers