You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
unit-test builder (Vitest): key fsModuleCache on the served build output instead of forcing it off #34443
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 f0a74e8 (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
In a project using @angular/build:unit-test with Vitest 5, set fsModuleCache: true and fsModuleCachePath: './.vitest-cache' in the runnerConfig.
Run ng test --no-watch.
No .vitest-cache directory is created: the builder overrides the option.
Activity