GeezerVison

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 (not applicable: internal Karma bundling fix; no new options or public API)

PR Type

• Bugfix

What is the current behavior?

Fixes #34250.

With @angular/build:karma, a component imported through a barrel can be captured as undefined in another component's imports array. This depends on the combination of spec entry points: an async spec importing the component directly can cause lazy module initialization to cross shared-chunk boundaries. The consuming decorator can run before the component is initialized.

The regression fixture includes:

1. A standalone layout component re-exported by a barrel.
2. A dialog importing that barrel and used by two specs.
3. A page importing the barrel and used by another spec.
4. An async spec importing the layout directly.

Against main (2c6e8b970), the browser reports 2 failed, 2 successful. Both dialog specs throw Cannot read properties of undefined (reading 'ɵcmp').

What is the new behavior?

The Karma build routes the discovered spec entry points through a shared virtual module that imports all selected specs. This keeps spec initialization in one module graph, avoiding the problematic partitioning across independent spec entry points.

• Preserve the existing spec-* entry names, including basename-collision handling.
• Keep code splitting enabled so Angular and its testing environment remain shared with the setup entry point.
• Include the original spec files as TypeScript root files, since the build entry points now refer to the virtual module.
• Preserve include/exclude selection: the virtual module only imports the specs collected by the existing discovery logic.

The same four browser specs now all pass. The added integration test exercises real Karma/Chrome execution rather than only checking generated bundle text.

Does this PR introduce a breaking change?

• Yes
• No

Other information

Simply setting disableCodeSplitting: true, as suggested by the earlier Vitest fix in #33729, was insufficient for Karma in this reproduction: it produced testing-environment initialization errors. This change retains shared framework chunks instead.

Validation on macOS arm64, Node.js 24.22.2, pnpm 12.16.1, and Chrome Headless 159:

• pnpm bazel test //packages/angular/build:karma_integration_tests --config=no-sharding --test_output=errors: 42 integration specs, 0 failures.
• ESLint for the changed implementation passes. The repository ESLint configuration excludes builder integration fixtures.
• Prettier checks for both changed files and git diff --check pass.

The full repository and E2E suites were not run. Large-suite build size/performance and dynamic addition of spec files during watch mode were not separately benchmarked or validated.