Migration Guide
Migrating to Vitest 2.0
Default Pool is forks
Vitest 2.0 changes the default configuration for pool to 'forks' for better stability. You can read the full motivation in PR.
If you've used poolOptions without specifying a pool, you might need to update the configuration:
export default defineConfig({
test: {
poolOptions: {
threads: {
singleThread: true,
},
forks: {
singleFork: true,
},
}
}
})Hooks are Running in a Stack
Before Vitest 2.0, all hooks ran in parallel. In 2.0, all hooks run serially. Additionally, afterAll/afterEach hooks run in reverse order.
To revert to the parallel execution of hooks, change sequence.hooks to 'parallel':
export default defineConfig({
test: {
sequence: {
hooks: 'parallel',
},
},
})suite.concurrent Runs All Tests Concurrently
Previously, specifying concurrent on a suite would group concurrent tests by suites, running them sequentially. Now, following Jest's behavior, all tests run concurrently (subject to maxConcurrency limits).
V8 Coverage's coverage.ignoreEmptyLines is Enabled by Default
The default value of coverage.ignoreEmptyLines is now true. This significant change may affect code coverage reports, requiring adjustments to coverage thresholds for some projects. This adjustment only affects the default setting when coverage.provider is 'v8'.
Removal of the watchExclude Option
Vitest uses Vite's watcher. Exclude files or directories by adding them to server.watch.ignored:
export default defineConfig({
server: {
watch: {
ignored: ['!node_modules/examplejs']
}
}
})--segfault-retry Removed
With the changes to default pool, this option is no longer needed. If you experience segfault errors, try switching to 'forks' pool. If the problem persists, please open a new issue with a reproduction.
Empty Task In Suite Tasks Removed
This is the change to the advanced task API. Previously, traversing .suite would eventually lead to the empty internal suite that was used instead of a file task.
This makes .suite optional; if the task is defined at the top level, it will not have a suite. You can fallback to the .file property that is now present on all tasks (including the file task itself, so be careful not to fall into the endless recursion).
This change also removes the file from expect.getState().currentTestName and makes expect.getState().testPath required.
task.meta is Added to the JSON Reporter
JSON reporter now prints task.meta for every assertion result.
Simplified Generic Types of Mock Functions (e.g. vi.fn<T>, Mock<T>)
Previously vi.fn<TArgs, TReturn> accepted two generic types separately for arguments and return value. This is changed to directly accept a function type vi.fn<T> to simplify the usage.
import { type Mock, vi } from 'vitest'
const add = (x: number, y: number): number => x + y
// using vi.fn<T>
const mockAdd = vi.fn<Parameters<typeof add>, ReturnType<typeof add>>()
const mockAdd = vi.fn<typeof add>()
// using Mock<T>
const mockAdd: Mock<Parameters<typeof add>, ReturnType<typeof add>> = vi.fn()
const mockAdd: Mock<typeof add> = vi.fn() Accessing Resolved mock.results
Previously Vitest resolved mock.results values if the function returned a Promise. Now there is a separate mock.settledResults property that populates only when the returned Promise is resolved or rejected.
const fn = vi.fn().mockResolvedValueOnce('result')
await fn()
const result = fn.mock.results[0] // 'result'
const result = fn.mock.results[0] // 'Promise<result>'
const settledResult = fn.mock.settledResults[0] // 'result'With this change, we also introduce new toHaveResolved* matchers similar to toHaveReturned to make migration easier if you used toHaveReturned before:
const fn = vi.fn().mockResolvedValueOnce('result')
await fn()
expect(fn).toHaveReturned('result')
expect(fn).toHaveResolved('result') Browser Mode
Vitest Browser Mode had a lot of changes during the beta cycle. You can read about our philosophy on the Browser Mode in the GitHub discussion page.
Most of the changes were additive, but there were some small breaking changes:
noneprovider was renamed topreview#5842previewprovider is now a default #5842indexScriptsis renamed toorchestratorScripts#5842
Deprecated Options Removed
Some deprecated options were removed:
vitest typecheckcommand - usevitest --typecheckinsteadVITEST_JUNIT_CLASSNAMEandVITEST_JUNIT_SUITE_NAMEenv variables (use reporter options instead)- check for
c8coverage (use coverage-v8 instead) - export of
SnapshotEnvironmentfromvitest- import it fromvitest/snapshotinstead SpyInstanceis removed in favor ofMockInstance
Migrating to Vitest 1.0
Minimum Requirements
Vitest 1.0 requires Vite 5.0 and Node.js 18 or higher.
All @vitest/* sub packages require Vitest version 1.0.
Snapshots Update #3961
Quotes in snapshots are no longer escaped, and all snapshots use backtick quotes (`) even if the string is just a single line.
- Quotes are no longer escaped:
expect({ foo: 'bar' }).toMatchInlineSnapshot(`
Object {
- \\"foo\\": \\"bar\\",
+ "foo": "bar",
}
`)- One-line snapshots now use "`" quotes instead of ':
- expect('some string').toMatchInlineSnapshot('"some string"')
+ expect('some string').toMatchInlineSnapshot(`"some string"`)There were also changes to @vitest/snapshot package. If you are not using it directly, you don't need to change anything.
- You no longer need to extend
SnapshotClientjust to overrideequalityCheckmethod: just pass it down asisEqualwhen initiating an instance client.setTestwas renamed toclient.startCurrentRunclient.resetCurrentwas renamed toclient.finishCurrentRun
Pools are Standardized #4172
We removed a lot of configuration options to make it easier to configure the runner to your needs. Please, have a look at migration examples if you rely on --threads or other related flags.
--threadsis now--pool=threads--no-threadsis now--pool=forks--single-threadis now--poolOptions.threads.singleThread--experimental-vm-threadsis now--pool=vmThreads--experimental-vm-worker-memory-limitis now--poolOptions.vmThreads.memoryLimit--isolateis now--poolOptions.<pool-name>.isolateandbrowser.isolatetest.maxThreadsis nowtest.poolOptions.<pool-name>.maxThreadstest.minThreadsis nowtest.poolOptions.<pool-name>.minThreadstest.useAtomicsis nowtest.poolOptions.<pool-name>.useAtomicstest.poolMatchGlobs.child_processis nowtest.poolMatchGlobs.forkstest.poolMatchGlobs.experimentalVmThreadsis nowtest.poolMatchGlobs.vmThreads
{
scripts: {
- "test": "vitest --no-threads"
// For identical behaviour:
+ "test": "vitest --pool forks --poolOptions.forks.singleFork"
// Or multi parallel forks:
+ "test": "vitest --pool forks"
}
}{
scripts: {
- "test": "vitest --experimental-vm-threads"
+ "test": "vitest --pool vmThreads"
}
}{
scripts: {
- "test": "vitest --isolate false"
+ "test": "vitest --poolOptions.threads.isolate false"
}
}{
scripts: {
- "test": "vitest --no-threads --isolate false"
+ "test": "vitest --pool forks --poolOptions.forks.isolate false"
}
}Changes to Coverage #4265, #4442
Option coverage.all is now enabled by default. This means that all project files matching coverage.include pattern will be processed even if they are not executed.
Coverage thresholds API's shape was changed, and it now supports specifying thresholds for specific files using glob patterns:
export default defineConfig({
test: {
coverage: {
- perFile: true,
- thresholdAutoUpdate: true,
- 100: true,
- lines: 100,
- functions: 100,
- branches: 100,
- statements: 100,
+ thresholds: {
+ perFile: true,
+ autoUpdate: true,
+ 100: true,
+ lines: 100,
+ functions: 100,
+ branches: 100,
+ statements: 100,
+ }
}
}
})Mock Types #4400
A few types were removed in favor of Jest-style "Mock" naming.
- import { EnhancedSpy, SpyInstance } from 'vitest'
+ import { MockInstance } from 'vitest'WARNING
SpyInstance is deprecated in favor of MockInstance and will be removed in the next major release.
Timer mocks #3925
vi.useFakeTimers() no longer automatically mocks process.nextTick. It is still possible to mock process.nextTick by explicitly specifying it by using vi.useFakeTimers({ toFake: ['nextTick'] }).
However, mocking process.nextTick is not possible when using --pool=forks. Use a different --pool option if you need process.nextTick mocking.
Migrating from Jest
Vitest has been designed with a Jest compatible API, in order to make the migration from Jest as simple as possible. Despite those efforts, you may still run into the following differences:
Globals as a Default
Jest has their globals API enabled by default. Vitest does not. You can either enable globals via the globals configuration setting or update your code to use imports from the vitest module instead.
If you decide to keep globals disabled, be aware that common libraries like testing-library will not run auto DOM cleanup.
Module Mocks
When mocking a module in Jest, the factory argument's return value is the default export. In Vitest, the factory argument has to return an object with each export explicitly defined. For example, the following jest.mock would have to be updated as follows:
jest.mock('./some-path', () => 'hello')
vi.mock('./some-path', () => ({
default: 'hello',
})) For more details please refer to the vi.mock api section.
Auto-Mocking Behaviour
Unlike Jest, mocked modules in <root>/__mocks__ are not loaded unless vi.mock() is called. If you need them to be mocked in every test, like in Jest, you can mock them inside setupFiles.
Importing the Original of a Mocked Package
If you are only partially mocking a package, you might have previously used Jest's function requireActual. In Vitest, you should replace these calls with vi.importActual.
const { cloneDeep } = jest.requireActual('lodash/cloneDeep')
const { cloneDeep } = await vi.importActual('lodash/cloneDeep') Extends mocking to external libraries
Where Jest does it by default, when mocking a module and wanting this mocking to be extended to other external libraries that use the same module, you should explicitly tell which 3rd-party library you want to be mocked, so the external library would be part of your source code, by using server.deps.inline.
server.deps.inline: ["lib-name"]expect.getState().currentTestName
Vitest's test names are joined with a > symbol to make it easier to distinguish tests from suites, while Jest uses an empty space ().
- `${describeTitle} ${testTitle}`
+ `${describeTitle} > ${testTitle}`Envs
Just like Jest, Vitest sets NODE_ENV to test, if it wasn't set before. Vitest also has a counterpart for JEST_WORKER_ID called VITEST_POOL_ID (always less than or equal to maxThreads), so if you rely on it, don't forget to rename it. Vitest also exposes VITEST_WORKER_ID which is a unique ID of a running worker - this number is not affected by maxThreads, and will increase with each created worker.
Replace property
If you want to modify the object, you will use replaceProperty API in Jest, you can use vi.stubEnv or vi.spyOn to do the same also in Vitest.
Done Callback
From Vitest v0.10.0, the callback style of declaring tests is deprecated. You can rewrite them to use async/await functions, or use Promise to mimic the callback style.
it('should work', (done) => {
it('should work', () => new Promise(done => {
// ...
done()
})
}))Hooks
beforeAll/beforeEach hooks may return teardown function in Vitest. Because of that you may need to rewrite your hooks declarations, if they return something other than undefined or null:
beforeEach(() => setActivePinia(createTestingPinia()))
beforeEach(() => { setActivePinia(createTestingPinia()) }) In Jest hooks are called sequentially (one after another). By default, Vitest runs hooks in parallel. To use Jest's behavior, update sequence.hooks option:
export default defineConfig({
test: {
sequence: {
hooks: 'list',
}
}
})Types
Vitest doesn't have an equivalent to jest namespace, so you will need to import types directly from vitest:
let fn: jest.Mock<(name: string) => number>
import type { Mock } from 'vitest'
let fn: Mock<(name: string) => number> Timers
Vitest doesn't support Jest's legacy timers.
Timeout
If you used jest.setTimeout, you would need to migrate to vi.setConfig:
jest.setTimeout(5_000)
vi.setConfig({ testTimeout: 5_000 }) Vue Snapshots
This is not a Jest-specific feature, but if you previously were using Jest with vue-cli preset, you will need to install jest-serializer-vue package, and use it inside setupFiles:
import { defineConfig } from 'vite'
export default defineConfig({
test: {
setupFiles: ['./tests/unit/setup.js']
}
})import vueSnapshotSerializer from 'jest-serializer-vue'
expect.addSnapshotSerializer(vueSnapshotSerializer)Otherwise your snapshots will have a lot of escaped " characters.