2,086 passing tests still produced a failing run
Our checkout ran 2,086 tests successfully, yet one failure made the command exit 1. That result fits Vitest's position better than a spotless marketing line would. This is a mature, heavily tested framework with a wide surface: assertions, mocks, snapshots, coverage, workspaces, watch mode, type tests, benchmarks, a UI, and real-browser component testing. A single edge failure does not erase that breadth, but a test runner should be judged strictly about its own test result.
Vitest is easiest to recommend inside a Vite application. It reads the same resolver, transformers, aliases, and plugins instead of asking a team to maintain a second compilation path for tests. Jest-compatible assertions and mocking lower migration cost. The compatibility has boundaries, and the project documents them plainly. Teams outside Vite can still use it, though the shared configuration advantage becomes smaller.
The 1,706-package source install is contributor-sized
Our clean pnpm install added 1,706 packages in 52 seconds and occupied 789 MB. The monorepo build then finished in 22 seconds. Those figures describe work on Vitest itself, not the footprint of adding the published vitest package to an application. They matter to contributors, CI image owners, and anyone evaluating a source fork. The repository held 3,127 files and about 211,733 lines of source before dependencies.
The project uses pnpm workspaces and splits the runner, assertions, coverage providers, Browser Mode, UI, and test fixtures across packages. Its contribution guide tells developers to build all packages before using watch development, then choose the core test command or the wider CI suite. That structure is reasonable for a framework serving several runtimes. It also explains why a source checkout costs much more disk than the one package most users install.
What happened when we ran it
Our run at commit 9614b80 installed 1,706 packages in 52 seconds and used 789 MB. The build succeeded in 22 seconds. The test step failed with exit code 1 after 44 seconds. Its summary reported 2,086 passed, 1 failed, 21 expected failures, 75 skipped, and 25 todo. It also reported 216 passing test files and 1 failing file out of 217.
The log tail identifies test/edge.test.ts as the failing file, with 1 failure among its 3 tests. It does not show the assertion or enough surrounding output to establish a cause, so we will not assign one. The same checkout had 13 CI workflow files, a tests directory, and monorepo workspaces. It had no Dockerfile. The repository was 34.4 MB checked out before the successful install.
Vitest 5 requires Node 22.12 and Vite 6.4
Version 5 raises the supported floor to Node.js 22.12 and Vite 6.4. The migration guide also changes behavior that can alter passing suites: clearMocks is enabled by default, inline projects inherit root configuration, shared Vite servers are enabled in eligible projects, nested hoisted mocks now throw, and unawaited asynchronous assertions fail. Those are defensible defaults. They still make a major upgrade a test migration rather than a package-number edit.
Jest compatibility also stops short of identity. Vitest does not enable globals by default, resets mock implementations differently, uses explicit export objects in module-mock factories, runs hooks with different default sequencing, and does not support legacy timers or callback-style tests. The guide gives replacements for each case. A large Jest suite should migrate in a branch and compare failures by category instead of assuming the first run measures application defects.
346 open issues include fresh v5 regressions
GitHub listed 346 open issues and 83 open pull requests on September 17, 2026. Two reports filed around v5.0.1 are worth checking before an upgrade. Issue 11298 reproduces a stack overflow when spying on Set.prototype.add. Issue 11296 reports several matchers treating unequal Maps or Sets as equal. Both reports include small reproductions, and an open fix for the Set recursion was already linked that day.
The repository was pushed on September 17 and had 17,129 stars. Release v5.0.1 arrived on September 15 with fixes across collection, automocking, fake timers, browser behavior, snapshots, types, and the UI. That pace shows maintainers responding to a newly shipped major version. It also argues for pinning the exact patch used in CI, especially during the first weeks of a new major line.
Browser Mode needs a real provider in CI
Browser Mode can run component tests through Chromium, Firefox, or WebKit, but the CI path requires Playwright or WebdriverIO. The documentation says the preview provider simulates events and recommends Playwright when teams do not already use either provider. Headless mode also depends on one of those integrations. This is useful consolidation for component tests, though it adds browser downloads and provider configuration beyond the base Vitest install.
Large browser workspaces should budget memory. Open issue 10990 describes one suite with 21 projects and 2 workers retaining 42 Chromium pages until the full run ended. The reporter measured about 12.8 GB at peak and documented a manual split as the working workaround. That is one user's reproduction, not a general Vitest benchmark. It is specific enough to test if your workspace runs many browser projects concurrently.
v5.0.1 is the right default for supported Vite apps
For a Vite application already on Node 22.12 or newer, Vitest v5.0.1 remains the first runner we would try. Its shared transform path removes a recurring source of test-only configuration, and the API covers the daily work without assembling separate assertion, mocking, snapshot, and coverage layers. The 44-second lab run shows a large core suite getting almost all the way through on 3 CPUs and 8 GB of RAM.
Adopt it with less ceremony than the 789 MB contributor checkout suggests, but keep the decision disciplined. Read the v5 migration changes, pin the patch, run the full application suite, and add Playwright when Browser Mode reaches CI. Our one failing edge test prevents a clean lab endorsement. The active release and issue response still make Vitest easier to trust than an unmaintained green badge.