Configuring Vitest

If you are using Vite and have a vite.config file, Vitest will read it to match with the plugins and setup as your Vite app. If you want to have a different configuration for testing or your main app doesn't rely on Vite specifically, you could either:

Create vitest.config.ts, which will have the higher priority and will override the configuration from vite.config.ts (Vitest supports all conventional JS and TS extensions, but doesn't support json) - it means all options in your vite.config will be ignored
Pass --config option to CLI, e.g. vitest --config ./path/to/vitest.config.ts
Use process.env.VITEST or mode property on defineConfig (will be set to test/benchmark if not overridden with --mode) to conditionally apply different configuration in vite.config.ts

To configure vitest itself, add test property in your Vite config. You'll also need to add a reference to Vitest types using a triple slash command at the top of your config file, if you are importing defineConfig from vite itself.

Open Config Examples

Using defineConfig from vite you should follow this:

vite.config.js

/// <reference types="vitest" />
import { defineConfig } from 'vite'

export default defineConfig({
  test: {
    // ... Specify options here.
  },
})

The <reference types="vitest" /> will stop working in Vitest 4, but you can already start migrating to vitest/config:

vite.config.js

/// <reference types="vitest/config" />
import { defineConfig } from 'vite'

export default defineConfig({
  test: {
    // ... Specify options here.
  },
})

Using defineConfig from vitest/config you should follow this:

vitest.config.js

import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    // ... Specify options here.
  },
})

You can retrieve Vitest's default options to expand them if needed:

vitest.config.js

import { configDefaults, defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    exclude: [...configDefaults.exclude, 'packages/template/*'],
  },
})

When using a separate vitest.config.js, you can also extend Vite's options from another config file if needed:

vitest.config.js

import { defineConfig, mergeConfig } from 'vitest/config'
import viteConfig from './vite.config'

export default mergeConfig(viteConfig, defineConfig({
  test: {
    exclude: ['packages/template/*'],
  },
}))

If your Vite config is defined as a function, you can define the config like this:

vitest.config.js

import { defineConfig, mergeConfig } from 'vitest/config'
import viteConfig from './vite.config'

export default defineConfig(configEnv => mergeConfig(
  viteConfig(configEnv),
  defineConfig({
    test: {
      exclude: ['packages/template/*'],
    },
  })
))

WARNING

All listed options on this page are located within a test property inside the configuration:

vitest.config.js

export default defineConfig({
  test: {
    exclude: [],
  },
})

Since Vitest uses Vite config, you can also use any configuration option from Vite. For example, define to define global variables, or resolve.alias to define aliases - these options should be defined on the top level, not within a test property.

Configuration options that are not supported inside a project config have * sign next to them. This means they can only be set in the root Vitest config.

include

Type: string[]
Default: ['**/*.{test,spec}.?(c|m)[jt]s?(x)']
CLI: vitest [...include], vitest **/*.test.js

A list of glob patterns that match your test files.

NOTE

When using coverage, Vitest automatically adds test files include patterns to coverage's default exclude patterns. See coverage.exclude.

exclude

Type: string[]
Default: ['**/node_modules/**', '**/dist/**', '**/cypress/**', '**/.{idea,git,cache,output,temp}/**', '**/{karma,rollup,webpack,vite,vitest,jest,ava,babel,nyc,cypress,tsup,build,eslint,prettier}.config.*']
CLI: vitest --exclude "**/excluded-file"

A list of glob patterns that should be excluded from your test files.

WARNING

This option does not affect coverage. If you need to remove certain files from the coverage report, use coverage.exclude.

This is the only option that doesn't override your configuration if you provide it with a CLI flag. All glob patterns added via --exclude flag will be added to the config's exclude.

includeSource

Type: string[]
Default: []

Include globs for in-source test files.

When defined, Vitest will run all matched files with import.meta.vitest inside.

name

Type: string | { label: string, color?: LabelColor }

Assign a custom name to the test project or Vitest process. The name will be visible in the CLI and UI, and available in the Node.js API via project.name.

Color used by CLI and UI can be changed by providing an object with color property.

server

Type: { sourcemap?, deps?, ... }

Vite-Node server options.

server.sourcemap

Type: 'inline' | boolean
Default: 'inline'

Inject inline source map to modules.

server.debug

