When you leave testing to an AI coding agent, running all tests after every fix versus running only the related ones makes a big difference in wait time on large projects. Vitest has long had --changed, which narrows the targets using the Git diff. However, it has weaknesses: the diff becomes empty if the agent commits partway through, and it cannot be used in a working directory without Git.
Vitest 5.1, released on November 2, 2026, adds --since-last-run for this use case. In this article, after checking the official release post and guide, we actually ran Vitest 5.1.0 in the editorial team's working environment (a container) and summarize which tests were selected and where it misses things.
How --since-last-run works
According to the official release post and the guide "Running Only Affected Tests," it behaves as follows.
- The first run executes all tests. During that run, it records the files each test loaded (including dynamic imports, mocks, setup files and snapshots)
- From the second run on, it compares modification times. If any recorded file is newer than the previous run or has been deleted, that test is run. Tests with no record (new test files, and files run in browser mode or type checking) are run every time
- Failed tests are run every time until they pass. Even if the fix is in a file outside the record, failed test files are run again
- It does not use Git. It works the same way in new containers, temporary worktrees and directories that are not repositories
- The record is stored in the cache. If you clear it with
vitest run --clearCache, the next run covers all tests again. If the cache is disabled, you get an error
The release post describes this feature as "experimental."
What we confirmed by actually running it
On November 6, 2026, we created a small project with Vitest 5.1.0 on Node.js 22.23.4 in an Ubuntu 24.04 container. We prepared one test each for src/price.js, which calculates consumption tax, and src/date.js, which handles dates. The results were as follows.
| Operation | Tests run | Output |
|---|---|---|
| First run (no record) | 2 of 2 | Affected 2 of 2 |
| Second run with no changes | 0 incidents | No changed files found, exiting with code 0 |
Introduce an error into price.js | Only the price test (failed) | Affected 1 of 2 |
| Run again with no changes | The price test (failed) | 0 changed files, 1 previously failed |
Fix price.js | The price test (passed) | 1 changed file, 1 previously failed |
| Change a value in the JSON read with fs | 0 incidents | No changed files found, exiting with code 0 |
The last row is the result to watch most closely this time. We added a test that uses readFileSync inside the test to read fixtures/rate.json and check its values. Even after we changed a value in the JSON so that the test would fail, --since-last-run decided there were "no changes," ran nothing, and ended with exit code 0. Running vitest run (all tests) in the same state makes this test fail.
Looking at the record file (dependencies.json under node_modules/.vite/vitest/), the only dependency recorded for this test was the test file itself. The experimental.recordDependencies entry in the configuration reference also states clearly that Vitest records only the files it loads itself, and does not record files read with fs (such as fixtures).
The official guide also lists, as things the record cannot see, "files no test loaded in the previous run (new .env or __mocks__ files)" and "files given a past timestamp by a checkout or extraction," and says that running all tests at the end covers both. Our results match these explanations.
How to write it into agent instructions
The official release post shows an example of writing the following two lines in an instruction file for agents (AGENTS.md).
- After a change, run `vitest run --since-last-run` to test only what the change affects.
- Before you finish, run `vitest run` once for the whole suite.If you write only the first line, then, as in the verification above, a fix that changes data such as JSON read with fs may run no tests at all and be taken as a "success." It is safer not to omit the second line, "run all tests once before finishing." According to the configuration reference, changing Vitest's own configuration file and its imports, global setup, or .env files runs all of the project's tests (we did not try this).
It is also worth keeping the following distinctions in mind (the editorial team's suggestions).
- Do not use it in CI. In CI, what matters is getting "the same result no matter who runs it." The official guide also says
--changedis the better fit if you share the baseline with others, and names--changed origin/mainfor checking pull requests. If you use--since-last-runin CI that carries over its cache, the number of tests run can be 0 depending on the previous record - Consider loading test data with import. According to the official explanation, imported modules are recorded. If you read JSON with
import, it should presumably be recorded (we did not try this)
The official repository also has user reports about 5.1.0, some of them unresolved (as of November 6, 2026; we did not try either one). #11863 reports that tests that load a module reading import.meta.hot in a DOM environment are rerun every time even with no changes, with Vue component tests given as an example. #11864 reports that the vitest run --since-last-run <ファイル> file setting is ignored.
We also covered ways to have AI agents read test results in our article on the AI Agent Reporter in Vitest 4.1.
--last-failed and other easy-to-miss changes
--last-failed is a flag that runs only the tests that failed in the previous run. When we ran it after introducing an error into price.js in the verification above, it showed "Last Failed 1 of 2 test files" and ran only the one that failed. Because it selects by test name, the release post explains, adding or moving other tests does not change what is selected. According to the CLI reference, a renamed test is not selected until you run without the flag, and when there are no previous failures it shows No failed tests found and ends with exit code 1 (when --passWithNoTests is not specified).
Projects that use browser mode also need to watch for the following changes.
- The default port changed from 63315 to 23315. This is because on Windows running Hyper-V, WSL2 or Docker Desktop, the old port was sometimes reserved and startup failed. If your firewall or container settings assume the old port, specify
api.port - The mocking mechanism changed to import maps (experimental,
browser.importMapMocks). In supported browsers (Chromium 133 or later, Safari 18.4 or later, and Firefox 150 or later with the Playwright provider), if a module was loaded before being registered withvi.mock, you get an error instead of the original module being used silently. If this causes problems, you can revert withbrowser.importMapMocks: false. Other browsers, and setups withisolatedisabled, work with the same mechanism as before - Trace view is now enabled by default only on failure.
browser.traceView.enabledis deprecated and replaced bybrowser.traceView.mode
For the Vitest version included in Vite+ 1.0, see our article on Vite+ 1.0.
Scope of verification
On November 6, 2026, we checked the official blog on vitest.dev (dated November 2, 2026), the guide, the CLI and configuration references, and the v5.1.0 release on GitHub, and confirmed in the npm registry the publication time of 5.1.0 (2026-11-02T16:12:37Z) and that it is the latest version. We verified it in an Ubuntu 24.04 container with Node.js 22.23.4 and Vitest 5.1.0 on a small project with three test files, running each operation once (hands-on testing). We did not try the reduction in run time on large projects, browser mode, the port change on Windows, or the contents of the two issues mentioned above.
GleamHub's development, AI and automation consultations cover test automation and how to build AI agents into your development workflow. The approach varies with the size of the project and how your CI is set up, so please get in touch through the contact form.
References
- Vitest — Vitest 5.1 is out!
- Vitest — Running Only Affected Tests
- Vitest — experimental.recordDependencies
- Vitest — CLI（
--since-last-run） - Vitest — browser.importMapMocks
- vitest-dev/vitest — docs/blog/vitest-5-1.md
- GitHub — vitest v5.1.0 release
- npm registry — vitest
- vitest-dev/vitest — issue #11863
- vitest-dev/vitest — issue #11864
