+1 -1

docs/api/describe.md

Reviewed

··· 254 254 255 255 - **Alias:** `suite.shuffle` 256 256 257 257 - Vitest provides a way to run all tests in random order via CLI flag [`--sequence.shuffle`](/guide/cli) or config option [`sequence.shuffle`](/config/#sequence-shuffle), but if you want to have only part of your test suite to run tests in random order, you can mark it with this flag. 257 257 + Vitest provides a way to run all tests in random order via CLI flag [`--sequence.shuffle`](/guide/cli) or config option [`sequence.shuffle`](/config/sequence#sequence-shuffle), but if you want to have only part of your test suite to run tests in random order, you can mark it with this flag. 258 258 259 259 ```ts 260 260 import { describe, test } from 'vitest'

+1 -1

docs/api/hooks.md

Reviewed

··· 431 431 ``` 432 432 433 433 ::: tip 434 434 - This hook is always called in reverse order and is not affected by [`sequence.hooks`](/config/#sequence-hooks) option. 434 434 + This hook is always called in reverse order and is not affected by [`sequence.hooks`](/config/sequence#sequence-hooks) option. 435 435 ::: 436 436 437 437 ### onTestFailed

+3 -3

docs/api/mock.md

Reviewed

··· 134 134 expect(spy.mock.calls).toEqual([['Bob']]) 135 135 ``` 136 136 137 137 - To automatically call this method before each test, enable the [`clearMocks`](/config/#clearmocks) setting in the configuration. 137 137 + To automatically call this method before each test, enable the [`clearMocks`](/config/clearmocks) setting in the configuration. 138 138 139 139 ## mockName 140 140 ··· 302 302 expect(spy.mock.calls).toEqual([['Bob']]) 303 303 ``` 304 304 305 305 - To automatically call this method before each test, enable the [`mockReset`](/config/#mockreset) setting in the configuration. 305 305 + To automatically call this method before each test, enable the [`mockReset`](/config/mockreset) setting in the configuration. 306 306 307 307 ## mockRestore 308 308 ··· 330 330 expect(spy.mock.calls).toEqual([]) 331 331 ``` 332 332 333 333 - To automatically call this method before each test, enable the [`restoreMocks`](/config/#restoremocks) setting in the configuration. 333 333 + To automatically call this method before each test, enable the [`restoreMocks`](/config/restoremocks) setting in the configuration. 334 334 335 335 ## mockResolvedValue 336 336

+1 -1

docs/api/test.md

Reviewed

··· 618 618 ``` 619 619 620 620 ::: tip 621 621 - Vitest processes `$values` with Chai `format` method. If the value is too truncated, you can increase [chaiConfig.truncateThreshold](/config/#chaiconfig-truncatethreshold) in your config file. 621 621 + Vitest processes `$values` with Chai `format` method. If the value is too truncated, you can increase [chaiConfig.truncateThreshold](/config/chaiconfig#chaiconfig-truncatethreshold) in your config file. 622 622 ::: 623 623 624 624 ## test.for

+6 -6

docs/api/vi.md

Reviewed

··· 4 4 5 5 # Vi 6 6 7 7 - Vitest provides utility functions to help you out through its `vi` helper. You can access it globally (when [globals configuration](/config/#globals) is enabled), or import it from `vitest` directly: 7 7 + Vitest provides utility functions to help you out through its `vi` helper. You can access it globally (when [globals configuration](/config/globals) is enabled), or import it from `vitest` directly: 8 8 9 9 ```js 10 10 import { vi } from 'vitest' ··· 42 42 ::: warning 43 43 `vi.mock` works only for modules that were imported with the `import` keyword. It doesn't work with `require`. 44 44 45 45 - In order to hoist `vi.mock`, Vitest statically analyzes your files. It indicates that `vi` that was not directly imported from the `vitest` package (for example, from some utility file) cannot be used. Use `vi.mock` with `vi` imported from `vitest`, or enable [`globals`](/config/#globals) config option. 45 45 + In order to hoist `vi.mock`, Vitest statically analyzes your files. It indicates that `vi` that was not directly imported from the `vitest` package (for example, from some utility file) cannot be used. Use `vi.mock` with `vi` imported from `vitest`, or enable [`globals`](/config/globals) config option. 46 46 47 47 Vitest will not mock modules that were imported inside a [setup file](/config/setupfiles) because they are cached by the time a test file is running. You can call [`vi.resetModules()`](#vi-resetmodules) inside [`vi.hoisted`](#vi-hoisted) to clear all module caches before running a test file. 48 48 ::: ··· 137 137 ``` 138 138 ::: 139 139 140 140 - If there is a `__mocks__` folder alongside a file that you are mocking, and the factory is not provided, Vitest will try to find a file with the same name in the `__mocks__` subfolder and use it as an actual module. If you are mocking a dependency, Vitest will try to find a `__mocks__` folder in the [root](/config/#root) of the project (default is `process.cwd()`). You can tell Vitest where the dependencies are located through the [`deps.moduleDirectories`](/config/#deps-moduledirectories) config option. 140 140 + If there is a `__mocks__` folder alongside a file that you are mocking, and the factory is not provided, Vitest will try to find a file with the same name in the `__mocks__` subfolder and use it as an actual module. If you are mocking a dependency, Vitest will try to find a `__mocks__` folder in the [root](/config/root) of the project (default is `process.cwd()`). You can tell Vitest where the dependencies are located through the [`deps.moduleDirectories`](/config/deps#deps-moduledirectories) config option. 141 141 142 142 For example, you have this file structure: 143 143 ··· 628 628 ::: 629 629 630 630 ::: tip 631 631 - You can call [`vi.restoreAllMocks`](#vi-restoreallmocks) inside [`afterEach`](/api/hooks#aftereach) (or enable [`test.restoreMocks`](/config/#restoreMocks)) to restore all methods to their original implementations after every test. This will restore the original [object descriptor](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty), so you won't be able to change method's implementation anymore, unless you spy again: 631 631 + You can call [`vi.restoreAllMocks`](#vi-restoreallmocks) inside [`afterEach`](/api/hooks#aftereach) (or enable [`test.restoreMocks`](/config/restoremocks)) to restore all methods to their original implementations after every test. This will restore the original [object descriptor](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty), so you won't be able to change method's implementation anymore, unless you spy again: 632 632 633 633 ```ts 634 634 const cart = { ··· 941 941 function runAllTimers(): Vitest 942 942 ``` 943 943 944 944 - This method will invoke every initiated timer until the timer queue is empty. It means that every timer called during `runAllTimers` will be fired. If you have an infinite interval, it will throw after 10 000 tries (can be configured with [`fakeTimers.loopLimit`](/config/#faketimers-looplimit)). 944 944 + This method will invoke every initiated timer until the timer queue is empty. It means that every timer called during `runAllTimers` will be fired. If you have an infinite interval, it will throw after 10 000 tries (can be configured with [`fakeTimers.loopLimit`](/config/faketimers#faketimers-looplimit)). 945 945 946 946 ```ts 947 947 let i = 0 ··· 967 967 ``` 968 968 969 969 This method will asynchronously invoke every initiated timer until the timer queue is empty. It means that every timer called during `runAllTimersAsync` will be fired even asynchronous timers. If you have an infinite interval, 970 970 - it will throw after 10 000 tries (can be configured with [`fakeTimers.loopLimit`](/config/#faketimers-looplimit)). 970 970 + it will throw after 10 000 tries (can be configured with [`fakeTimers.loopLimit`](/config/faketimers#faketimers-looplimit)). 971 971 972 972 ```ts 973 973 setTimeout(async () => {

+5 -5

docs/blog/vitest-3-2.md

Reviewed

··· 68 68 69 69 The file fixture is similar to using `beforeAll` and `afterAll` at the top level of the file, but it won't be called if the fixture is not used in any test. 70 70 71 71 - The `worker` fixture is initiated once per worker, but note that by default Vitest creates one worker for every test, so you need to disable [isolation](/config/#isolate) to benefit from it. 71 71 + The `worker` fixture is initiated once per worker, but note that by default Vitest creates one worker for every test, so you need to disable [isolation](/config/isolate) to benefit from it. 72 72 73 73 ## Custom Project Name Colors 74 74 75 75 - You can now set a custom [color](/config/#name) when using `projects`: 75 75 + You can now set a custom [color](/config/name) when using `projects`: 76 76 77 77 ::: details Config Example 78 78 ```ts{6-9,14-17} ··· 192 192 193 193 Vitest now provides an [`AbortSignal`](https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal) object to the test body. You can use it to stop any resource that supports this Web API. 194 194 195 195 - The signal is aborted when test times out, another test fails and [`--bail` flag](/config/#bail) is set to a non-zero value, or the user presses Ctrl+C in the terminal. 195 195 + The signal is aborted when test times out, another test fails and [`--bail` flag](/config/bail) is set to a non-zero value, or the user presses Ctrl+C in the terminal. 196 196 197 197 For example, you can stop a `fetch` request when tests are interrupted: 198 198 ··· 204 204 205 205 ## Coverage V8 AST-aware remapping 206 206 207 207 - Vitest now uses `ast-v8-to-istanbul` package developed by one of the Vitest maintainers, [AriPerkkio](https://github.com/AriPerkkio). This brings v8 coverage report in line with istanbul, but has a better performance! Enable this feature by setting [`coverage.experimentalAstAwareRemapping`](/config/#coverage-experimentalastawareremapping) to `true`. 207 207 + Vitest now uses `ast-v8-to-istanbul` package developed by one of the Vitest maintainers, [AriPerkkio](https://github.com/AriPerkkio). This brings v8 coverage report in line with istanbul, but has a better performance! Enable this feature by setting [`coverage.experimentalAstAwareRemapping`](/config/coverage#coverage-experimentalastawareremapping) to `true`. 208 208 209 209 We are planning to make this the default remapping mode in the next major. The old `v8-to-istanbul` will be removed completely. Feel free to join discussion at https://github.com/vitest-dev/vitest/issues/7928. 210 210 ··· 267 267 268 268 ## `sequence.groupOrder` 269 269 270 270 - The new [`sequence.groupOrder`](/config/#grouporder) option controls the order in which the project runs its tests when using multiple [projects](/guide/projects). 270 270 + The new [`sequence.groupOrder`](/config/sequence#sequence-grouporder) option controls the order in which the project runs its tests when using multiple [projects](/guide/projects). 271 271 272 272 - Projects with the same group order number will run together, and groups are run from lowest to highest. 273 273 - If you don’t set this option, all projects run in parallel.

+2 -2

docs/guide/cli-generated.md

Reviewed

··· 165 165 - **CLI:** `--coverage.reporter <name>` 166 166 - **Config:** [coverage.reporter](/config/coverage#coverage-reporter) 167 167 168 168 - Coverage reporters to use. Visit [`coverage.reporter`](/config/#coverage-reporter) for more information (default: `["text", "html", "clover", "json"]`) 168 168 + Coverage reporters to use. Visit [`coverage.reporter`](/config/coverage#coverage-reporter) for more information (default: `["text", "html", "clover", "json"]`) 169 169 170 170 ### coverage.reportOnFailure 171 171 ··· 511 511 - **CLI:** `--sequence.hooks <order>` 512 512 - **Config:** [sequence.hooks](/config/sequence#sequence-hooks) 513 513 514 514 - Changes the order in which hooks are executed. Accepted values are: "stack", "list" and "parallel". Visit [`sequence.hooks`](/config/#sequence-hooks) for more information (default: `"parallel"`) 514 514 + Changes the order in which hooks are executed. Accepted values are: "stack", "list" and "parallel". Visit [`sequence.hooks`](/config/sequence#sequence-hooks) for more information (default: `"parallel"`) 515 515 516 516 ### sequence.setupFiles 517 517

+1 -1

docs/guide/cli.md

Reviewed

··· 198 198 199 199 When used with code coverage the report will contain only the files that were related to the changes. 200 200 201 201 - If paired with the [`forceRerunTriggers`](/config/#forcereruntriggers) config option it will run the whole test suite if at least one of the files listed in the `forceRerunTriggers` list changes. By default, changes to the Vitest config file and `package.json` will always rerun the whole suite. 201 201 + If paired with the [`forceRerunTriggers`](/config/forcereruntriggers) config option it will run the whole test suite if at least one of the files listed in the `forceRerunTriggers` list changes. By default, changes to the Vitest config file and `package.json` will always rerun the whole suite. 202 202 203 203 ### shard 204 204

+1 -1

docs/guide/common-errors.md

Reviewed

··· 28 28 + import helpers from '../src/helpers' 29 29 ``` 30 30 31 31 - 3. Make sure you don't have relative [aliases](/config/#alias). Vite treats them as relative to the file where the import is instead of the root. 31 31 + 3. Make sure you don't have relative [aliases](/config/alias). Vite treats them as relative to the file where the import is instead of the root. 32 32 33 33 ```ts 34 34 import { defineConfig } from 'vitest/config'

+4 -4

docs/guide/coverage.md

Reviewed

··· 138 138 ## Coverage Setup 139 139 140 140 ::: tip 141 141 - All coverage options are listed in [Coverage Config Reference](/config/#coverage). 141 141 + All coverage options are listed in [Coverage Config Reference](/config/coverage). 142 142 ::: 143 143 144 144 To test with coverage enabled, you can pass the `--coverage` flag in CLI or set `coverage.enabled` in `vitest.config.ts`: ··· 167 167 168 168 ## Including and Excluding Files from Coverage Report 169 169 170 170 - You can define what files are shown in coverage report by configuring [`coverage.include`](/config/#coverage-include) and [`coverage.exclude`](/config/#coverage-exclude). 170 170 + You can define what files are shown in coverage report by configuring [`coverage.include`](/config/coverage#coverage-include) and [`coverage.exclude`](/config/coverage#coverage-exclude). 171 171 172 172 By default Vitest will show only files that were imported during test run. 173 173 - To include uncovered files in the report, you'll need to configure [`coverage.include`](/config/#coverage-include) with a pattern that will pick your source files: 173 173 + To include uncovered files in the report, you'll need to configure [`coverage.include`](/config/coverage#coverage-include) with a pattern that will pick your source files: 174 174 175 175 ::: code-group 176 176 ```ts [vitest.config.ts] {6} ··· 204 204 ``` 205 205 ::: 206 206 207 207 - To exclude files that are matching `coverage.include`, you can define an additional [`coverage.exclude`](/config/#coverage-exclude): 207 207 + To exclude files that are matching `coverage.include`, you can define an additional [`coverage.exclude`](/config/coverage#coverage-exclude): 208 208 209 209 ::: code-group 210 210 ```ts [vitest.config.ts] {7}

+2 -2

docs/guide/environment.md

Reviewed

··· 4 4 5 5 # Test Environment 6 6 7 7 - Vitest provides [`environment`](/config/#environment) option to run code inside a specific environment. You can modify how environment behaves with [`environmentOptions`](/config/#environmentoptions) option. 7 7 + Vitest provides [`environment`](/config/environment) option to run code inside a specific environment. You can modify how environment behaves with [`environmentOptions`](/config/environmentoptions) option. 8 8 9 9 By default, you can use these environments: 10 10 ··· 14 14 - `edge-runtime` emulates Vercel's [edge-runtime](https://edge-runtime.vercel.app/), uses [`@edge-runtime/vm`](https://www.npmjs.com/package/@edge-runtime/vm) package 15 15 16 16 ::: info 17 17 - When using `jsdom` or `happy-dom` environments, Vitest follows the same rules that Vite does when importing [CSS](https://vitejs.dev/guide/features.html#css) and [assets](https://vitejs.dev/guide/features.html#static-assets). If importing external dependency fails with `unknown extension .css` error, you need to inline the whole import chain manually by adding all packages to [`server.deps.inline`](/config/#server-deps-inline). For example, if the error happens in `package-3` in this import chain: `source code -> package-1 -> package-2 -> package-3`, you need to add all three packages to `server.deps.inline`. 17 17 + When using `jsdom` or `happy-dom` environments, Vitest follows the same rules that Vite does when importing [CSS](https://vitejs.dev/guide/features.html#css) and [assets](https://vitejs.dev/guide/features.html#static-assets). If importing external dependency fails with `unknown extension .css` error, you need to inline the whole import chain manually by adding all packages to [`server.deps.inline`](/config/server#inline). For example, if the error happens in `package-3` in this import chain: `source code -> package-1 -> package-2 -> package-3`, you need to add all three packages to `server.deps.inline`. 18 18 19 19 The `require` of CSS and assets inside the external dependencies are resolved automatically. 20 20 :::

+3 -3

docs/guide/features.md

Reviewed

··· 39 39 ## Threads 40 40 41 41 By default Vitest runs test files in [multiple processes](/guide/parallelism) using [`node:child_process`](https://nodejs.org/api/child_process.html), allowing tests to run simultaneously. If you want to speed up your test suite even further, consider enabling `--pool=threads` to run tests using [`node:worker_threads`](https://nodejs.org/api/worker_threads.html) (beware that some packages might not work with this setup). 42 42 - To run tests in a single thread or process, see [`fileParallelism`](/config/#fileParallelism). 42 42 + To run tests in a single thread or process, see [`fileParallelism`](/config/fileparallelism). 43 43 44 44 Vitest also isolates each file's environment so env mutations in one file don't affect others. Isolation can be disabled by passing `--no-isolate` to the CLI (trading correctness for run performance). 45 45 ··· 102 102 103 103 [Chai](https://www.chaijs.com/) is built-in for assertions with [Jest `expect`](https://jestjs.io/docs/expect)-compatible APIs. 104 104 105 105 - Notice that if you are using third-party libraries that add matchers, setting [`test.globals`](/config/#globals) to `true` will provide better compatibility. 105 105 + Notice that if you are using third-party libraries that add matchers, setting [`test.globals`](/config/globals) to `true` will provide better compatibility. 106 106 107 107 ## Mocking 108 108 ··· 292 292 ``` 293 293 ::: 294 294 295 295 - Alternatively, you can also ignore reported errors with a [`dangerouslyIgnoreUnhandledErrors`](/config/#dangerouslyignoreunhandlederrors) option. Vitest will still report them, but they won't affect the test result (exit code won't be changed). 295 295 + Alternatively, you can also ignore reported errors with a [`dangerouslyIgnoreUnhandledErrors`](/config/dangerouslyignoreunhandlederrors) option. Vitest will still report them, but they won't affect the test result (exit code won't be changed). 296 296 297 297 If you need to test that error was not caught, you can create a test that looks like this: 298 298

+1 -1

docs/guide/filtering.md

Reviewed

··· 51 51 52 52 ## Specifying a Timeout 53 53 54 54 - You can optionally pass a timeout in milliseconds as a third argument to tests. The default is [5 seconds](/config/#testtimeout). 54 54 + You can optionally pass a timeout in milliseconds as a third argument to tests. The default is [5 seconds](/config/testtimeout). 55 55 56 56 ```ts 57 57 import { test } from 'vitest'

+4 -4

docs/guide/improving-performance.md

Reviewed

··· 2 2 3 3 ## Test Isolation 4 4 5 5 - By default Vitest runs every test file in an isolated environment based on the [pool](/config/#pool): 5 5 + By default Vitest runs every test file in an isolated environment based on the [pool](/config/pool): 6 6 7 7 - `threads` pool runs every test file in a separate [`Worker`](https://nodejs.org/api/worker_threads.html#class-worker) 8 8 - `forks` pool runs every test file in a separate [forked child process](https://nodejs.org/api/child_process.html#child_processforkmodulepath-args-options) 9 9 - `vmThreads` pool runs every test file in a separate [VM context](https://nodejs.org/api/vm.html#vmcreatecontextcontextobject-options), but it uses workers for parallelism 10 10 11 11 - This greatly increases test times, which might not be desirable for projects that don't rely on side effects and properly cleanup their state (which is usually true for projects with `node` environment). In this case disabling isolation will improve the speed of your tests. To do that, you can provide `--no-isolate` flag to the CLI or set [`test.isolate`](/config/#isolate) property in the config to `false`. 11 11 + This greatly increases test times, which might not be desirable for projects that don't rely on side effects and properly cleanup their state (which is usually true for projects with `node` environment). In this case disabling isolation will improve the speed of your tests. To do that, you can provide `--no-isolate` flag to the CLI or set [`test.isolate`](/config/isolate) property in the config to `false`. 12 12 13 13 ::: code-group 14 14 ```bash [CLI] ··· 56 56 If you are using `vmThreads` pool, you cannot disable isolation. Use `threads` pool instead to improve your tests performance. 57 57 ::: 58 58 59 59 - For some projects, it might also be desirable to disable parallelism to improve startup time. To do that, provide `--no-file-parallelism` flag to the CLI or set [`test.fileParallelism`](/config/#fileparallelism) property in the config to `false`. 59 59 + For some projects, it might also be desirable to disable parallelism to improve startup time. To do that, provide `--no-file-parallelism` flag to the CLI or set [`test.fileParallelism`](/config/fileparallelism) property in the config to `false`. 60 60 61 61 ::: code-group 62 62 ```bash [CLI] ··· 75 75 76 76 ## Limiting Directory Search 77 77 78 78 - You can limit the working directory when Vitest searches for files using [`test.dir`](/config/#test-dir) option. This should make the search faster if you have unrelated folders and files in the root directory. 78 78 + You can limit the working directory when Vitest searches for files using [`test.dir`](/config/dir) option. This should make the search faster if you have unrelated folders and files in the root directory. 79 79 80 80 ## Pool 81 81

+9 -9

docs/guide/migration.md

Reviewed

··· 145 145 Alongside new features like supporting constructors, Vitest 4 creates mocks differently to address several module mocking issues that we received over the years. This release attempts to make module spies less confusing, especially when working with classes. 146 146 147 147 - `vi.fn().getMockName()` now returns `vi.fn()` by default instead of `spy`. This can affect snapshots with mocks - the name will be changed from `[MockFunction spy]` to `[MockFunction]`. Spies created with `vi.spyOn` will keep using the original name by default for better debugging experience 148 148 - - `vi.restoreAllMocks` no longer resets the state of spies and only restores spies created manually with `vi.spyOn`, automocks are no longer affected by this function (this also affects the config option [`restoreMocks`](/config/#restoremocks)). Note that `.mockRestore` will still reset the mock implementation and clear the state 148 148 + - `vi.restoreAllMocks` no longer resets the state of spies and only restores spies created manually with `vi.spyOn`, automocks are no longer affected by this function (this also affects the config option [`restoreMocks`](/config/restoremocks)). Note that `.mockRestore` will still reset the mock implementation and clear the state 149 149 - Calling `vi.spyOn` on a mock now returns the same mock 150 150 - `mock.settledResults` are now populated immediately on function invocation with an `'incomplete'` result. When the promise is finished, the type is changed according to the result. 151 151 - Automocked instance methods are now properly isolated, but share a state with the prototype. Overriding the prototype implementation will always affect instance methods unless the methods have a custom mock implementation of their own. Calling `.mockReset` on the mock also no longer breaks that inheritance. ··· 212 212 - `vitest/execute` entry point was removed. It was always meant to be internal 213 213 - [Custom environments](/guide/environment) no longer need to provide a `transformMode` property. Instead, provide `viteEnvironment`. If it is not provided, Vitest will use the environment name to transform files on the server (see [`server.environments`](https://vite.dev/guide/api-environment-instances.html)) 214 214 - `vite-node` is no longer a dependency of Vitest 215 215 - - `deps.optimizer.web` was renamed to [`deps.optimizer.client`](/config/#deps-optimizer-client). You can also use any custom names to apply optimizer configs when using other server environments 215 215 + - `deps.optimizer.web` was renamed to [`deps.optimizer.client`](/config/deps#deps-client). You can also use any custom names to apply optimizer configs when using other server environments 216 216 217 217 - Vite has its own externalization mechanism, but we decided to keep using the old one to reduce the amount of breaking changes. You can keep using [`server.deps`](/config/#server-deps) to inline or externalize packages. 217 217 + Vite has its own externalization mechanism, but we decided to keep using the old one to reduce the amount of breaking changes. You can keep using [`server.deps`](/config/server#deps) to inline or externalize packages. 218 218 219 219 This update should not be noticeable unless you rely on advanced features mentioned above. 220 220 ··· 439 439 440 440 ### Snapshots using Custom Elements Print the Shadow Root 441 441 442 442 - In Vitest 4.0 snapshots that include custom elements will print the shadow root contents. To restore the previous behavior, set the [`printShadowRoot` option](/config/#snapshotformat) to `false`. 442 442 + In Vitest 4.0 snapshots that include custom elements will print the shadow root contents. To restore the previous behavior, set the [`printShadowRoot` option](/config/snapshotformat) to `false`. 443 443 444 444 ```js{15-22} 445 445 // before Vitest 4.0 ··· 500 500 501 501 ### Globals as a Default 502 502 503 503 - Jest has their [globals API](https://jestjs.io/docs/api) enabled by default. Vitest does not. You can either enable globals via [the `globals` configuration setting](/config/#globals) or update your code to use imports from the `vitest` module instead. 503 503 + Jest has their [globals API](https://jestjs.io/docs/api) enabled by default. Vitest does not. You can either enable globals via [the `globals` configuration setting](/config/globals) or update your code to use imports from the `vitest` module instead. 504 504 505 505 If you decide to keep globals disabled, be aware that common libraries like [`testing-library`](https://testing-library.com/) will not run auto DOM [cleanup](https://testing-library.com/docs/svelte-testing-library/api/#cleanup). 506 506 ··· 552 552 553 553 ### Extends mocking to external libraries 554 554 555 555 - 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](/config/#server-deps-inline). 555 555 + 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](/config/server#inline). 556 556 557 557 ``` 558 558 server.deps.inline: ["lib-name"] ··· 590 590 beforeEach(() => { setActivePinia(createTestingPinia()) }) // [!code ++] 591 591 ``` 592 592 593 593 - In Jest hooks are called sequentially (one after another). By default, Vitest runs hooks in a stack. To use Jest's behavior, update [`sequence.hooks`](/config/#sequence-hooks) option: 593 593 + In Jest hooks are called sequentially (one after another). By default, Vitest runs hooks in a stack. To use Jest's behavior, update [`sequence.hooks`](/config/sequence#sequence-hooks) option: 594 594 595 595 ```ts 596 596 export default defineConfig({ ··· 627 627 628 628 ### Vue Snapshots 629 629 630 630 - 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`](https://github.com/eddyerburgh/jest-serializer-vue) package, and specify it in [`snapshotSerializers`](/config/#snapshotserializers): 630 630 + 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`](https://github.com/eddyerburgh/jest-serializer-vue) package, and specify it in [`snapshotSerializers`](/config/snapshotserializers): 631 631 632 632 ```js [vitest.config.js] 633 633 import { defineConfig } from 'vitest/config' ··· 811 811 812 812 ### Key Differences 813 813 814 814 - 1. **Globals**: Mocha provides globals by default. In Vitest, either import from `vitest` or enable [`globals`](/config/#globals) config 814 814 + 1. **Globals**: Mocha provides globals by default. In Vitest, either import from `vitest` or enable [`globals`](/config/globals) config 815 815 2. **Assertion style**: You can use both Chai-style (`expect(spy).to.have.been.called`) and Jest-style (`expect(spy).toHaveBeenCalled()`) 816 816 3. **Parallel execution**: Vitest runs tests in parallel by default, Mocha runs sequentially 817 817

+3 -3

docs/guide/mocking.md

Reviewed

··· 5 5 6 6 # Mocking 7 7 8 8 - When writing tests it's only a matter of time before you need to create a "fake" version of an internal — or external — service. This is commonly referred to as **mocking**. Vitest provides utility functions to help you out through its `vi` helper. You can import it from `vitest` or access it globally if [`global` configuration](/config/#globals) is enabled. 8 8 + When writing tests it's only a matter of time before you need to create a "fake" version of an internal — or external — service. This is commonly referred to as **mocking**. Vitest provides utility functions to help you out through its `vi` helper. You can import it from `vitest` or access it globally if [`global` configuration](/config/globals) is enabled. 9 9 10 10 ::: warning 11 11 Always remember to clear or restore mocks before or after each test run to undo mock state changes between runs! See [`mockReset`](/api/mock#mockreset) docs for more info. ··· 182 182 183 183 ### Mock a global variable 184 184 185 185 - You can set global variable by assigning a value to `globalThis` or using [`vi.stubGlobal`](/api/vi#vi-stubglobal) helper. When using `vi.stubGlobal`, it will **not** automatically reset between different tests, unless you enable [`unstubGlobals`](/config/#unstubglobals) config option or call [`vi.unstubAllGlobals`](/api/vi#vi-unstuballglobals). 185 185 + You can set global variable by assigning a value to `globalThis` or using [`vi.stubGlobal`](/api/vi#vi-stubglobal) helper. When using `vi.stubGlobal`, it will **not** automatically reset between different tests, unless you enable [`unstubGlobals`](/config/unstubglobals) config option or call [`vi.unstubAllGlobals`](/api/vi#vi-unstuballglobals). 186 186 187 187 ```ts 188 188 vi.stubGlobal('__VERSION__', '1.0.0') ··· 213 213 }) 214 214 ``` 215 215 216 216 - 2. If you want to automatically reset the value(s), you can use the `vi.stubEnv` helper with the [`unstubEnvs`](/config/#unstubenvs) config option enabled (or call [`vi.unstubAllEnvs`](/api/vi#vi-unstuballenvs) manually in a `beforeEach` hook): 216 216 + 2. If you want to automatically reset the value(s), you can use the `vi.stubEnv` helper with the [`unstubEnvs`](/config/unstubenvs) config option enabled (or call [`vi.unstubAllEnvs`](/api/vi#vi-unstuballenvs) manually in a `beforeEach` hook): 217 217 218 218 ```ts 219 219 import { expect, it, vi } from 'vitest'

+4 -4

docs/guide/parallelism.md

Reviewed

··· 12 12 - `forks` (the default) and `vmForks` run tests in different [child processes](https://nodejs.org/api/child_process.html) 13 13 - `threads` and `vmThreads` run tests in different [worker threads](https://nodejs.org/api/worker_threads.html) 14 14 15 15 - Both "child processes" and "worker threads" are referred to as "workers". You can configure the number of running workers with [`maxWorkers`](/config/#maxworkers) option. 15 15 + Both "child processes" and "worker threads" are referred to as "workers". You can configure the number of running workers with [`maxWorkers`](/config/maxworkers) option. 16 16 17 17 - If you have a lot of tests, it is usually faster to run them in parallel, but it also depends on the project, the environment and [isolation](/config/#isolate) state. To disable file parallelisation, you can set [`fileParallelism`](/config/#fileparallelism) to `false`. To learn more about possible performance improvements, read the [Performance Guide](/guide/improving-performance). 17 17 + If you have a lot of tests, it is usually faster to run them in parallel, but it also depends on the project, the environment and [isolation](/config/isolate) state. To disable file parallelisation, you can set [`fileParallelism`](/config/fileparallelism) to `false`. To learn more about possible performance improvements, read the [Performance Guide](/guide/improving-performance). 18 18 19 19 ## Test Parallelism 20 20 21 21 Unlike _test files_, Vitest runs _tests_ in sequence. This means that tests inside a single test file will run in the order they are defined. 22 22 23 23 - Vitest supports the [`concurrent`](/api/test#test-concurrent) option to run tests together. If this option is set, Vitest will group concurrent tests in the same _file_ (the number of simultaneously running tests depends on the [`maxConcurrency`](/config/#maxconcurrency) option) and run them with [`Promise.all`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all). 23 23 + Vitest supports the [`concurrent`](/api/test#test-concurrent) option to run tests together. If this option is set, Vitest will group concurrent tests in the same _file_ (the number of simultaneously running tests depends on the [`maxConcurrency`](/config/maxconcurrency) option) and run them with [`Promise.all`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all). 24 24 25 25 Vitest doesn't perform any smart analysis and doesn't create additional workers to run these tests. This means that the performance of your tests will improve only if you rely heavily on asynchronous operations. For example, these tests will still run one after another even though the `concurrent` option is specified. This is because they are synchronous: 26 26 ··· 34 34 }) 35 35 ``` 36 36 37 37 - If you wish to run all tests concurrently, you can set the [`sequence.concurrent`](/config/#sequence-concurrent) option to `true`. 37 37 + If you wish to run all tests concurrently, you can set the [`sequence.concurrent`](/config/sequence#sequence-concurrent) option to `true`.

+3 -3

docs/guide/profiling-test-performance.md

Reviewed

··· 19 19 - Setup: Time spent for running the [`setupFiles`](/config/setupfiles) files. 20 20 - Import: Time it took to import your test files and their dependencies. This also includes the time spent collecting all tests. Note that this doesn't include dynamic imports inside of tests. 21 21 - Tests: Time spent for actually running the test cases. 22 22 - - Environment: Time spent for setting up the test [`environment`](/config/#environment), for example JSDOM. 22 22 + - Environment: Time spent for setting up the test [`environment`](/config/environment), for example JSDOM. 23 23 24 24 ## Test Runner 25 25 ··· 57 57 58 58 ## Main Thread 59 59 60 60 - Profiling main thread is useful for debugging Vitest's Vite usage and [`globalSetup`](/config/#globalsetup) files. 60 60 + Profiling main thread is useful for debugging Vitest's Vite usage and [`globalSetup`](/config/globalsetup) files. 61 61 This is also where your Vite plugins are running. 62 62 63 63 :::tip ··· 150 150 151 151 This profiling approach is great for detecting large files that are accidentally picked by coverage providers. 152 152 For example if your configuration is accidentally including large built minified Javascript files in code coverage, they should appear in logs. 153 153 - In these cases you might want to adjust your [`coverage.include`](/config/#coverage-include) and [`coverage.exclude`](/config/#coverage-exclude) options. 153 153 + In these cases you might want to adjust your [`coverage.include`](/config/coverage#coverage-include) and [`coverage.exclude`](/config/coverage#coverage-exclude) options. 154 154 155 155 ## Inspecting Profiling Records 156 156

+5 -5

docs/guide/reporters.md

Reviewed

··· 5 5 6 6 # Reporters 7 7 8 8 - Vitest provides several built-in reporters to display test output in different formats, as well as the ability to use custom reporters. You can select different reporters either by using the `--reporter` command line option, or by including a `reporters` property in your [configuration file](/config/#reporters). If no reporter is specified, Vitest will use the `default` reporter as described below. 8 8 + Vitest provides several built-in reporters to display test output in different formats, as well as the ability to use custom reporters. You can select different reporters either by using the `--reporter` command line option, or by including a `reporters` property in your [configuration file](/config/reporters). If no reporter is specified, Vitest will use the `default` reporter as described below. 9 9 10 10 Using reporters via command line: 11 11 ··· 40 40 41 41 ## Reporter Output 42 42 43 43 - By default, Vitest's reporters will print their output to the terminal. When using the `json`, `html` or `junit` reporters, you can instead write your tests' output to a file by including an `outputFile` [configuration option](/config/#outputfile) either in your Vite configuration file or via CLI. 43 43 + By default, Vitest's reporters will print their output to the terminal. When using the `json`, `html` or `junit` reporters, you can instead write your tests' output to a file by including an `outputFile` [configuration option](/config/outputfile) either in your Vite configuration file or via CLI. 44 44 45 45 :::code-group 46 46 ```bash [CLI] ··· 294 294 295 295 ### JUnit Reporter 296 296 297 297 - Outputs a report of the test results in JUnit XML format. Can either be printed to the terminal or written to an XML file using the [`outputFile`](/config/#outputfile) configuration option. 297 297 + Outputs a report of the test results in JUnit XML format. Can either be printed to the terminal or written to an XML file using the [`outputFile`](/config/outputfile) configuration option. 298 298 299 299 :::code-group 300 300 ```bash [CLI] ··· 345 345 346 346 ### JSON Reporter 347 347 348 348 - Generates a report of the test results in a JSON format compatible with Jest's `--json` option. Can either be printed to the terminal or written to a file using the [`outputFile`](/config/#outputfile) configuration option. 348 348 + Generates a report of the test results in a JSON format compatible with Jest's `--json` option. Can either be printed to the terminal or written to a file using the [`outputFile`](/config/outputfile) configuration option. 349 349 350 350 :::code-group 351 351 ```bash [CLI] ··· 417 417 418 418 Generates an HTML file to view test results through an interactive [GUI](/guide/ui). After the file has been generated, Vitest will keep a local development server running and provide a link to view the report in a browser. 419 419 420 420 - Output file can be specified using the [`outputFile`](/config/#outputfile) configuration option. If no `outputFile` option is provided, a new HTML file will be created. 420 420 + Output file can be specified using the [`outputFile`](/config/outputfile) configuration option. If no `outputFile` option is provided, a new HTML file will be created. 421 421 422 422 :::code-group 423 423 ```bash [CLI]

+1 -1

docs/guide/snapshot.md

Reviewed

··· 136 136 }) 137 137 ``` 138 138 139 139 - We also support [snapshotSerializers](/config/#snapshotserializers) option to implicitly add custom serializers. 139 139 + We also support [snapshotSerializers](/config/snapshotserializers) option to implicitly add custom serializers. 140 140 141 141 ```ts [path/to/custom-serializer.ts] 142 142 import { SnapshotSerializer } from 'vitest'

+4 -4

docs/guide/test-context.md

Reviewed

··· 94 94 ): Promise<TestAnnotation> 95 95 ``` 96 96 97 97 - Add a [test annotation](/guide/test-annotations) that will be displayed by your [reporter](/config/#reporters). 97 97 + Add a [test annotation](/guide/test-annotations) that will be displayed by your [reporter](/config/reporters). 98 98 99 99 ```ts 100 100 test('annotations API', async ({ annotate }) => { ··· 109 109 - Test times out 110 110 - User manually cancelled the test run with Ctrl+C 111 111 - [`vitest.cancelCurrentRun`](/api/advanced/vitest#cancelcurrentrun) was called programmatically 112 112 - - Another test failed in parallel and the [`bail`](/config/#bail) flag is set 112 112 + - Another test failed in parallel and the [`bail`](/config/bail) flag is set 113 113 114 114 ```ts 115 115 it('stop request when test times out', async ({ signal }) => { ··· 568 568 ``` 569 569 570 570 ::: info 571 571 - By default, every file runs in a separate worker, so `file` and `worker` scopes work the same way. However, if you disable [isolation](/config/#isolate), then the number of workers is limited by [`maxWorkers`](/config/#maxworkers), and worker-scoped fixtures will be shared across files running in the same worker. 571 571 + By default, every file runs in a separate worker, so `file` and `worker` scopes work the same way. However, if you disable [isolation](/config/isolate), then the number of workers is limited by [`maxWorkers`](/config/maxworkers), and worker-scoped fixtures will be shared across files running in the same worker. 572 572 573 573 When running tests in `vmThreads` or `vmForks`, `scope: 'worker'` works the same way as `scope: 'file'` because each file has its own VM context. 574 574 ::: ··· 640 640 641 641 ### Default Fixture (Injected) 642 642 643 643 - Since Vitest 3, you can provide different values in different [projects](/guide/projects). To enable this, pass `{ injected: true }` in the options. If the key is not specified in the [project configuration](/config/#provide), the default value will be used. 643 643 + Since Vitest 3, you can provide different values in different [projects](/guide/projects). To enable this, pass `{ injected: true }` in the options. If the key is not specified in the [project configuration](/config/provide), the default value will be used. 644 644 645 645 :::code-group 646 646 ```ts [fixtures.test.ts]

+4 -4

docs/guide/testing-types.md

Reviewed

··· 10 10 11 11 ::: 12 12 13 13 - Vitest allows you to write tests for your types, using `expectTypeOf` or `assertType` syntaxes. By default all tests inside `*.test-d.ts` files are considered type tests, but you can change it with [`typecheck.include`](/config/#typecheck-include) config option. 13 13 + Vitest allows you to write tests for your types, using `expectTypeOf` or `assertType` syntaxes. By default all tests inside `*.test-d.ts` files are considered type tests, but you can change it with [`typecheck.include`](/config/typecheck#typecheck-include) config option. 14 14 15 15 - Under the hood Vitest calls `tsc` or `vue-tsc`, depending on your config, and parses results. Vitest will also print out type errors in your source code, if it finds any. You can disable it with [`typecheck.ignoreSourceErrors`](/config/#typecheck-ignoresourceerrors) config option. 15 15 + Under the hood Vitest calls `tsc` or `vue-tsc`, depending on your config, and parses results. Vitest will also print out type errors in your source code, if it finds any. You can disable it with [`typecheck.ignoreSourceErrors`](/config/typecheck#typecheck-ignoresourceerrors) config option. 16 16 17 17 Keep in mind that Vitest doesn't run these files, they are only statically analyzed by the compiler. Meaning, that if you use a dynamic name or `test.each` or `test.for`, the test name will not be evaluated - it will be displayed as is. 18 18 ··· 111 111 ``` 112 112 113 113 ::: tip 114 114 - When using `@ts-expect-error` syntax, you might want to make sure that you didn't make a typo. You can do that by including your type files in [`test.include`](/config/#include) config option, so Vitest will also actually *run* these tests and fail with `ReferenceError`. 114 114 + When using `@ts-expect-error` syntax, you might want to make sure that you didn't make a typo. You can do that by including your type files in [`test.include`](/config/include) config option, so Vitest will also actually *run* these tests and fail with `ReferenceError`. 115 115 116 116 This will pass, because it expects an error, but the word “answer” has a typo, so it's a false positive error: 117 117 ··· 123 123 124 124 ## Run Typechecking 125 125 126 126 - To enable typechecking, just add [`--typecheck`](/config/#typecheck) flag to your Vitest command in `package.json`: 126 126 + To enable typechecking, just add [`--typecheck`](/config/typecheck) flag to your Vitest command in `package.json`: 127 127 128 128 ```json [package.json] 129 129 {

+1 -1

docs/guide/ui.md

Reviewed

··· 50 50 npx vite preview --outDir ./html 51 51 ``` 52 52 53 53 - You can configure output with [`outputFile`](/config/#outputfile) config option. You need to specify `.html` path there. For example, `./html/index.html` is the default value. 53 53 + You can configure output with [`outputFile`](/config/outputfile) config option. You need to specify `.html` path there. For example, `./html/index.html` is the default value. 54 54 ::: 55 55 56 56 ## Module Graph

+1 -1

docs/api/advanced/artifacts.md

Reviewed

··· 21 21 - Optional attachments, either files or inline content associated with the artifact 22 22 - A source code location indicating where the artifact was created 23 23 24 24 - Vitest automatically manages attachment serialization (files are copied to [`attachmentsDir`](/config/#attachmentsdir)) and injects source location metadata, so you can focus on the data you want to record. All artifacts **must** extend from [`TestArtifactBase`](#testartifactbase) and all attachments from [`TestAttachment`](#testattachment) to be correctly handled internally. 24 24 + Vitest automatically manages attachment serialization (files are copied to [`attachmentsDir`](/config/attachmentsdir)) and injects source location metadata, so you can focus on the data you want to record. All artifacts **must** extend from [`TestArtifactBase`](#testartifactbase) and all attachments from [`TestAttachment`](#testattachment) to be correctly handled internally. 25 25 26 26 ## API 27 27

+3 -3

docs/api/advanced/reporters.md

Reviewed

··· 140 140 - `failed`: test run has at least one error (due to a syntax error during collection or an actual error during test execution) 141 141 - `interrupted`: test was interrupted by [`vitest.cancelCurrentRun`](/api/advanced/vitest#cancelcurrentrun) call or `Ctrl+C` was pressed in the terminal (note that it's still possible to have failed tests in this case) 142 142 143 143 - If Vitest didn't find any test files to run, this event will be invoked with empty arrays of modules and errors, and the state will depend on the value of [`config.passWithNoTests`](/config/#passwithnotests). 143 143 + If Vitest didn't find any test files to run, this event will be invoked with empty arrays of modules and errors, and the state will depend on the value of [`config.passWithNoTests`](/config/passwithnotests). 144 144 145 145 ::: details Example 146 146 ```ts ··· 324 324 325 325 The `onTestCaseAnnotate` hook is associated with the [`context.annotate`](/guide/test-context#annotate) method. When `annotate` is invoked, Vitest serialises it and sends the same attachment to the main thread where reporter can interact with it. 326 326 327 327 - If the path is specified, Vitest stores it in a separate directory (configured by [`attachmentsDir`](/config/#attachmentsdir)) and modifies the `path` property to reference it. 327 327 + If the path is specified, Vitest stores it in a separate directory (configured by [`attachmentsDir`](/config/attachmentsdir)) and modifies the `path` property to reference it. 328 328 329 329 ## onTestCaseArtifactRecord <Version type="experimental">4.0.11</Version> {#ontestcaseartifactrecord} 330 330 ··· 337 337 338 338 The `onTestCaseArtifactRecord` hook is associated with the [`recordArtifact`](/api/advanced/artifacts#recordartifact) utility. When `recordArtifact` is invoked, Vitest serialises it and sends the same attachment to the main thread where reporter can interact with it. 339 339 340 340 - If the path is specified, Vitest stores it in a separate directory (configured by [`attachmentsDir`](/config/#attachmentsdir)) and modifies the `path` property to reference it. 340 340 + If the path is specified, Vitest stores it in a separate directory (configured by [`attachmentsDir`](/config/attachmentsdir)) and modifies the `path` property to reference it. 341 341 342 342 Note: annotations, [even though they're built on top of this feature](/api/advanced/artifacts#relationship-with-annotations), won't hit this hook and won't appear in the `task.artifacts` array for backwards compatibility reasons until the next major version.

+1 -1

docs/api/advanced/test-case.md

Reviewed

··· 79 79 80 80 ## location 81 81 82 82 - The location in the module where the test was defined. Locations are collected only if [`includeTaskLocation`](/config/#includetasklocation) is enabled in the config. Note that this option is automatically enabled if `--reporter=html`, `--ui` or `--browser` flags are used. 82 82 + The location in the module where the test was defined. Locations are collected only if [`includeTaskLocation`](/config/includetasklocation) is enabled in the config. Note that this option is automatically enabled if `--reporter=html`, `--ui` or `--browser` flags are used. 83 83 84 84 The location of this test will be equal to `{ line: 3, column: 1 }`: 85 85

+3 -3

docs/api/advanced/test-project.md

Reviewed

··· 117 117 ): void 118 118 ``` 119 119 120 120 - A way to provide custom values to tests in addition to [`config.provide`](/config/#provide) field. All values are validated with [`structuredClone`](https://developer.mozilla.org/en-US/docs/Web/API/Window/structuredClone) before they are stored, but the values on `providedContext` themselves are not cloned. 120 120 + A way to provide custom values to tests in addition to [`config.provide`](/config/provide) field. All values are validated with [`structuredClone`](https://developer.mozilla.org/en-US/docs/Web/API/Window/structuredClone) before they are stored, but the values on `providedContext` themselves are not cloned. 121 121 122 122 ::: code-group 123 123 ```ts [node.js] ··· 137 137 The values can be provided dynamically. Provided value in tests will be updated on their next run. 138 138 139 139 ::: tip 140 140 - This method is also available to [global setup files](/config/#globalsetup) for cases where you cannot use the public API: 140 140 + This method is also available to [global setup files](/config/globalsetup) for cases where you cannot use the public API: 141 141 142 142 ```js 143 143 export default function setup({ provide }) { ··· 179 179 ): TestSpecification 180 180 ``` 181 181 182 182 - Create a [test specification](/api/advanced/test-specification) that can be used in [`vitest.runTestSpecifications`](/api/advanced/vitest#runtestspecifications). Specification scopes the test file to a specific `project` and test `locations` (optional). Test [locations](/api/advanced/test-case#location) are code lines where the test is defined in the source code. If locations are provided, Vitest will only run tests defined on those lines. Note that if [`testNamePattern`](/config/#testnamepattern) is defined, then it will also be applied. 182 182 + Create a [test specification](/api/advanced/test-specification) that can be used in [`vitest.runTestSpecifications`](/api/advanced/vitest#runtestspecifications). Specification scopes the test file to a specific `project` and test `locations` (optional). Test [locations](/api/advanced/test-case#location) are code lines where the test is defined in the source code. If locations are provided, Vitest will only run tests defined on those lines. Note that if [`testNamePattern`](/config/testnamepattern) is defined, then it will also be applied. 183 183 184 184 ```ts 185 185 import { createVitest } from 'vitest/node'

+2 -2

docs/api/advanced/test-specification.md

Reviewed

··· 42 42 43 43 ## pool {#pool} 44 44 45 45 - The [`pool`](/config/#pool) in which the test module will run. 45 45 + The [`pool`](/config/pool) in which the test module will run. 46 46 47 47 ::: danger 48 48 - It's possible to have multiple pools in a single test project with [`typecheck.enabled`](/config/#typecheck-enabled). This means it's possible to have several specifications with the same `moduleId` but different `pool`. In later versions, the project will only support a single pool. 48 48 + It's possible to have multiple pools in a single test project with [`typecheck.enabled`](/config/typecheck#typecheck-enabled). This means it's possible to have several specifications with the same `moduleId` but different `pool`. In later versions, the project will only support a single pool. 49 49 ::: 50 50 51 51 ## testLines

+1 -1

docs/api/advanced/test-suite.md

Reviewed

··· 80 80 81 81 ## location 82 82 83 83 - The location in the module where the suite was defined. Locations are collected only if [`includeTaskLocation`](/config/#includetasklocation) is enabled in the config. Note that this option is automatically enabled if `--reporter=html`, `--ui` or `--browser` flags are used. 83 83 + The location in the module where the suite was defined. Locations are collected only if [`includeTaskLocation`](/config/includetasklocation) is enabled in the config. Note that this option is automatically enabled if `--reporter=html`, `--ui` or `--browser` flags are used. 84 84 85 85 The location of this suite will be equal to `{ line: 3, column: 1 }`: 86 86

+4 -4

docs/api/advanced/vitest.md

Reviewed

··· 357 357 function setGlobalTestNamePattern(pattern: string | RegExp): void 358 358 ``` 359 359 360 360 - This methods overrides the global [test name pattern](/config/#testnamepattern). 360 360 + This methods overrides the global [test name pattern](/config/testnamepattern). 361 361 362 362 ::: warning 363 363 This method doesn't start running any tests. To run tests with updated pattern, call [`runTestSpecifications`](#runtestspecifications). ··· 377 377 function resetGlobalTestNamePattern(): void 378 378 ``` 379 379 380 380 - This methods resets the [test name pattern](/config/#testnamepattern). It means Vitest won't skip any tests now. 380 380 + This methods resets the [test name pattern](/config/testnamepattern). It means Vitest won't skip any tests now. 381 381 382 382 ::: warning 383 383 This method doesn't start running any tests. To run tests without a pattern, call [`runTestSpecifications`](#runtestspecifications). ··· 452 452 453 453 Closes all projects and exit the process. If `force` is set to `true`, the process will exit immediately after closing the projects. 454 454 455 455 - This method will also forcefully call `process.exit()` if the process is still active after [`config.teardownTimeout`](/config/#teardowntimeout) milliseconds. 455 455 + This method will also forcefully call `process.exit()` if the process is still active after [`config.teardownTimeout`](/config/teardowntimeout) milliseconds. 456 456 457 457 ## shouldKeepServer 458 458 ··· 548 548 Creates a coverage provider if `coverage` is enabled in the config. This is done automatically if you are running tests with [`start`](#start) or [`init`](#init) methods. 549 549 550 550 ::: warning 551 551 - This method will also clean all previous reports if [`coverage.clean`](/config/#coverage-clean) is not set to `false`. 551 551 + This method will also clean all previous reports if [`coverage.clean`](/config/coverage#coverage-clean) is not set to `false`. 552 552 ::: 553 553 554 554 ## enableCoverage <Version>4.0.0</Version> {#enablecoverage}

+3 -3

docs/config/browser/expect.md

Reviewed

··· 98 98 99 99 - `root: string` 100 100 101 101 - Absolute path to the project's [`root`](/config/#root). 101 101 + Absolute path to the project's [`root`](/config/root). 102 102 103 103 - `testFileDirectory: string` 104 104 105 105 - Path to the test file, relative to the project's [`root`](/config/#root). 105 105 + Path to the test file, relative to the project's [`root`](/config/root). 106 106 107 107 - `testFileName: string` 108 108 ··· 115 115 116 116 - `attachmentsDir: string` 117 117 118 118 - The value provided to [`attachmentsDir`](/config/#attachmentsdir), if none is 118 118 + The value provided to [`attachmentsDir`](/config/attachmentsdir), if none is 119 119 provided, its default value. 120 120 121 121 For example, to group screenshots by browser:

+2 -2

docs/config/browser/isolate.md

Reviewed

··· 6 6 # browser.isolate <Deprecated /> 7 7 8 8 - **Type:** `boolean` 9 9 - - **Default:** the same as [`--isolate`](/config/#isolate) 9 9 + - **Default:** the same as [`--isolate`](/config/isolate) 10 10 - **CLI:** `--browser.isolate`, `--browser.isolate=false` 11 11 12 12 Run every test in a separate iframe. 13 13 14 14 ::: danger DEPRECATED 15 15 - This option is deprecated. Use [`isolate`](/config/#isolate) instead. 15 15 + This option is deprecated. Use [`isolate`](/config/isolate) instead. 16 16 :::

+1 -1

docs/config/browser/trackunhandlederrors.md

Reviewed

··· 10 10 11 11 Enables tracking uncaught errors and exceptions so they can be reported by Vitest. 12 12 13 13 - If you need to hide certain errors, it is recommended to use [`onUnhandledError`](/config/#onunhandlederror) option instead. 13 13 + If you need to hide certain errors, it is recommended to use [`onUnhandledError`](/config/onunhandlederror) option instead. 14 14 15 15 Disabling this will completely remove all Vitest error handlers, which can help debugging with the "Pause on exceptions" checkbox turned on.

+2 -2

docs/guide/browser/index.md

Reviewed

··· 118 118 ``` 119 119 120 120 ::: info 121 121 - Vitest assigns port `63315` to avoid conflicts with the development server, allowing you to run both in parallel. You can change that with the [`browser.api`](/config/#browser-api) option. 121 121 + Vitest assigns port `63315` to avoid conflicts with the development server, allowing you to run both in parallel. You can change that with the [`browser.api`](/config/browser/api) option. 122 122 123 123 The CLI does not print the Vite server URL automatically. You can press "b" to print the URL when running in watch mode. 124 124 ::: ··· 328 328 Since Vitest 3.2, if you don't have the `browser` option in your config but specify the `--browser` flag, Vitest will fail because it can't assume that config is meant for the browser and not Node.js tests. 329 329 ::: 330 330 331 331 - By default, Vitest will automatically open the browser UI for development. Your tests will run inside an iframe in the center. You can configure the viewport by selecting the preferred dimensions, calling `page.viewport` inside the test, or setting default values in [the config](/config/#browser-viewport). 331 331 + By default, Vitest will automatically open the browser UI for development. Your tests will run inside an iframe in the center. You can configure the viewport by selecting the preferred dimensions, calling `page.viewport` inside the test, or setting default values in [the config](/config/browser/viewport). 332 332 333 333 ## Headless 334 334

+1 -1

docs/guide/browser/multiple-setups.md

Reviewed

··· 74 74 ``` 75 75 ::: 76 76 77 77 - In this example Vitest will run all tests in `chromium` browser, but execute a `'./ratio-setup.ts'` file only in the first configuration and inject a different `ratio` value depending on the [`provide` field](/config/#provide). 77 77 + In this example Vitest will run all tests in `chromium` browser, but execute a `'./ratio-setup.ts'` file only in the first configuration and inject a different `ratio` value depending on the [`provide` field](/config/provide). 78 78 79 79 ::: warning 80 80 Note that you need to define the custom `name` value if you are using the same browser name because Vitest will assign the `browser` as the project name otherwise.

+1 -1

docs/guide/mocking/globals.md

Reviewed

··· 2 2 3 3 You can mock global variables that are not present with `jsdom` or `node` by using [`vi.stubGlobal`](/api/vi#vi-stubglobal) helper. It will put the value of the global variable into a `globalThis` object. 4 4 5 5 - By default, Vitest does not reset these globals, but you can turn on the [`unstubGlobals`](/config/#unstubglobals) option in your config to restore the original values after each test or call [`vi.unstubAllGlobals()`](/api/vi#vi-unstuballglobals) manually. 5 5 + By default, Vitest does not reset these globals, but you can turn on the [`unstubGlobals`](/config/unstubglobals) option in your config to restore the original values after each test or call [`vi.unstubAllGlobals()`](/api/vi#vi-unstuballglobals) manually. 6 6 7 7 ```ts 8 8 import { vi } from 'vitest'

+1 -1

docs/guide/mocking/modules.md

Reviewed

··· 236 236 237 237 By default, Vitest will fail transforming files if it cannot find the source of the import. To bypass this, you need to specify it in your config. You can either always redirect the import to a file, or just signal Vite to ignore it and use the `vi.mock` factory to define its exports. 238 238 239 239 - To redirect the import, use [`test.alias`](/config/#alias) config option: 239 239 + To redirect the import, use [`test.alias`](/config/alias) config option: 240 240 241 241 ```ts [vitest.config.ts] 242 242 import { defineConfig } from 'vitest/config'

+2 -2

packages/vitest/src/node/cli/cli-config.ts

Reviewed

··· 193 193 }, 194 194 reporter: { 195 195 description: 196 196 - 'Coverage reporters to use. Visit [`coverage.reporter`](https://vitest.dev/config/#coverage-reporter) for more information (default: `["text", "html", "clover", "json"]`)', 196 196 + 'Coverage reporters to use. Visit [`coverage.reporter`](https://vitest.dev/config/coverage#coverage-reporter) for more information (default: `["text", "html", "clover", "json"]`)', 197 197 argument: '<name>', 198 198 subcommands: null, // don't support custom objects 199 199 array: true, ··· 485 485 }, 486 486 hooks: { 487 487 description: 488 488 - 'Changes the order in which hooks are executed. Accepted values are: "stack", "list" and "parallel". Visit [`sequence.hooks`](https://vitest.dev/config/#sequence-hooks) for more information (default: `"parallel"`)', 488 488 + 'Changes the order in which hooks are executed. Accepted values are: "stack", "list" and "parallel". Visit [`sequence.hooks`](https://vitest.dev/config/sequence#sequence-hooks) for more information (default: `"parallel"`)', 489 489 argument: '<order>', 490 490 }, 491 491 setupFiles: {