Type: { dumpModules?, loadDumppedModules? }

Vite-Node debugger options.

server.debug.dumpModules

Type: boolean | string

Dump the transformed module to filesystem. Passing a string will dump to the specified path.

server.debug.loadDumppedModules

Type: boolean

Read dumped module from filesystem whenever exists. Useful for debugging by modifying the dump result from the filesystem.

server.deps

Type: { external?, inline?, ... }

Handling for dependencies resolution.

server.deps.external

Type: (string | RegExp)[]
Default: [/\/node_modules\//]

Externalize means that Vite will bypass the package to the native Node. Externalized dependencies will not be applied to Vite's transformers and resolvers, so they do not support HMR on reload. By default, all packages inside node_modules are externalized.

These options support package names as they are written in node_modules or specified inside deps.moduleDirectories. For example, package @company/some-name located inside packages/some-name should be specified as some-name, and packages should be included in deps.moduleDirectories. Basically, Vitest always checks the file path, not the actual package name.

If regexp is used, Vitest calls it on the file path, not the package name.

server.deps.inline

Type: (string | RegExp)[] | true
Default: []

Vite will process inlined modules. This could be helpful to handle packages that ship .js in ESM format (that Node can't handle).

If true, every dependency will be inlined. All dependencies, specified in ssr.noExternal will be inlined by default.

server.deps.fallbackCJS

Type boolean
Default: false

When a dependency is a valid ESM package, try to guess the cjs version based on the path. This might be helpful, if a dependency has the wrong ESM file.

This might potentially cause some misalignment if a package has different logic in ESM and CJS mode.

server.deps.cacheDir

Type string
Default: 'node_modules/.vite'

Directory to save cache files.

deps

Type: { optimizer?, ... }

Handling for dependencies resolution.

deps.optimizer

Type: { ssr?, web? }
See also: Dep Optimization Options

Enable dependency optimization. If you have a lot of tests, this might improve their performance.

When Vitest encounters the external library listed in include, it will be bundled into a single file using esbuild and imported as a whole module. This is good for several reasons:

Importing packages with a lot of imports is expensive. By bundling them into one file we can save a lot of time
Importing UI libraries is expensive because they are not meant to run inside Node.js
Your alias configuration is now respected inside bundled packages
Code in your tests is running closer to how it's running in the browser

Be aware that only packages in deps.optimizer?.[mode].include option are bundled (some plugins populate this automatically, like Svelte). You can read more about available options in Vite docs (Vitest doesn't support disable and noDiscovery options). By default, Vitest uses optimizer.web for jsdom and happy-dom environments, and optimizer.ssr for node and edge environments, but it is configurable by transformMode.

This options also inherits your optimizeDeps configuration (for web Vitest will extend optimizeDeps, for ssr - ssr.optimizeDeps). If you redefine include/exclude option in deps.optimizer it will extend your optimizeDeps when running tests. Vitest automatically removes the same options from include, if they are listed in exclude.

TIP

You will not be able to edit your node_modules code for debugging, since the code is actually located in your cacheDir or test.cache.dir directory. If you want to debug with console.log statements, edit it directly or force rebundling with deps.optimizer?.[mode].force option.

deps.optimizer.{mode}.enabled

Type: boolean
Default: false

Enable dependency optimization.

deps.web

Type: { transformAssets?, ... }

Options that are applied to external files when transform mode is set to web. By default, jsdom and happy-dom use web mode, while node and edge environments use ssr transform mode, so these options will have no affect on files inside those environments.

Usually, files inside node_modules are externalized, but these options also affect files in server.deps.external.

deps.web.transformAssets

Type: boolean
Default: true

Should Vitest process assets (.png, .svg, .jpg, etc) files and resolve them like Vite does in the browser.

This module will have a default export equal to the path to the asset, if no query is specified.

WARNING

At the moment, this option only works with vmThreads and vmForks pools.

deps.web.transformCss

Type: boolean
Default: true

Should Vitest process CSS (.css, .scss, .sass, etc) files and resolve them like Vite does in the browser.

If CSS files are disabled with css options, this option will just silence ERR_UNKNOWN_FILE_EXTENSION errors.

WARNING

At the moment, this option only works with vmThreads and vmForks pools.

deps.web.transformGlobPattern

Type: RegExp | RegExp[]
Default: []

Regexp pattern to match external files that should be transformed.

By default, files inside node_modules are externalized and not transformed, unless it's CSS or an asset, and corresponding option is not disabled.

WARNING

At the moment, this option only works with vmThreads and vmForks pools.

deps.interopDefault

Type: boolean
Default: true

Interpret CJS module's default as named exports. Some dependencies only bundle CJS modules and don't use named exports that Node.js can statically analyze when a package is imported using import syntax instead of require. When importing such dependencies in Node environment using named exports, you will see this error:

import { read } from 'fs-jetpack';
         ^^^^
SyntaxError: Named export 'read' not found. The requested module 'fs-jetpack' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export.

Vitest doesn't do static analysis, and cannot fail before your running code, so you will most likely see this error when running tests, if this feature is disabled:

TypeError: createAsyncThunk is not a function
TypeError: default is not a function

By default, Vitest assumes you are using a bundler to bypass this and will not fail, but you can disable this behaviour manually, if you code is not processed.

deps.moduleDirectories

Type: string[]
Default: ['node_modules']

A list of directories that should be treated as module directories. This config option affects the behavior of vi.mock: when no factory is provided and the path of what you are mocking matches one of the moduleDirectories values, Vitest will try to resolve the mock by looking for a __mocks__ folder in the root of the project.

This option will also affect if a file should be treated as a module when externalizing dependencies. By default, Vitest imports external modules with native Node.js bypassing Vite transformation step.

Setting this option will override the default, if you wish to still search node_modules for packages include it along with any other options:

import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    deps: {
      moduleDirectories: ['node_modules', path.resolve('../../packages')],
    }
  },
})

