Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

Vitest integration lacks programmatic API for IDEs and advanced tooling

未關閉
#32,182 1 則留言 93 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

評估

難度
5/5
預估耗時
一週以上
新手友好度
35/100
Issue 類型
功能
描述清晰度
基本清楚
活躍度
停滯
技術堆疊
angular, typescript
領域
cli, testing, tooling

研究方向

未指定檔案或測試。首先定位 Angular CLI 的 Vitest 整合,以及建置、設定和建立 Vitest 執行個體的程式碼;查看相關 issue 連結以了解現有的上下文。當一個受支援的外部進入點能夠提供建立前的設定覆寫,並且能夠存取底層 Vitest 執行個體,而不需要重複 CLI 內部實作時,即表示完成。

由索引模型根據 Issue 內容生成。

描述

angular/build:unit-test area: @angular/build feature feature: under consideration
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:

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.

主要語言
TypeScript
星號
27k
分支
11.8k
平均合併
17 小時 21 分鐘
30 天內合併 PR
181

貢獻指南

開啟貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

angular/angular-cli 的其他 Issue

查看 angular/angular-cli 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。