| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
Exposes the codeBundle cache used in executeBuild to allow for performant multi-builder setups.
|
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 |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
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:
PR Type
What kind of change does this PR introduce?
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?
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