runner

Type: VitestRunnerConstructor
Default: node, when running tests, or benchmark, when running benchmarks

Path to a custom test runner. This is an advanced feature and should be used with custom library runners. You can read more about it in the documentation.

benchmark

Type: { include?, exclude?, ... }

Options used when running vitest bench.

benchmark.include

Type: string[]
Default: ['**/*.{bench,benchmark}.?(c|m)[jt]s?(x)']

Include globs for benchmark test files

benchmark.exclude

Type: string[]
Default: ['node_modules', 'dist', '.idea', '.git', '.cache']

Exclude globs for benchmark test files

benchmark.includeSource

Type: string[]
Default: []

Include globs for in-source benchmark test files. This option is similar to includeSource.

When defined, Vitest will run all matched files with import.meta.vitest inside.

benchmark.reporters

Type: Arrayable<BenchmarkBuiltinReporters | Reporter>
Default: 'default'

Custom reporter for output. Can contain one or more built-in report names, reporter instances, and/or paths to custom reporters.

benchmark.outputFile

Deprecated in favor of benchmark.outputJson.

benchmark.outputJson

Type: string | undefined
Default: undefined

A file path to store the benchmark result, which can be used for --compare option later.

For example:

# save main branch's result
git checkout main
vitest bench --outputJson main.json

# change a branch and compare against main
git checkout feature
vitest bench --compare main.json

benchmark.compare

Type: string | undefined
Default: undefined

A file path to a previous benchmark result to compare against current runs.

alias

Type: Record<string, string> | Array<{ find: string | RegExp, replacement: string, customResolver?: ResolverFunction | ResolverObject }>

Define custom aliases when running inside tests. They will be merged with aliases from resolve.alias.

WARNING

Vitest uses Vite SSR primitives to run tests which has certain pitfalls.

Aliases affect only modules imported directly with an import keyword by an inlined module (all source code is inlined by default).
Vitest does not support aliasing require calls.
If you are aliasing an external dependency (e.g., react -> preact), you may want to alias the actual node_modules packages instead to make it work for externalized dependencies. Both Yarn and pnpm support aliasing via the npm: prefix.

globals

Type: boolean
Default: false
CLI: --globals, --globals=false

By default, vitest does not provide global APIs for explicitness. If you prefer to use the APIs globally like Jest, you can pass the --globals option to CLI or add globals: true in the config.

import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    globals: true,
  },
})

To get TypeScript working with the global APIs, add vitest/globals to the types field in your tsconfig.json

tsconfig.json

json

{
  "compilerOptions": {
    "types": ["vitest/globals"]
  }
}

