Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

unit-test builder (Vitest): key `fsModuleCache` on the served build output instead of forcing it off

Đã đóng
  • Có gì không ổn?
#34,443 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@jv3n đang làm issue này rồi.

Từ ngày 20/10/2026.

  • #34444 của @jv3n — đang mở

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
20/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
angular, typescript
Lĩnh vực
build-system, testing

Hướng nghiên cứu

Start in the angular:test-in-memory-provider plugin’s configureVitest hook and inspect how buildResultFiles are served and hashed. Check the unit-test builder configuration that forces fsModuleCache off, then trace how the cache key can include the served output and source map hashes. Done means the cache can be enabled without stale results when an imported file changes; the issue reports a fix-ready linked pull request, #34444.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

area: @angular/build
Command

test

Is this a regression?
  • Yes, this behavior used to work in the previous version
The previous version in which this bug was not present was

No response

Description

Since f0a74e8f0 (released in 22.2.3), @angular/build:unit-test forces fsModuleCache: false, at the root and on the test project, overriding the runnerConfig. The reason is sound: Vitest keys its file system module cache on the file found on disk, while a test entry point is served from its bundle, which also holds the application code the spec imports. Changing an imported file without touching the spec left the key unchanged, and the cache served a stale bundle.

Vitest provides a hook for exactly this case: a plugin can add its own part to the cache key with defineCacheKeyGenerator, from configureVitest. The angular:test-in-memory-provider plugin already implements configureVitest and holds buildResultFiles, the files its load() serves, each with a content hash. Keying the cache on the served build output (the output file hash plus its source map hash) removes the staleness at its root, so the cache does not need to be turned off.

Since #34337 (also in 22.2.3) the test bundles are byte-identical from one build to the next, so such a key is stable and the cache can be reused across runs and CI pipelines.

Measured on a workspace application with 255 spec files (warm Angular cache, macOS, runs alternated on an idle machine), the builder patched as described:

builder Vitest duration ng test wall time
22.2.3 (cache forced off) 21.4 s, 21.4 s 36.6 s, 37.9 s
patched, warm fsModuleCache 20.0 s, 18.4 s 35.8 s, 35.8 s

The gain is modest here, since execution dominates this suite; it grows with the share of transform time. On the same workspace, changing a file imported by a spec (without touching the spec) makes that spec fail as expected, and reverting the change reuses the original cache entry.

I have a fix ready and will open a PR referencing this issue.

Minimal Reproduction
  1. In a project using @angular/build:unit-test with Vitest 5, set fsModuleCache: true and fsModuleCachePath: './.vitest-cache' in the runnerConfig.
  2. Run ng test --no-watch.
  3. No .vitest-cache directory is created: the builder overrides the option.
Exception or Error

No response

Your Environment
Angular CLI       : 22.2.3
Angular           : 22.2.3
Node.js           : 24.21.0
Package Manager   : npm 11.19.0
Operating System  : darwin arm64

@angular/build    : 22.2.3
vitest            : 5.0.4
Anything else relevant?

Follow-up of #34335 / #34337 (deterministic test discovery) and of f0a74e8f0 (fsModuleCache disabled to avoid stale bundles).

Ngôn ngữ chính
TypeScript
Star
27k
Fork
11.8k
Merge trung bình
1 ngày 5 giờ
Pull request đã merge (30 ngày)
240

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của angular/angular-cli

Tất cả issue của angular/angular-cli

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.