Vitest 2.0: Test Pool Configuration for Repeatable Development Environments

Goal

Develop a stable, repeatable testing workflow in Vitest 2.0 where each test file runs with a clean module cache and isolated global state, while keeping startup time and memory usage within acceptable limits.

Constraints & Uncertainty

The default pool is threads, which shares the Node.js module cache within a worker but does not automatically reset require.cache or global singletons between test files. The forks pool provides full process isolation but incurs higher memory overhead and slower startup. The experimental --isolate flag offers cache invalidation but is not yet stable, and its interaction with native addons and global timers is unclear. There is no documented automatic reset mechanism for module cache in the threads pool, and users must manually invoke vi.resetModules() or provide custom globalSetup/teardown logic.

Unresolved Questions

1. What is the recommended configuration to guarantee module cache isolation across test files when using the threads pool in Vitest 2.0?
2. Does Vitest provide a built‑in mechanism (e.g., a flag or lifecycle hook) to reset require.cache automatically between test files in the threads pool?
3. How can one balance the trade‑offs between process isolation (forks) and startup performance (threads) while ensuring that native addons and global timers do not leak across test files?