If you have redefined your typeRoots to include more types in your compilation, you will have to add back the node_modules to make vitest/globals discoverable.

tsconfig.json

json

{
  "compilerOptions": {
    "typeRoots": ["./types", "./node_modules/@types", "./node_modules"],
    "types": ["vitest/globals"]
  }
}

If you are already using unplugin-auto-import in your project, you can also use it directly for auto importing those APIs.

vitest.config.js

import { defineConfig } from 'vitest/config'
import AutoImport from 'unplugin-auto-import/vite'

export default defineConfig({
  plugins: [
    AutoImport({
      imports: ['vitest'],
      dts: true, // generate TypeScript declaration
    }),
  ],
})

environment

Type: 'node' | 'jsdom' | 'happy-dom' | 'edge-runtime' | string
Default: 'node'
CLI: --environment=<env>

The environment that will be used for testing. The default environment in Vitest is a Node.js environment. If you are building a web application, you can use browser-like environment through either jsdom or happy-dom instead. If you are building edge functions, you can use edge-runtime environment

TIP

You can also use Browser Mode to run integration or unit tests in the browser without mocking the environment.

By adding a @vitest-environment docblock or comment at the top of the file, you can specify another environment to be used for all tests in that file:

Docblock style:

/**
 * @vitest-environment jsdom
 */

test('use jsdom in this test file', () => {
  const element = document.createElement('div')
  expect(element).not.toBeNull()
})

Comment style:

// @vitest-environment happy-dom

test('use happy-dom in this test file', () => {
  const element = document.createElement('div')
  expect(element).not.toBeNull()
})

For compatibility with Jest, there is also a @jest-environment:

/**
 * @jest-environment jsdom
 */

test('use jsdom in this test file', () => {
  const element = document.createElement('div')
  expect(element).not.toBeNull()
})

If you are running Vitest with --isolate=false flag, your tests will be run in this order: node, jsdom, happy-dom, edge-runtime, custom environments. Meaning, that every test with the same environment is grouped, but is still running sequentially.

Starting from 0.23.0, you can also define custom environment. When non-builtin environment is used, Vitest will try to load package vitest-environment-${name}. That package should export an object with the shape of Environment:

environment.js

import type { Environment } from 'vitest'

export default <Environment>{
  name: 'custom',
  transformMode: 'ssr',
  setup() {
    // custom setup
    return {
      teardown() {
        // called after all tests with this env have been run
      }
    }
  }
}

Vitest also exposes builtinEnvironments through vitest/environments entry, in case you just want to extend it. You can read more about extending environments in our guide.

TIP

jsdom environment exposes jsdom global variable equal to the current JSDOM instance. If you want TypeScript to recognize it, you can add vitest/jsdom to your tsconfig.json when you use this environment:

tsconfig.json

json

{
  "compilerOptions": {
    "types": ["vitest/jsdom"]
  }
}

environmentOptions

Type: Record<'jsdom' | string, unknown>
Default: {}

These options are passed down to setup method of current environment. By default, you can configure only JSDOM options, if you are using it as your test environment.

environmentMatchGlobs

Type: [string, EnvironmentName][]
Default: []

DEPRECATED

This API was deprecated in Vitest 3. Use projects to define different configurations instead.

export default defineConfig({
  test: {
    environmentMatchGlobs: [ 
      ['./*.jsdom.test.ts', 'jsdom'], 
    ], 
    projects: [ 
      { 
        extends: true, 
        test: { 
          environment: 'jsdom', 
        }, 
      }, 
    ], 
  },
})

Automatically assign environment based on globs. The first match will be used.

For example:

import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    environmentMatchGlobs: [
      // all tests in tests/dom will run in jsdom
      ['tests/dom/**', 'jsdom'],
      // all tests in tests/ with .edge.test.ts will run in edge-runtime
      ['**\/*.edge.test.ts', 'edge-runtime'],
      // ...
    ]
  }
})

poolMatchGlobs

Type: [string, 'threads' | 'forks' | 'vmThreads' | 'vmForks' | 'typescript'][]
Default: []

DEPRECATED

This API was deprecated in Vitest 3. Use projects to define different configurations instead:

export default defineConfig({
  test: {
    poolMatchGlobs: [ 
      ['./*.threads.test.ts', 'threads'], 
    ], 
    projects: [ 
      { 
        test: { 
          extends: true, 
          pool: 'threads', 
        }, 
      }, 
    ], 
  },
})

