feat(@angular/build): Support splitting browser and server stats jsonfiles for easier consumption

[tsteuwer-accesso]

This feature supports splitting out the browser and server stats json files so it's easier to inspect the bundle in various analyzers. Today, everything gets dumped into a single file and it's nearly impossible to use without hours of fix -> remove unused browser/server chunks -> analyze and starting the loop all over again.

This feature implements the feature request I made in #28185, along with another developers request to see a stats json file for just the initial page bundle. I've tested this out in my own repository and it's already helped an incredible amount.

Original closed feature: #32631

Fixes #28185 #28671

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?

When using --stats-json, the CLI outputs a single stats.json file.

Issue Number: 28185

What is the new behavior?

We now receive a browser-stats.json, server-stats.json, browser-stats-initial.json and server-stats-initial.json

Does this PR introduce a breaking change?

• Yes
• No

This is a breaking change for anyone relying on CI processes that inspect the old stats.json file as it will no longer be named that.

Other information

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[tsteuwer-accesso]

Signed CLA.

[alan-agius4]

This changes are unrelated and unneeded.

Please revert.

[alan-agius4]

Please revert.

[alan-agius4]

Please revert.

[alan-agius4]

This isn't the ideal place for this logic. Since metadata is already being merged here, we should instead modify that process to skip merging for specific fields or keep them isolated from the start.

[tsteuwer-accesso]

Thanks, will update when I get a chance. Give me a bit :)

[tsteuwer-accesso]

@alan-agius4 , so looking into this, I was reviewing that mergeResults function and there are several places that look at metafile on the BundleContextResult like chunk-optimizer.ts, server-bundle-metadata-plugin.ts, etc. Should I keep the metafile that includes everything and then add separate browserMetafile and serverMetafile? Or what would you rather me do?

[alan-agius4]

@tsteuwer-accesso, thanks for looking into this.

The createServerBundleMetadata pulls metadata directly from a specific build, it remains unaffected by any changes in mergeResults. Furthermore, chunk-optimizer.ts utilizes browser metadata, keeping these separate shouldn't be an issue either.

[alan-agius4]

Closing this out for now as it looks like this has stalled. Please reopen if you're still interested in pursuing these changes

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}