[sdjayna]

Build output is non-deterministic: two builds of identical sources can write different stats files. Merging the component stylesheet metafiles in a stable order fixes it.

PR Checklist

• 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

• Bugfix

What is the current behavior?

Issue Number: #34209

outputs[<file>].inputs in the stats file changes between builds of the same sources. The cause is one loop in build.onEnd: the compiler plugin merges each component stylesheet's metafile into the main metafile in the order the stylesheets finished bundling, and when two stylesheets produce the same output file, the last one merged owns the entry. Every emitted file is byte-identical; only the metadata moves.

What is the new behavior?

The entries are sorted by key before merging, so the merged metafile is the same on every build.

The new spec builds two components in different directories with identical stylesheets, builds twice, and asserts the shared output is attributed to the same input both times.

Does this PR introduce a breaking change?

• No

Other information

Measured on 22.1.9 with the reproduction at https://github.com/sdjayna/angular-metafile-merge-order-repro (60 components, 12 identical-stylesheet pairs, 4 identical-image pairs): without the change 5 of 5 build pairs differed, in 7 to 10 of 54 outputs entries; with it, 0 of 3 differed and the stats file was byte-identical. The same loop is on main today. The sort runs once per build over one entry per stylesheet, so its cost does not register against the bundling.

[gemini-code-assist]

Code Review

This pull request ensures deterministic metafile generation by sorting additional compilation results by key order before merging, preventing non-deterministic output attribution caused by completion-order variations. A test has been added to verify this behavior. The feedback suggests that if the merging logic is eventually updated to merge duplicate output inputs rather than overwriting them, the test assertion should be updated to expect both input files.

[alan-agius4]

Thanks for investigating this! However, there are a couple of concerns with this approach:

1. Stats accuracy: outputs[file].inputs in an esbuild metafile is intended to list all input source files that contributed to that output file. By sorting and continuing to shallowly overwrite with Object.assign(result.metafile.outputs, metafile.outputs), we deterministically drop inputs (as seen in the test where src/app/a/shared.css is completely missing from outputs['shared.css'].inputs). When an output already exists in result.metafile.outputs, we should merge existingOutput.inputs rather than replacing the entire output entry.
2. Performance: [...additionalResults].sort(...) creates and sorts an array of [key, value] tuples across all component stylesheets on every build and rebuild in the critical path, even when statsJson is disabled. In large apps with thousands of components, this introduces unnecessary allocations and overhead. If deterministic key ordering for stats.json is required, that can be done when generating/serializing the stats JSON (where options.stats is enabled) rather than in the compilation plugin's onEnd callback.

[sdjayna]

Both points taken, and this replaces what I said to the bot above. Pushed as two fixups.

• The merge now unions inputs when an output already exists, and builds a new object for the merged entry. The new object matters: the stylesheet bundler caches its result across rebuilds and the clone shares each output's inputs, so assigning in place carried one stylesheet's input into the other's entry on later rebuilds. The sort is gone.
• The stats files are serialised with sorted keys, behind options.stats. onEnd is otherwise as it was.
• Three specs: both inputs listed on every build; both stats files sorted; and a five-build watch test that changes one of two identical stylesheets, restores it, and changes it again, the ordering that exposes an in-place merge.

Each spec fails against the code it guards, and the application target passes in full. One detail for the record: unminified CSS carries a source-path comment, so identical stylesheets share a hashed name only when styles are minified, which is why this stayed hidden in development builds.

[sdjayna]

@alan-agius4 a gentle nudge on this one, in case it slipped: both of your points from 30 September are addressed in the fixups, and it still rebases cleanly onto current main with the @angular/build unit and application integration suites passing, including the 8 statsJson specs. Happy to rebase and squash the fixups once it's approved.

[alan-agius4]

Thanks for the updates! There are still a couple of performance/memory concerns and some test cleanups needed. Please see the inline comments below. Also, when squashing the fixup commits, please make sure to update the commit message so it reflects the current approach.

[sdjayna]

You're right, the earlier revisions weren't surgical. I've applied all three suggestions:

• compiler-plugin.ts: clone-on-first-insert, then an in-place Object.assign for colliding outputs. No per-collision spread, so the v8:11536 path is gone and the cached metafile stays untouched.
• execute-build.ts: a targeted stableStringify that sorts only inputs, outputs and each output.inputs, with no JSON.stringify replacer, keeping V8 on its native serializer. (sortObjectKeys assigns through a Record<string, unknown> and casts once at return, so it type-checks under the strict config.)
• The spec uses expectSortedKeys in place of the recursive clone, and the two sorted-keys cases are folded into the existing browser and SSR tests to drop the extra builds.

One correction while I'm here: my earlier reply on the Gemini thread said this "only fixes the order, it doesn't change what the merge records." That's no longer accurate - the merge now unions the inputs of colliding outputs so every input is attributed, and the tests assert it.

Squashed into one commit with an updated message. The statsJson integration specs pass locally.

[alan-agius4]

LGTM, thanks for the updates!

[alan-agius4]

This PR was merged into the repository. The changes were merged into the following branches:

• main: b0c415a
• 22.2.x: 250fae7