Automatically assign pool in which tests will run based on globs. The first match will be used.

For example:

import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    poolMatchGlobs: [
      // all tests in "worker-specific" directory will run inside a worker as if you enabled `--pool=threads` for them,
      ['**/tests/worker-specific/**', 'threads'],
      // run all tests in "browser" directory in an actual browser
      ['**/tests/browser/**', 'browser'],
      // all other tests will run based on "browser.enabled" and "threads" options, if you didn't specify other globs
      // ...
    ]
  }
})

update *

Type: boolean
Default: false
CLI: -u, --update, --update=false

Update snapshot files. This will update all changed snapshots and delete obsolete ones.

watch *

Type: boolean
Default: !process.env.CI && process.stdin.isTTY
CLI: -w, --watch, --watch=false

Enable watch mode

In interactive environments, this is the default, unless --run is specified explicitly.

In CI, or when run from a non-interactive shell, "watch" mode is not the default, but can be enabled explicitly with this flag.

watchTriggerPatterns 3.2.0+ *

Type: WatcherTriggerPattern[]

Vitest reruns tests based on the module graph which is populated by static and dynamic import statements. However, if you are reading from the file system or fetching from a proxy, then Vitest cannot detect those dependencies.

To correctly rerun those tests, you can define a regex pattern and a function that retuns a list of test files to run.

import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    watchTriggerPatterns: [
      {
        pattern: /^src\/(mailers|templates)\/(.*)\.(ts|html|txt)$/,
        testsToRun: (id, match) => {
          // relative to the root value
          return `./api/tests/mailers/${match[2]}.test.ts`
        },
      },
    ],
  },
})

WARNING

Returned files should be either absolute or relative to the root. Note that this is a global option, and it cannot be used inside of project configs.

root

Type: string
CLI: -r <path>, --root=<path>

Project root

dir

Type: string
CLI: --dir=<path>
Default: same as root

Base directory to scan for the test files. You can specify this option to speed up test discovery if your root covers the whole project

reporters *

Type: Reporter | Reporter[]
Default: 'default'
CLI: --reporter=<name>, --reporter=<name1> --reporter=<name2>

Custom reporters for output. Reporters can be a Reporter instance, a string to select built-in reporters, or a path to a custom implementation (e.g. './path/to/reporter.ts', '@scope/reporter').

outputFile *

Type: string | Record<string, string>
CLI: --outputFile=<path>, --outputFile.json=./path

Write test results to a file when the --reporter=json, --reporter=html or --reporter=junit option is also specified. By providing an object instead of a string you can define individual outputs when using multiple reporters.

pool *

Type: 'threads' | 'forks' | 'vmThreads' | 'vmForks'
Default: 'forks'
CLI: --pool=threads

Pool used to run tests in.

threads *

Enable multi-threading using tinypool (a lightweight fork of Piscina). When using threads you are unable to use process related APIs such as process.chdir(). Some libraries written in native languages, such as Prisma, bcrypt and canvas, have problems when running in multiple threads and run into segfaults. In these cases it is advised to use forks pool instead.

forks *

Similar as threads pool but uses child_process instead of worker_threads via tinypool. Communication between tests and main process is not as fast as with threads pool. Process related APIs such as process.chdir() are available in forks pool.

vmThreads *

Run tests using VM context (inside a sandboxed environment) in a threads pool.

This makes tests run faster, but the VM module is unstable when running ESM code. Your tests will leak memory - to battle that, consider manually editing poolOptions.vmThreads.memoryLimit value.

WARNING

Running code in a sandbox has some advantages (faster tests), but also comes with a number of disadvantages.

The globals within native modules, such as (fs, path, etc), differ from the globals present in your test environment. As a result, any error thrown by these native modules will reference a different Error constructor compared to the one used in your code:

try {
  fs.writeFileSync('/doesnt exist')
}
catch (err) {
  console.log(err instanceof Error) // false
}

Importing ES modules caches them indefinitely which introduces memory leaks if you have a lot of contexts (test files). There is no API in Node.js that clears that cache.
Accessing globals takes longer in a sandbox environment.

Please, be aware of these issues when using this option. Vitest team cannot fix any of the issues on our side.

