Vitest integration lacks programmatic API for IDEs and advanced tooling

[Andreas02-dev]

Command

test

Description

Angular CLI’s current Vitest integration does not expose a supported programmatic integration surface for external tooling.

For advanced tooling such as mutation testing (StrykerJS) and IDE integrations, two capabilities are required, both of which are currently blocked:

1. The ability to override or extend the Vitest configuration at runtime.
   This is needed to run Vitest in a mutation-testing mode, for example to change includes/excludes, disable threading, adjust environments, add setup files, or tweak dependency handling.

2. Access to the Vitest instance itself, so external tools can use Vitest APIs such as the provide API for mutant switching (injecting or replacing values during test execution).
   Vitest provide API documentation: https://main.vitest.dev/api/advanced/vitest.html#provide

At the moment, Angular CLI fully encapsulates Vitest creation and configuration. As a result, external tools cannot integrate without re-implementing Angular CLI internals.

This issue is not limited to StrykerJS. Other tools in the ecosystem are running into the same limitation:

• The Vitest VS Code extension cannot detect or execute tests in Angular projects using the CLI Vitest setup:
  Vitest plugin doesn't work with Angular v21 project vitest-dev/vscode#686
• IDE and external tooling compatibility issues around Vitest are already being tracked by the Angular CLI team:
  Add support for Vitest VSCode Plugin and similar #31734

We’d also like to thank the Angular team for the long-standing collaboration with the tooling ecosystem, and with StrykerJS in particular. Changes in Angular CLI over the years made it possible for tools like StrykerJS to support Angular with Karma reliably for a long time, and we really appreciate that effort. We hope we can work something out together again so the new Vitest-based architecture remains just as extensible and ecosystem-friendly.

Describe the solution you'd like

We would like Angular CLI to expose a stable, supported API for its Vitest integration that external tools can build upon.

Concretely, this would include:

1. Runtime Vitest config overrides before instance creation
   External tooling should be able to provide or merge Vitest configuration before the Vitest instance is created. This is required for use cases like mutation testing, where tools need to adjust runner-level behavior such as threading, test selection, setup files, or environment options.

2. Access to the actual Vitest instance
   External tools need access to the real Vitest instance so they can:

   • Use the Vitest provide API for mutant switching and other runtime injections
   • Control test execution (for example related tests, name pattern filtering, or repeated runs)
   • Reset or manage internal state between runs in a supported way

3. An exported helper function, for example buildAndCreateVitest(...)

   This helper would:

   • Perform the Angular build
   • Load the compiled files into memory
   • Create and return the configured Vitest instance

   It should also:

   • Allow pre-create Vitest config overrides
   • Work when invoked from an external tool’s execution context (such as a sandbox directory with modified or mutated files)
   • Return the underlying, mutable Vitest instance, not just a “run tests” abstraction

   Tools like StrykerJS could then call this function from their Vitest test runner instead of duplicating Angular CLI internals or relying on fragile workarounds.

Providing this kind of integration point would significantly improve compatibility with IDE plugins, mutation testing tools, and other advanced testing or analysis tooling, while keeping Angular CLI as the single source of truth for how Vitest is configured and executed in Angular projects.

Describe alternatives you've considered

• Using Analog’s Vitest integration, which exposes a more standard and tool-friendly Vitest setup:
  https://analogjs.org/docs/features/testing/vitest

  While this can work as a workaround, it is not a good long-term solution for Angular CLI users. It requires manual configuration by the user, is not officially supported by Angular CLI, and does not provide an out-of-the-box Angular experience. As a result, tooling would only work for users who opt into a specific non-CLI setup, rather than working by default for Angular projects.

• Custom scripts that build Angular separately and invoke Vitest outside Angular CLI.
  These approaches are brittle, bypass CLI guarantees, duplicate Angular internals, and are difficult to maintain over time.

Ultimately, both alternatives shift complexity to end users or tooling authors and fragment the ecosystem. A supported integration point in Angular CLI would allow tools to work out of the box for Angular projects.