Vitest 4 Coverage Remapping Default Change — when and how should I migrate?

Test owners need to decide how to recalibrate coverage budgets and CI thresholds after Vitest 4 changed V8 remapping behavior and removed prior compatibility flags.

Stay on Vitest 4 V8 coverage and re-baseline now if you run on Node/Chromium and can set `coverage.include`; switch to Istanbul only when runtime support demands it.

Blockers

Who this is for

Candidates

Stay on Vitest 4 V8 coverage and re-baseline with explicit include rules

As of 2026-04-08, Vitest 4 uses the V8 coverage provider by default and its V8 remapping now uses the AST-based method that Vitest introduced in v3.2.0. Vitest says this remapping is more accurate and produces reports equivalent to Istanbul, but teams should expect coverage numbers to change versus older Vitest v3 setups. Vitest 4 also removed `coverage.experimentalAstAwareRemapping`, so the old remapping path is no longer supported. Separately, Vitest 4 removed `coverage.all` and now defaults to reporting only files loaded during the test run unless `coverage.include` is set.

When to choose

Use this when you run on Node or Chromium-based environments and want Vitest's default path with lower runtime overhead than Istanbul. The decisive factor is whether you can accept a one-time coverage baseline reset and are willing to define `coverage.include` explicitly so uncovered source files still count in CI.

Tradeoffs

Fast default path and no pre-instrumentation, but historical coverage trends may shift because remapping is more accurate and because Vitest 4 no longer includes all matching files by default. If you forget to set `coverage.include`, global percentages can rise artificially because only loaded files are counted.

Cautions

Vitest 4 requires Node.js >= 20.0.0 and Vite >= 6.0.0. The V8 provider does not work on non-V8 runtimes such as Bun or Firefox, and Vitest docs note it also does not work in environments like Cloudflare Workers that do not expose V8 coverage via a profiler.

Sources

Switch to Istanbul coverage for threshold continuity across runtimes

As of 2026-04-08, Vitest 4 still supports `istanbul` as an optional coverage provider via `@vitest/coverage-istanbul`. Vitest documents Istanbul as runtime-agnostic because it instruments source files instead of depending on V8 profiler coverage, so it works on any JavaScript runtime. Vitest also states that the newer V8 remapping is now as accurate as Istanbul, which means the main reason to choose Istanbul in Vitest 4 is runtime compatibility or collection behavior rather than report correctness. Istanbul can also be faster in some cases because instrumentation can be limited to specific files, unlike V8 where all modules are instrumented.

When to choose

Use this when your test matrix includes non-V8 runtimes or environments where V8 coverage is unsupported, or when you want instrumentation-based collection behavior you can scope more tightly. The decisive factor is environment compatibility rather than raw default performance.

Tradeoffs

Broader runtime support and more predictable compatibility, but it requires pre-instrumentation, increases execution overhead, and uses more memory than V8 according to Vitest docs.

Cautions

Switching providers is still a coverage-system change, so thresholds should be re-checked before reusing old CI gates. If your main issue is Vitest 4 no longer counting unloaded files, switching to Istanbul alone does not solve that; you still need explicit `coverage.include` patterns.

Sources

Facts updated: 2026-04-08
Published: 2026-04-09

Related questions

Try with your AI agent

$ npm install -g pocketlantern
$ pocketlantern init
# Restart Claude Code, Cursor, or your MCP client, then ask:
# "Vitest 4 Coverage Remapping Default Change — when and how should I migrate?"
Missing something? Request coverage