vmForks *

Similar as vmThreads pool but uses child_process instead of worker_threads via tinypool. Communication between tests and the main process is not as fast as with vmThreads pool. Process related APIs such as process.chdir() are available in vmForks pool. Please be aware that this pool has the same pitfalls listed in vmThreads.

poolOptions *

Type: Record<'threads' | 'forks' | 'vmThreads' | 'vmForks', {}>
Default: {}

poolOptions.threads

Options for threads pool.

import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    poolOptions: {
      threads: {
        // Threads related options here
      }
    }
  }
})

poolOptions.threads.maxThreads *

Type: number | string
Default: available CPUs

Maximum number or percentage of threads. You can also use VITEST_MAX_THREADS environment variable.

poolOptions.threads.minThreads *

Type: number | string
Default: available CPUs

Minimum number or percentage of threads. You can also use VITEST_MIN_THREADS environment variable.

poolOptions.threads.singleThread

Type: boolean
Default: false

Run all tests with the same environment inside a single worker thread. This will disable built-in module isolation (your source code or inlined code will still be reevaluated for each test), but can improve test performance.

WARNING

Even though this option will force tests to run one after another, this option is different from Jest's --runInBand. Vitest uses workers not only for running tests in parallel, but also to provide isolation. By disabling this option, your tests will run sequentially, but in the same global context, so you must provide isolation yourself.

This might cause all sorts of issues, if you are relying on global state (frontend frameworks usually do) or your code relies on environment to be defined separately for each test. But can be a speed boost for your tests (up to 3 times faster), that don't necessarily rely on global state or can easily bypass that.

poolOptions.threads.useAtomics *

Type: boolean
Default: false

Use Atomics to synchronize threads.

This can improve performance in some cases, but might cause segfault in older Node versions.

poolOptions.threads.isolate

Type: boolean
Default: true

Isolate environment for each test file.

poolOptions.threads.execArgv *

Type: string[]
Default: []

Pass additional arguments to node in the threads. See Command-line API | Node.js for more information.

WARNING

Be careful when using, it as some options may crash worker, e.g. --prof, --title. See https://github.com/nodejs/node/issues/41103.

poolOptions.forks

Options for forks pool.

import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    poolOptions: {
      forks: {
        // Forks related options here
      }
    }
  }
})

poolOptions.forks.maxForks *

Type: number | string
Default: available CPUs

Maximum number or percentage of forks. You can also use VITEST_MAX_FORKS environment variable.

poolOptions.forks.minForks *

Type: number | string
Default: available CPUs

Minimum number or percentage of forks. You can also use VITEST_MIN_FORKS environment variable.

poolOptions.forks.isolate

Type: boolean
Default: true

Isolate environment for each test file.

poolOptions.forks.singleFork

Type: boolean
Default: false

Run all tests with the same environment inside a single child process. This will disable built-in module isolation (your source code or inlined code will still be reevaluated for each test), but can improve test performance.

WARNING

Even though this option will force tests to run one after another, this option is different from Jest's --runInBand. Vitest uses child processes not only for running tests in parallel, but also to provide isolation. By disabling this option, your tests will run sequentially, but in the same global context, so you must provide isolation yourself.

poolOptions.forks.execArgv *

Type: string[]
Default: []

Pass additional arguments to node process in the child processes. See Command-line API | Node.js for more information.

WARNING

Be careful when using, it as some options may crash worker, e.g. --prof, --title. See https://github.com/nodejs/node/issues/41103.

poolOptions.vmThreads

Options for vmThreads pool.

import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    poolOptions: {
      vmThreads: {
        // VM threads related options here
      }
    }
  }
})

poolOptions.vmThreads.maxThreads *

Type: number | string
Default: available CPUs

Maximum number or percentage of threads. You can also use VITEST_MAX_THREADS environment variable.

poolOptions.vmThreads.minThreads *

Type: number | string
Default: available CPUs

Minimum number or percentage of threads. You can also use VITEST_MIN_THREADS environment variable.

poolOptions.vmThreads.memoryLimit *

Type: string | number
Default: 1 / CPU Cores

Specifies the memory limit for workers before they are recycled. This value heavily depends on your environment, so it's better to specify it manually instead of relying on the default.

TIP

The implementation is based on Jest's workerIdleMemoryLimit.

