[nagahara-naoki]

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.

[gemini-code-assist]

Code Review

This pull request updates the Karma application builder to group spec files into a single module graph using a virtual module plugin. This prevents cross-chunk lazy initialization from exposing uninitialized barrel exports. Additionally, a behavior test is added to verify barrel imports with async tests. The review feedback suggests appending the collected spec files to buildOptions.rootFiles instead of overwriting it, which prevents potential loss of existing root files.

[gemini-code-assist]

To prevent potentially overwriting any existing rootFiles that might be set on buildOptions in the future or by other setup steps, it is safer to append the new specFiles to the existing array if it exists, rather than directly overwriting it.

  buildOptions.rootFiles = buildOptions.rootFiles
    ? [...buildOptions.rootFiles, ...specFiles]
    : specFiles;

[alan-agius4]

Thank you for taking the time to investigate #34250 and put together this PR.

However, we are going to close this PR as this approach introduces several regressions and architectural issues in @angular/build:karma:

1. Breaks custom main (src/test.ts) and TypeScript polyfills: Setting buildOptions.rootFiles to only specFiles overrides the rootNames loaded from tsconfig.spec.json. Any options.main file (test_main) or .ts polyfill is excluded from the TypeScript compilation, causing builds where main imports @angular/core/testing to fail with File '...' not found in TypeScript compilation.
2. Redundant bundle emission and script loading: Mapping all $N$ spec-* entry points to the same 'angular:karma-specs' virtual module causes esbuild to emit $N$ identical wrapper bundles (spec-*.js and .js.map) and Karma to load $N$ <script type="module"> tags in the browser, where the first script executes all specs in the suite and the remaining $N - 1$ scripts are no-ops.
3. Loss of per-spec isolation and incomplete fix: Combining all specs into a single virtual entry point removes per-spec module evaluation isolation (a top-level error in one spec prevents subsequent specs from registering), and the same esbuild chunk-splitting initialization order issue can still occur between test_main and angular:karma-specs.

Given that Karma is deprecated in favor of @angular/build:unit-test, we do not plan to restructure the Karma builder's entry-point bundling around a single virtual module.

[nagahara-naoki]

Thanks for taking the time to review this and explain the trade-offs! I appreciate you pointing out the impact on custom test setups and per-spec isolation. I understand the decision to close the PR given Karma’s deprecation.