The limit can be specified in a number of different ways and whatever the result is Math.floor is used to turn it into an integer value:

<= 1 - The value is assumed to be a percentage of system memory. So 0.5 sets the memory limit of the worker to half of the total system memory
\> 1 - Assumed to be a fixed byte value. Because of the previous rule if you wanted a value of 1 byte (I don't know why) you could use 1.1.
With units
- 50% - As above, a percentage of total system memory
- 100KB, 65MB, etc - With units to denote a fixed memory limit.
  - K / KB - Kilobytes (x1000)
  - KiB - Kibibytes (x1024)
  - M / MB - Megabytes
  - MiB - Mebibytes
  - G / GB - Gigabytes
  - GiB - Gibibytes

WARNING

Percentage based memory limit does not work on Linux CircleCI workers due to incorrect system memory being reported.

poolOptions.vmThreads.useAtomics *

Type: boolean
Default: false

Use Atomics to synchronize threads.

This can improve performance in some cases, but might cause segfault in older Node versions.

poolOptions.vmThreads.execArgv *

Type: string[]
Default: []

Pass additional arguments to node process in the VM context. See Command-line API | Node.js for more information.

WARNING

Be careful when using, it as some options may crash worker, e.g. --prof, --title. See https://github.com/nodejs/node/issues/41103.

poolOptions.vmForks *

Options for vmForks pool.

import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    poolOptions: {
      vmForks: {
        // VM forks related options here
      }
    }
  }
})

poolOptions.vmForks.maxForks *

Type: number | string
Default: available CPUs

Maximum number or percentage of forks. You can also use VITEST_MAX_FORKS environment variable.

poolOptions.vmForks.minForks *

Type: number | string
Default: available CPUs

Minimum number or percentage of forks. You can also use VITEST_MIN_FORKS environment variable.

poolOptions.vmForks.memoryLimit *

Type: string | number
Default: 1 / CPU Cores

Specifies the memory limit for workers before they are recycled. This value heavily depends on your environment, so it's better to specify it manually instead of relying on the default. How the value is calculated is described in poolOptions.vmThreads.memoryLimit

poolOptions.vmForks.execArgv *

Type: string[]
Default: []

Pass additional arguments to node process in the VM context. See Command-line API | Node.js for more information.

WARNING

Be careful when using, it as some options may crash worker, e.g. --prof, --title. See https://github.com/nodejs/node/issues/41103.

fileParallelism *

Type: boolean
Default: true
CLI: --no-file-parallelism, --fileParallelism=false

Should all test files run in parallel. Setting this to false will override maxWorkers and minWorkers options to 1.

TIP

This option doesn't affect tests running in the same file. If you want to run those in parallel, use concurrent option on describe or via a config.

maxWorkers *

Type: number | string

Maximum number or percentage of workers to run tests in. poolOptions.{threads,vmThreads}.maxThreads/poolOptions.forks.maxForks has higher priority.

minWorkers *

Type: number | string

Minimum number or percentage of workers to run tests in. poolOptions.{threads,vmThreads}.minThreads/poolOptions.forks.minForks has higher priority.

testTimeout

Type: number
Default: 5_000 in Node.js, 15_000 if browser.enabled is true
CLI: --test-timeout=5000, --testTimeout=5000

Default timeout of a test in milliseconds. Use 0 to disable timeout completely.

hookTimeout

Type: number
Default: 10_000 in Node.js, 30_000 if browser.enabled is true
CLI: --hook-timeout=10000, --hookTimeout=10000

Default timeout of a hook in milliseconds. Use 0 to disable timeout completely.

teardownTimeout *

Type: number
Default: 10000
CLI: --teardown-timeout=5000, --teardownTimeout=5000

Default timeout to wait for close when Vitest shuts down, in milliseconds

silent *

Type: boolean | 'passed-only'
Default: false
CLI: --silent, --silent=false

Silent console output from tests.

Use 'passed-only' to see logs from failing tests only. Logs from failing tests are printed after a test has finished.

setupFiles

Type: string | string[]

Path to setup files. They will be run before each test file.

INFO

Editing a setup file will automatically trigger a rerun of all tests.

You can use process.env.VITEST_POOL_ID (integer-like string) inside to distinguish between threads.

TIP

Note, that if you are running

Configuring Vitest ​

include ​

exclude ​

includeSource ​

name ​

server ​

server.sourcemap ​

server.debug ​

server.debug.dumpModules ​

server.debug.loadDumppedModules ​

server.deps ​

server.deps.external ​

server.deps.inline ​

server.deps.fallbackCJS ​

server.deps.cacheDir ​

deps ​

deps.optimizer ​

deps.optimizer.{mode}.enabled ​

deps.web ​

deps.web.transformAssets ​

deps.web.transformCss ​

deps.web.transformGlobPattern ​

deps.interopDefault ​

deps.moduleDirectories ​

runner ​

benchmark ​

benchmark.include ​

benchmark.exclude ​

benchmark.includeSource ​

benchmark.reporters ​

benchmark.outputFile ​

benchmark.outputJson ​

benchmark.compare ​

alias ​

globals ​

environment ​

environmentOptions ​

environmentMatchGlobs ​

poolMatchGlobs ​

update * ​

watch * ​

watchTriggerPatterns 3.2.0+ * ​

root ​

dir ​

reporters * ​

outputFile * ​

pool * ​

threads * ​

forks * ​

vmThreads * ​

vmForks * ​

poolOptions * ​

poolOptions.threads ​

poolOptions.threads.maxThreads * ​

poolOptions.threads.minThreads * ​

poolOptions.threads.singleThread ​

poolOptions.threads.useAtomics * ​

poolOptions.threads.isolate ​

poolOptions.threads.execArgv * ​

poolOptions.forks ​

poolOptions.forks.maxForks * ​

poolOptions.forks.minForks * ​

poolOptions.forks.isolate ​

poolOptions.forks.singleFork ​

poolOptions.forks.execArgv * ​

poolOptions.vmThreads ​

poolOptions.vmThreads.maxThreads * ​

poolOptions.vmThreads.minThreads * ​

poolOptions.vmThreads.memoryLimit * ​

poolOptions.vmThreads.useAtomics * ​

poolOptions.vmThreads.execArgv * ​

poolOptions.vmForks * ​

poolOptions.vmForks.maxForks * ​

poolOptions.vmForks.minForks * ​

poolOptions.vmForks.memoryLimit * ​

poolOptions.vmForks.execArgv * ​

fileParallelism * ​

maxWorkers * ​

minWorkers * ​

testTimeout ​

Configuring Vitest

include

exclude

includeSource

name

server

server.sourcemap

server.debug

server.debug.dumpModules

server.debug.loadDumppedModules

server.deps

server.deps.external

server.deps.inline

server.deps.fallbackCJS

server.deps.cacheDir

deps

deps.optimizer

deps.optimizer.{mode}.enabled

deps.web

deps.web.transformAssets

deps.web.transformCss

deps.web.transformGlobPattern

deps.interopDefault

deps.moduleDirectories

runner

benchmark

benchmark.include

benchmark.exclude

benchmark.includeSource

benchmark.reporters

benchmark.outputFile

benchmark.outputJson

benchmark.compare

alias

globals

environment

environmentOptions

environmentMatchGlobs

poolMatchGlobs

update *

watch *

watchTriggerPatterns 3.2.0+ *

root

dir

reporters *

outputFile *

pool *

threads *

forks *

vmThreads *

vmForks *

poolOptions *

poolOptions.threads

poolOptions.threads.maxThreads *

poolOptions.threads.minThreads *

poolOptions.threads.singleThread

poolOptions.threads.useAtomics *

poolOptions.threads.isolate

poolOptions.threads.execArgv *

poolOptions.forks

poolOptions.forks.maxForks *

poolOptions.forks.minForks *

poolOptions.forks.isolate

poolOptions.forks.singleFork

poolOptions.forks.execArgv *

poolOptions.vmThreads

poolOptions.vmThreads.maxThreads *

poolOptions.vmThreads.minThreads *

poolOptions.vmThreads.memoryLimit *

poolOptions.vmThreads.useAtomics *

poolOptions.vmThreads.execArgv *

poolOptions.vmForks *

poolOptions.vmForks.maxForks *

poolOptions.vmForks.minForks *

poolOptions.vmForks.memoryLimit *

poolOptions.vmForks.execArgv *

fileParallelism *

maxWorkers *

minWorkers *

testTimeout