+2 -2

docs/.vitepress/config.ts

Reviewed

··· 198 198 link: '/guide/browser', 199 199 }, 200 200 { 201 201 - text: 'In-source Testing', 201 201 + text: 'In-Source Testing', 202 202 link: '/guide/in-source', 203 203 }, 204 204 { ··· 259 259 link: '/api/expect-typeof', 260 260 }, 261 261 { 262 262 - text: 'assertType', 262 262 + text: 'AssertType', 263 263 link: '/api/assert-type', 264 264 }, 265 265 ],

+2 -2

docs/advanced/api.md

Reviewed

··· 1 1 # Node API 2 2 3 3 ::: warning 4 4 - Vitest exposes experimental private API. Breaking changes might not follow semver, please pin Vitest's version when using it. 4 4 + Vitest exposes experimental private API. Breaking changes might not follow SemVer, please pin Vitest's version when using it. 5 5 ::: 6 6 7 7 ## startVitest ··· 18 18 19 19 `startVitest` function returns `Vitest` instance if tests can be started. It returns `undefined`, if one of the following occurs: 20 20 21 21 - - Vitest didn't find "vite" package (usually installed with Vitest) 21 21 + - Vitest didn't find the `vite` package (usually installed with Vitest) 22 22 - If coverage is enabled and run mode is "test", but the coverage package is not installed (`@vitest/coverage-v8` or `@vitest/coverage-istanbul`) 23 23 - If the environment package is not installed (`jsdom`/`happy-dom`/`@edge-runtime/vm`) 24 24

+2 -2

docs/advanced/metadata.md

Reviewed

··· 1 1 # Task Metadata 2 2 3 3 ::: warning 4 4 - Vitest exposes experimental private API. Breaking changes might not follow semver, please pin Vitest's version when using it. 4 4 + Vitest exposes experimental private API. Breaking changes might not follow SemVer, please pin Vitest's version when using it. 5 5 ::: 6 6 7 7 If you are developing a custom reporter or using Vitest Node.js API, you might find it useful to pass data from tests that are being executed in various contexts to your reporter or custom Vitest handler. ··· 71 71 custom?: string 72 72 } 73 73 } 74 74 - ``` 74 74 + ```

+1 -1

docs/advanced/pool.md

Reviewed

··· 55 55 56 56 If you are using a custom pool, you will have to provide test files and their results yourself - you can reference [`vitest.state`](https://github.com/vitest-dev/vitest/blob/feat/custom-pool/packages/vitest/src/node/state.ts) for that (most important are `collectFiles` and `updateTasks`). Vitest uses `startTests` function from `@vitest/runner` package to do that. 57 57 58 58 - To communicate between different processes, you can create methods object using `createMethodsRPC` from `vitest/node`, and use any form of communication that you prefer. For example, to use websockets with `birpc` you can write something like this: 58 58 + To communicate between different processes, you can create methods object using `createMethodsRPC` from `vitest/node`, and use any form of communication that you prefer. For example, to use WebSockets with `birpc` you can write something like this: 59 59 60 60 ```ts 61 61 import { createBirpc } from 'birpc'

+1 -1

docs/advanced/runner.md

Reviewed

··· 106 106 Snapshot support and some other features depend on the runner. If you don't want to lose it, you can extend your runner from `VitestTestRunner` imported from `vitest/runners`. It also exposes `BenchmarkNodeRunner`, if you want to extend benchmark functionality. 107 107 ::: 108 108 109 109 - ## Your task function 109 109 + ## Your Task Function 110 110 111 111 You can extend Vitest task system with your tasks. A task is an object that is part of a suite. It is automatically added to the current suite with a `suite.task` method: 112 112

+2 -2

docs/api/expect.md

Reviewed

··· 19 19 expect(input).toBe(2) // jest API 20 20 ``` 21 21 22 22 - Technically this example doesn't use [`test`](/api/#test) function, so in the console you will see Nodejs error instead of Vitest output. To learn more about `test`, please read [Test API Reference](/api/). 22 22 + Technically this example doesn't use [`test`](/api/#test) function, so in the console you will see Node.js error instead of Vitest output. To learn more about `test`, please read [Test API Reference](/api/). 23 23 24 24 - Also, `expect` can be used statically to access matchers functions, described later, and more. 24 24 + Also, `expect` can be used statically to access matcher functions, described later, and more. 25 25 26 26 ::: warning 27 27 `expect` has no effect on testing types, if the expression doesn't have a type error. If you want to use Vitest as [type checker](/guide/testing-types), use [`expectTypeOf`](/api/expect-typeof) or [`assertType`](/api/assert-type).

+1 -1

docs/api/index.md

Reviewed

··· 370 370 If you want to have access to `TestContext`, use `describe.each` with a single test. 371 371 372 372 ::: tip 373 373 - 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. 373 373 + 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. 374 374 ::: 375 375 376 376 ::: warning

+1 -1

docs/api/mock.md

Reviewed

··· 244 244 245 245 Accepts a value that will be returned during the next function call. If chained, every consecutive call will return the specified value. 246 246 247 247 - When there are no more `mockReturnValueOnce` values to use, mock will fallback to preivously defined implementation if there is one. 247 247 + When there are no more `mockReturnValueOnce` values to use, mock will fallback to previously defined implementation if there is one. 248 248 249 249 ```ts 250 250 const myMockFn = vi

+5 -5

docs/api/vi.md

Reviewed

··· 150 150 151 151 - **Type**: `(path: string, factory?: (importOriginal: () => unknown) => unknown) => void` 152 152 153 153 - The same as [`vi.mock`](#vi-mock), but it's not hoisted to the top of the file, so you can reference variables in the global file scope. The next [dynamic import](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import) of the module will be mocked. 153 153 + The same as [`vi.mock`](#vi-mock), but it's not hoisted to the top of the file, so you can reference variables in the global file scope. The next [dynamic import](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import) of the module will be mocked. 154 154 155 155 ::: warning 156 156 This will not mock modules that were imported before this was called. Don't forget that all static imports in ESM are always [hoisted](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#hoisting), so putting this before static import will not force it to be called before the import: ··· 333 333 ``` 334 334 335 335 ::: tip 336 336 - If during a dynamic import another dynamic import is initiated, this method will wait unti all of them are resolved. 336 336 + If during a dynamic import another dynamic import is initiated, this method will wait until all of them are resolved. 337 337 338 338 This method will also wait for the next `setTimeout` tick after the import is resolved so all synchronous operations should be completed by the time it's resolved. 339 339 ::: ··· 386 386 387 387 - **Type:** `<T, K extends keyof T>(object: T, method: K, accessType?: 'get' | 'set') => MockInstance` 388 388 389 389 - Creates a spy on a method or getter/setter of an object simillar to [`vi.fn()`](/#vi-fn). It returns a [mock function](/api/mock). 389 389 + Creates a spy on a method or getter/setter of an object similar to [`vi.fn()`](/#vi-fn). It returns a [mock function](/api/mock). 390 390 391 391 ```ts 392 392 let apples = 0 ··· 724 724 725 725 If fake timers are enabled, this method simulates a user changing the system clock (will affect date related API like `hrtime`, `performance.now` or `new Date()`) - however, it will not fire any timers. If fake timers are not enabled, this method will only mock `Date.*` calls. 726 726 727 727 - Useful if you need to test anything that depends on the current date - for example [luxon](https://github.com/moment/luxon/) calls inside your code. 727 727 + Useful if you need to test anything that depends on the current date - for example [Luxon](https://github.com/moment/luxon/) calls inside your code. 728 728 729 729 ```ts 730 730 const date = new Date(1998, 11, 19) ··· 749 749 750 750 ::: tip 751 751 Since version `0.35.0` `vi.useFakeTimers()` no longer automatically mocks `process.nextTick`. 752 752 - It can still be mocked by specyfing the option in `toFake` argument: `vi.useFakeTimers({ toFake: ['nextTick'] })`. 752 752 + It can still be mocked by specifying the option in `toFake` argument: `vi.useFakeTimers({ toFake: ['nextTick'] })`. 753 753 ::: 754 754 755 755 ### vi.isFakeTimers

+11 -11

docs/config/index.md

Reviewed

··· 65 65 ``` 66 66 67 67 ::: warning 68 68 - `mergeConfig` helper is availabe in Vitest since v0.30.0. You can import it from `vite` directly, if you use lower version. 68 68 + `mergeConfig` helper is available in Vitest since v0.30.0. You can import it from `vite` directly, if you use lower version. 69 69 ::: 70 70 71 71 - If your vite config is defined as a function, you can define the config like this: 71 71 + If your Vite config is defined as a function, you can define the config like this: 72 72 ```ts 73 73 import { defineConfig, mergeConfig } from 'vitest/config' 74 74 import viteConfig from './vite.config' ··· 138 138 - **Type:** `'inline' | boolean` 139 139 - **Default:** `'inline'` 140 140 141 141 - Inject inline sourcemap to modules. 141 141 + Inject inline source map to modules. 142 142 143 143 #### server.debug 144 144 ··· 623 623 624 624 #### threads<NonProjectOption /> 625 625 626 626 - Enable multi-threading using [tinypool](https://github.com/tinylibs/tinypool) (a lightweight fork of [Piscina](https://github.com/piscinajs/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 adviced to use `forks` pool instead. 626 626 + Enable multi-threading using [tinypool](https://github.com/tinylibs/tinypool) (a lightweight fork of [Piscina](https://github.com/piscinajs/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. 627 627 628 628 #### forks<NonProjectOption /> 629 629 ··· 959 959 ::: warning 960 960 Since Vitest 1.0.0-beta, global setup runs only if there is at least one running test. This means that global setup might start running during watch mode after test file is changed (the test file will wait for global setup to finish before running). 961 961 962 962 - Beware that the global setup is running in a different global scope, so your tests don't have access to variables defined here. Hovewer, since 1.0.0 you can pass down serializable data to tests via `provide` method: 962 962 + Beware that the global setup is running in a different global scope, so your tests don't have access to variables defined here. However, since 1.0.0 you can pass down serializable data to tests via `provide` method: 963 963 964 964 ```ts 965 965 // globalSetup.js ··· 1383 1383 ::: 1384 1384 1385 1385 ::: warning 1386 1386 - This is an experimental feature. Breaking changes might not follow semver, please pin Vitest's version when using it. 1386 1386 + This is an experimental feature. Breaking changes might not follow SemVer, please pin Vitest's version when using it. 1387 1387 ::: 1388 1388 1389 1389 #### browser.enabled ··· 1392 1392 - **Default:** `false` 1393 1393 - **CLI:** `--browser`, `--browser.enabled=false` 1394 1394 1395 1395 - Run all tests inside a browser by default. Can be overriden with [`poolMatchGlobs`](/config/#poolmatchglobs) option. 1395 1395 + Run all tests inside a browser by default. Can be overridden with [`poolMatchGlobs`](/config/#poolmatchglobs) option. 1396 1396 1397 1397 #### browser&#46;name 1398 1398 ··· 1878 1878 1879 1879 Stop test execution when given number of tests have failed. 1880 1880 1881 1881 - By default Vitest will run all of your test cases even if some of them fail. This may not be desired for CI builds where you are only interested in 100% successful builds and would like to stop test execution as early as possible when test failures occur. The `bail` option can be used to speed up CI runs by preventing it from running more tests when failures have occured. 1881 1881 + By default Vitest will run all of your test cases even if some of them fail. This may not be desired for CI builds where you are only interested in 100% successful builds and would like to stop test execution as early as possible when test failures occur. The `bail` option can be used to speed up CI runs by preventing it from running more tests when failures have occurred. 1882 1882 1883 1883 ### retry 1884 1884 ··· 1915 1915 - **Type**: `(error: Error, frame: ParsedStack) => boolean | void` 1916 1916 - **Version**: Since Vitest 1.0.0-beta.3 1917 1917 1918 1918 - Apply a filtering function to each frame of each stacktrace when handling errors. The first argument, `error`, is an object with the same properties as a standard `Error`, but it is not an actual instance. 1918 1918 + Apply a filtering function to each frame of each stack trace when handling errors. The first argument, `error`, is an object with the same properties as a standard `Error`, but it is not an actual instance. 1919 1919 1920 1920 - Can be useful for filtering out stacktrace frames from third-party libraries. 1920 1920 + Can be useful for filtering out stack trace frames from third-party libraries. 1921 1921 1922 1922 ```ts 1923 1923 import type { ParsedStack } from 'vitest' ··· 1980 1980 - **Type:** `number | Date` 1981 1981 - **Default:** `Date.now()` 1982 1982 1983 1983 - Installs fake timers with the specified unix epoch. 1983 1983 + Installs fake timers with the specified Unix epoch. 1984 1984 1985 1985 #### fakeTimers.toFake 1986 1986

+6 -5

docs/guide/browser.md

Reviewed

··· 2 2 title: Browser Mode | Guide 3 3 --- 4 4 5 5 - # Browser Mode (experimental) 5 5 + # Browser Mode <Badge type="warning">Experimental</Badge> 6 6 7 7 This page provides information about the experimental browser mode feature in the Vitest API, which allows you to run your tests in the browser natively, providing access to browser globals like window and document. This feature is currently under development, and APIs may change in the future. 8 8 ··· 10 10 11 11 We developed the Vitest browser mode feature to help improve testing workflows and achieve more accurate and reliable test results. This experimental addition to our testing API allows developers to run tests in a native browser environment. In this section, we'll explore the motivations behind this feature and its benefits for testing. 12 12 13 13 - ### Different ways of testing 13 13 + ### Different Ways of Testing 14 14 15 15 There are different ways to test JavaScript code. Some testing frameworks simulate browser environments in Node.js, while others run tests in real browsers. In this context, [jsdom](https://www.npmjs.com/package/jsdom) is an example of a spec implementation that simulates a browser environment by being used with a test runner like Jest or Vitest, while other testing tools such as [WebdriverIO](https://webdriver.io/) or [Cypress](https://www.cypress.io/) allow developers to test their applications in a real browser or in case of [Playwright](https://playwright.dev/) provide you a browser engine. 16 16 17 17 - ### The simulation caveat 17 17 + ### The Simulation Caveat 18 18 19 19 Testing JavaScript programs in simulated environments such as jsdom or happy-dom has simplified the test setup and provided an easy-to-use API, making them suitable for many projects and increasing confidence in test results. However, it is crucial to keep in mind that these tools only simulate a browser environment and not an actual browser, which may result in some discrepancies between the simulated environment and the real environment. Therefore, false positives or negatives in test results may occur. 20 20 ··· 47 47 }) 48 48 ``` 49 49 50 50 - ## Browser Option Types: 50 50 + ## Browser Option Types 51 51 52 52 The browser option in Vitest depends on the provider. Vitest will fail, if you pass `--browser` and don't specify its name in the config file. Available options: 53 53 ··· 61 61 - `webkit` 62 62 - `chromium` 63 63 64 64 - ## Cross-browser Testing: 64 64 + ## Cross-Browser Testing 65 65 66 66 When you specify a browser name in the browser option, Vitest will try to run the specified browser using [WebdriverIO](https://webdriver.io/) by default, and then run the tests there. This feature makes cross-browser testing easy to use and configure in environments like a CI. If you don't want to use WebdriverIO, you can configure the custom browser provider by using `browser.provider` option. 67 67 ··· 109 109 In this case, Vitest will run in headless mode using the Chrome browser. 110 110 111 111 ## Limitations 112 112 + 112 113 ### Thread Blocking Dialogs 113 114 114 115 When using Vitest Browser, it's important to note that thread blocking dialogs like `alert` or `confirm` cannot be used natively. This is because they block the web page, which means Vitest cannot continue communicating with the page, causing the execution to hang.

+1 -1

docs/guide/cli.md

Reviewed

··· 81 81 | `--mode` | Override Vite mode (default: `test`) | 82 82 | `--mode <name>` | Override Vite mode (default: `test`) | 83 83 | `--globals` | Inject APIs globally | 84 84 - | `--dom` | Mock browser api with happy-dom | 84 84 + | `--dom` | Mock browser API with happy-dom | 85 85 | `--browser [options]` | Run tests in [the browser](/guide/browser) (default: `false`) | 86 86 | `--environment <env>` | Runner environment (default: `node`) | 87 87 | `--passWithNoTests` | Pass when no tests found |

+5 -1

docs/guide/common-errors.md

Reviewed

··· 1 1 + --- 2 2 + title: Common Errors | Guide 3 3 + --- 4 4 + 1 5 # Common Errors 2 6 3 7 ## Cannot find module './relative-path' ··· 37 41 } 38 42 } 39 43 }) 40 40 - ``` 44 44 + ```

+15 -4

docs/guide/comparisons.md

Reviewed

··· 10 10 11 11 It is possible to use Jest in Vite setups. [@sodatea](https://twitter.com/haoqunjiang) built [vite-jest](https://github.com/sodatea/vite-jest#readme), which aims to provide first-class Vite integration for [Jest](https://jestjs.io/). The last [blockers in Jest](https://github.com/sodatea/vite-jest/blob/main/packages/vite-jest/README.md#vite-jest) have been solved, so this is a valid option for your unit tests. 12 12 13 13 - However, in a world where we have [Vite](https://vitejs.dev) providing support for the most common web tooling (typescript, JSX, most popular UI Frameworks), Jest represents a duplication of complexity. If your app is powered by Vite, having two different pipelines to configure and maintain is not justifiable. With Vitest you get to define the configuration for your dev, build and test environments as a single pipeline, sharing the same plugins and the same vite.config.js. 13 13 + However, in a world where we have [Vite](https://vitejs.dev) providing support for the most common web tooling (TypeScript, JSX, most popular UI Frameworks), Jest represents a duplication of complexity. If your app is powered by Vite, having two different pipelines to configure and maintain is not justifiable. With Vitest you get to define the configuration for your dev, build and test environments as a single pipeline, sharing the same plugins and the same vite.config.js. 14 14 15 15 - Even if your library is not using Vite (for example, if it is built with esbuild or rollup), Vitest is an interesting option as it gives you a faster run for your unit tests and a jump in DX thanks to the default watch mode using Vite instant Hot Module Reload (HMR). Vitest offers compatibility with most of the Jest API and ecosystem libraries, so in most projects, it should be a drop-in replacement for Jest. 15 15 + Even if your library is not using Vite (for example, if it is built with esbuild or Rollup), Vitest is an interesting option as it gives you a faster run for your unit tests and a jump in DX thanks to the default watch mode using Vite instant Hot Module Reload (HMR). Vitest offers compatibility with most of the Jest API and ecosystem libraries, so in most projects, it should be a drop-in replacement for Jest. 16 16 17 17 ## Cypress 18 18 ··· 40 40 41 41 ## Web Test Runner 42 42 43 43 - [@web/test-runner](https://modern-web.dev/docs/test-runner/overview/) runs tests inside a headless browser, providing the same execution environment as your web application without the need for mocking out browser APIs or the DOM. This also makes it possible to debug inside a real browser using the devtools, although there is no UI shown for stepping through the test, as there is in Cypress tests. There is a watch mode, but it is not as intelligent as that of vitest, and may not always re-run the tests you want. To use @web/test-runner with a vite project, use [@remcovaes/web-test-runner-vite-plugin](https://github.com/remcovaes/web-test-runner-vite-plugin). @web/test-runner does not include assertion or mocking libraries, so it is up to you to add them. 43 43 + [@web/test-runner](https://modern-web.dev/docs/test-runner/overview/) runs tests inside a headless browser, providing the same execution environment as your web application without the need for mocking out browser APIs or the DOM. This also makes it possible to debug inside a real browser using the devtools, although there is no UI shown for stepping through the test, as there is in Cypress tests. 44 44 + 45 45 + There is a watch mode, but it is not as intelligent as that of Vitest, and may not always re-run the tests you want. 46 46 + 47 47 + To use @web/test-runner with a Vite project, use [@remcovaes/web-test-runner-vite-plugin](https://github.com/remcovaes/web-test-runner-vite-plugin). @web/test-runner does not include assertion or mocking libraries, so it is up to you to add them. 44 48 45 49 ## uvu 46 46 - [uvu](https://github.com/lukeed/uvu) is a test runner for Node.js and the browser. It runs tests in a single thread, so tests are not isolated and can leak across files. Vitest, however, uses worker threads to isolate tests and run them in parallel. For transforming your code, uvu relies on require and loader hooks. Vitest uses [Vite](https://vitejs.dev), so files are transformed with the full power of Vite's plugin system. In a world where we have Vite providing support for the most common web tooling (typescript, JSX, most popular UI Frameworks), uvu represents a duplication of complexity. If your app is powered by Vite, having two different pipelines to configure and maintain is not justifiable. With Vitest you get to define the configuration for your dev, build and test environments as a single pipeline, sharing the same plugins and the same vite.config.js. uvu does not provide an intelligent watch mode to rerun the changed tests, while Vitest gives you amazing DX thanks to the default watch mode using Vite instant Hot Module Reload (HMR). uvu is a fast option for running simple tests, but Vitest can be faster and more reliable for more complex tests and projects. 50 50 + 51 51 + [uvu](https://github.com/lukeed/uvu) is a test runner for Node.js and the browser. It runs tests in a single thread, so tests are not isolated and can leak across files. Vitest, however, uses worker threads to isolate tests and run them in parallel. 52 52 + 53 53 + For transforming your code, uvu relies on require and loader hooks. Vitest uses [Vite](https://vitejs.dev), so files are transformed with the full power of Vite's plugin system. In a world where we have Vite providing support for the most common web tooling (TypeScript, JSX, most popular UI Frameworks), uvu represents a duplication of complexity. If your app is powered by Vite, having two different pipelines to configure and maintain is not justifiable. With Vitest you get to define the configuration for your dev, build and test environments as a single pipeline, sharing the same plugins and the same configuration. 54 54 + 55 55 + uvu does not provide an intelligent watch mode to rerun the changed tests, while Vitest gives you amazing DX thanks to the default watch mode using Vite instant Hot Module Reload (HMR). 56 56 + 57 57 + uvu is a fast option for running simple tests, but Vitest can be faster and more reliable for more complex tests and projects.

+2 -2

docs/guide/coverage.md

Reviewed

··· 118 118 119 119 Please refer to the type definition for more details. 120 120 121 121 - ## Changing the default coverage folder location 121 121 + ## Changing the Default Coverage Folder Location 122 122 123 123 When running a coverage report, a `coverage` folder is created in the root directory of your project. If you want to move it to a different directory, use the `test.coverage.reportsDirectory` property in the `vite.config.js` file. 124 124 ··· 134 134 }) 135 135 ``` 136 136 137 137 - ## Ignoring code 137 137 + ## Ignoring Code 138 138 139 139 Both coverage providers have their own ways how to ignore code from coverage reports: 140 140

+7 -7

docs/guide/debugging.md

Reviewed

··· 8 8 When debugging tests you might want to use `--test-timeout` CLI argument to prevent tests from timing out when stopping at breakpoints. 9 9 ::: 10 10 11 11 - ## VSCode 11 11 + ## VS Code 12 12 13 13 - Quick way to debug tests in VSCode is via `JavaScript Debug Terminal`. Open a new `JavaScript Debug Terminal` and run `npm run test` or `vitest` directly. *this works with any code ran in Node, so will work with most JS testing frameworks* 13 13 + Quick way to debug tests in VS Code is via `JavaScript Debug Terminal`. Open a new `JavaScript Debug Terminal` and run `npm run test` or `vitest` directly. *this works with any code ran in Node, so will work with most JS testing frameworks* 14 14 15 15  16 16 17 17 - You can also add a dedicated launch configuration to debug a test file in VSCode: 17 17 + You can also add a dedicated launch configuration to debug a test file in VS Code: 18 18 19 19 ```json 20 20 { ··· 44 44 45 45 Setting | Value 46 46 --- | --- 47 47 - Working directory | /path/to/your-project-root 48 48 - JavaScript file | ./node_modules/vitest/vitest.mjs 49 49 - Application parameters | run --pool forks 47 47 + Working directory | `/path/to/your-project-root` 48 48 + JavaScript file | `./node_modules/vitest/vitest.mjs` 49 49 + Application parameters | `run --pool forks` 50 50 51 51 Then run this configuration in debug mode. The IDE will stop at JS/TS breakpoints set in the editor. 52 52 ··· 62 62 vitest --inspect-brk --pool forks --poolOptions.forks.singleFork 63 63 ``` 64 64 65 65 - Once Vitest starts it will stop execution and waits for you to open developer tools that can connect to [NodeJS inspector](https://nodejs.org/en/docs/guides/debugging-getting-started/). You can use Chrome DevTools for this by opening `chrome://inspect` on browser. 65 65 + Once Vitest starts it will stop execution and wait for you to open developer tools that can connect to [Node.js inspector](https://nodejs.org/en/docs/guides/debugging-getting-started/). You can use Chrome DevTools for this by opening `chrome://inspect` on browser. 66 66 67 67 In watch mode you can keep the debugger open during test re-runs by using the `--poolOptions.threads.isolate false` options.

+5 -1

docs/guide/environment.md

Reviewed

··· 1 1 + --- 2 2 + title: Test Environment | Guide 3 3 + --- 4 4 + 1 5 # Test Environment 2 6 3 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. ··· 9 13 - `happy-dom` emulates browser environment by providing Browser API, and considered to be faster than jsdom, but lacks some API, uses [`happy-dom`](https://github.com/capricorn86/happy-dom) package 10 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 11 15 12 12 - ## Environments for specific files 16 16 + ## Environments for Specific Files 13 17 14 18 When setting `environment` option in your config, it will apply to all the test files in your project. To have more fine-grained control, you can use control comments to specify environment for specific files. Control comments are comments that start with `@vitest-environment` and are followed by the environment name: 15 19

+7 -7

docs/guide/features.md

Reviewed

··· 10 10 <div h-2 /> 11 11 <CourseLink href="https://vueschool.io/lessons/your-first-test?friend=vueuse">Learn how to write your first test by Video</CourseLink> 12 12 13 13 - ## Shared config between test, dev and build 13 13 + ## Shared Config between Test, Dev and Build 14 14 15 15 Vite's config, transformers, resolvers, and plugins. Use the same setup from your app to run the tests. 16 16 ··· 26 26 27 27 `vitest` starts in `watch mode` **by default in development environment** and `run mode` in CI environment (when `process.env.CI` presents) smartly. You can use `vitest watch` or `vitest run` to explicitly specify the desired mode. 28 28 29 29 - ## Common web idioms out-of-the-box 29 29 + ## Common Web Idioms Out-Of-The-Box 30 30 31 31 Out-of-the-box ES Module / TypeScript / JSX support / PostCSS 32 32 ··· 42 42 43 43 Learn more about [Test Filtering](./filtering.md). 44 44 45 45 - ## Running tests concurrently 45 45 + ## Running Tests Concurrently 46 46 47 47 Use `.concurrent` in consecutive tests to run them in parallel. 48 48 ··· 91 91 92 92 Learn more at [Snapshot](/guide/snapshot). 93 93 94 94 - ## Chai and Jest `expect` compatibility 94 94 + ## Chai and Jest `expect` Compatibility 95 95 96 96 [Chai](https://www.chaijs.com/) is built-in for assertions plus [Jest `expect`](https://jestjs.io/docs/expect)-compatible APIs. 97 97 ··· 156 156 157 157 Learn more at [Coverage](/guide/coverage). 158 158 159 159 - ## In-source testing 159 159 + ## In-Source Testing 160 160 161 161 Vitest also provides a way to run tests within your source code along with the implementation, similar to [Rust's module tests](https://doc.rust-lang.org/book/ch11-03-test-organization.html#the-tests-module-and-cfgtest). 162 162 ··· 183 183 184 184 Learn more at [In-source testing](/guide/in-source). 185 185 186 186 - ## Benchmarking ^{<code>experimental</code>} 186 186 + ## Benchmarking <Badge type="warning">Experimental</Badge> 187 187 188 188 Since Vitest 0.23.0, you can run benchmark tests with [`bench`](/api/#bench) 189 189 function via [Tinybench](https://github.com/tinylibs/tinybench) to compare performance results. ··· 208 208 }) 209 209 ``` 210 210 211 211 - ## Type Testing ^{<code>experimental</code>} 211 211 + ## Type Testing <Badge type="warning">Experimental</Badge> 212 212 213 213 Since Vitest 0.25.0 you can [write tests](/guide/testing-types) to catch type regressions. Vitest comes with [`expect-type`](https://github.com/mmkal/expect-type) package to provide you with a similar and easy to understand API. 214 214

+2 -2

docs/guide/ide.md

Reviewed

··· 4 4 5 5 # IDE Integrations 6 6 7 7 - ## VS Code ^{<code>Official</code>} 7 7 + ## VS Code <Badge>Offical</Badge> 8 8 9 9 <p text-center> 10 10 <img src="https://raw.githubusercontent.com/vitest-dev/vscode/main/img/cover.png" w-60> ··· 26 26 27 27  28 28 29 29 - ## Wallaby.js ^{<code>Paid (free for OSS)</code>} 29 29 + ## Wallaby.js <Badge>Paid (free for OSS)</Badge> 30 30 31 31 Created by [The Wallaby Team](https://wallabyjs.com) 32 32

+5 -5

docs/guide/in-source.md

Reviewed

··· 1 1 --- 2 2 - title: In-source testing | Guide 2 2 + title: In-Source Testing | Guide 3 3 --- 4 4 5 5 - # In-source testing 5 5 + # In-Source Testing 6 6 7 7 Vitest also provides a way to run tests within your source code along side the implementation, similar to [Rust's module tests](https://doc.rust-lang.org/book/ch11-03-test-organization.html#the-tests-module-and-cfgtest). 8 8 ··· 51 51 $ npx vitest 52 52 ``` 53 53 54 54 - ## Production build 54 54 + ## Production Build 55 55 56 56 For the production build, you will need to set the `define` options in your config file, letting the bundler do the dead code elimination. For example, in Vite 57 57 ··· 92 92 </details> 93 93 94 94 <details my2> 95 95 - <summary text-xl>rollup</summary> 95 95 + <summary text-xl>Rollup</summary> 96 96 97 97 ```ts 98 98 // rollup.config.js ··· 108 108 } 109 109 ``` 110 110 111 111 - Learn more: <a href="https://rollupjs.org/" target="_blank">rollup</a> 111 111 + Learn more: <a href="https://rollupjs.org/" target="_blank">Rollup</a> 112 112 113 113 </details> 114 114

+1 -1

docs/guide/index.md

Reviewed

··· 14 14 15 15 You can try Vitest online on [StackBlitz](https://vitest.new). It runs Vitest directly in the browser, and it is almost identical to the local setup but doesn't require installing anything on your machine. 16 16 17 17 - ## Adding Vitest to your Project 17 17 + ## Adding Vitest to Your Project 18 18 19 19 <CourseLink href="https://vueschool.io/lessons/how-to-install-vitest?friend=vueuse">Learn how to install by Video</CourseLink> 20 20

+3 -3

docs/guide/migration.md

Reviewed

··· 14 14 15 15 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). 16 16 17 17 - ### Module mocks 17 17 + ### Module Mocks 18 18 19 19 When mocking a module in Jest, the factory argument's return value is the default export. In Vitest, the factory argument has to return an object with each export explicitly defined. For example, the following `jest.mock` would have to be updated as follows: 20 20 ··· 31 31 32 32 Unlike Jest, mocked modules in `<root>/__mocks__` are not loaded unless `vi.mock()` is called. If you need them to be mocked in every test, like in Jest, you can mock them inside [`setupFiles`](/config/#setupfiles). 33 33 34 34 - ### Importing the original of a mocked package 34 34 + ### Importing the Original of a Mocked Package 35 35 36 36 If you are only partially mocking a package, you might have previously used Jest's function `requireActual`. In Vitest, you should replace these calls with `vi.importActual`. 37 37 ··· 46 46 47 47 ### Replace property 48 48 49 49 - If you want to modify the object, you will use [replaceProperty API](https://jestjs.io/docs/jest-object#jestreplacepropertyobject-propertykey-value) in Jest, you can use [`vi.stubEnv`](https://vitest.dev/api/vi.html#vi-stubenv) or [`vi.spyOn`](/api/vi#vi-spyon) to do the same also in Vitest. 49 49 + If you want to modify the object, you will use [replaceProperty API](https://jestjs.io/docs/jest-object#jestreplacepropertyobject-propertykey-value) in Jest, you can use [`vi.stubEnv`](https://vitest.dev/api/vi.html#vi-stubenv) or [`vi.spyOn`](/api/vi#vi-spyon) to do the same also in Vitest. 50 50 51 51 ### Done Callback 52 52

+3 -3

docs/guide/mocking.md

Reviewed

··· 156 156 157 157 Mock modules observe third-party-libraries, that are invoked in some other code, allowing you to test arguments, output or even redeclare its implementation. 158 158 159 159 - See the [`vi.mock()` api section](/api/vi#vi-mock) for a more in-depth detailed API description. 159 159 + See the [`vi.mock()` API section](/api/vi#vi-mock) for a more in-depth detailed API description. 160 160 161 161 - ### Automocking algorithm 161 161 + ### Automocking Algorithm 162 162 163 163 If your code is importing a mocked module, without any associated `__mocks__` file or `factory` for this module, Vitest will mock the module itself by invoking it and mocking every export. 164 164 ··· 330 330 331 331 When we test code that involves timeouts or intervals, instead of having our tests wait it out or timeout, we can speed up our tests by using "fake" timers that mock calls to `setTimeout` and `setInterval`. 332 332 333 333 - See the [`vi.useFakeTimers` api section](/api/vi#vi-usefaketimers) for a more in depth detailed API description. 333 333 + See the [`vi.useFakeTimers` API section](/api/vi#vi-usefaketimers) for a more in depth detailed API description. 334 334 335 335 ### Example 336 336

+19 -19

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](https://vitest.dev/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 ··· 28 28 29 29 ## Reporter Output 30 30 31 31 - 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](https://vitest.dev/config/#outputfile) either in your Vite configuration file or via CLI. 31 31 + 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. 32 32 33 33 :::code-group 34 34 ```bash [CLI] ··· 80 80 81 81 ## Built-in Reporters 82 82 83 83 - ### Default reporter 83 83 + ### Default Reporter 84 84 85 85 By default (i.e. if no reporter is specified), Vitest will display results for each test suite hierarchically as they run, and then collapse after a suite passes. When all tests have finished running, the final terminal output will display a summary of results and details of any failed tests. 86 86 ··· 106 106 Duration 1.26s (transform 35ms, setup 1ms, collect 90ms, tests 1.47s, environment 0ms, prepare 267ms) 107 107 ``` 108 108 109 109 - ### Basic reporter 109 109 + ### Basic Reporter 110 110 111 111 - The `basic` reporter displays the test files that have run and a summary of results after the entire suite has finished running. Individual tests are not included in the report unless they fail. 111 111 + The `basic` reporter displays the test files that have run and a summary of results after the entire suite has finished running. Individual tests are not included in the report unless they fail. 112 112 113 113 :::code-group 114 114 ```bash [CLI] ··· 135 135 Duration 1.26s (transform 35ms, setup 1ms, collect 90ms, tests 1.47s, environment 0ms, prepare 267ms) 136 136 ``` 137 137 138 138 - ### Verbose reporter 138 138 + ### Verbose Reporter 139 139 140 140 Follows the same hierarchical structure as the `default` reporter, but does not collapse sub-trees for passed test suites. The final terminal output displays all tests that have run, including those that have passed. 141 141 ··· 171 171 Duration 1.26s (transform 35ms, setup 1ms, collect 90ms, tests 1.47s, environment 0ms, prepare 267ms) 172 172 ``` 173 173 174 174 - ### Dot reporter 174 174 + ### Dot Reporter 175 175 176 176 Prints a single dot for each completed test to provide minimal output while still showing all tests that have run. Details are only provided for failed tests, along with the `basic` reporter summary for the suite. 177 177 ··· 200 200 Duration 1.26s (transform 35ms, setup 1ms, collect 90ms, tests 1.47s, environment 0ms, prepare 267ms) 201 201 ``` 202 202 203 203 - ### JUnit reporter 203 203 + ### JUnit Reporter 204 204 205 205 - 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`](##Reporter-Output) configuration option. 205 205 + 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. 206 206 207 207 :::code-group 208 208 ```bash [CLI] ··· 236 236 ``` 237 237 The outputted XML contains nested `testsuites` and `testcase` tags. You can use the environment variables `VITEST_JUNIT_SUITE_NAME` and `VITEST_JUNIT_CLASSNAME` to configure their `name` and `classname` attributes, respectively. 238 238 239 239 - ### JSON reporter 239 239 + ### JSON Reporter 240 240 241 241 - Outputs a report of the test results in JSON format. Can either be printed to the terminal or written to a file using the [`outputFile`](##Reporter-Output) configuration option. 241 241 + Outputs a report of the test results in JSON format. Can either be printed to the terminal or written to a file using the [`outputFile`](/config/#outputfile) configuration option. 242 242 243 243 :::code-group 244 244 ```bash [CLI] ··· 300 300 } 301 301 ``` 302 302 303 303 - ### HTML reporter 303 303 + ### HTML Reporter 304 304 305 305 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. 306 306 307 307 - Output file can be specified using the [`outputFile`](##Reporter-Output) configuration option. If no `outputFile` option is provided, a new HTML file will be created. 307 307 + 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. 308 308 309 309 :::code-group 310 310 ```bash [CLI] ··· 324 324 This reporter requires installed [`@vitest/ui`](/guide/ui) package. 325 325 ::: 326 326 327 327 - ### TAP reporter 327 327 + ### TAP Reporter 328 328 329 329 - Outputs a report following [Test Anything Protocol](https://testanything.org/) (TAP). 329 329 + Outputs a report following [Test Anything Protocol](https://testanything.org/) (TAP). 330 330 331 331 :::code-group 332 332 ```bash [CLI] ··· 364 364 } 365 365 ``` 366 366 367 367 - ### TAP flat reporter 367 367 + ### TAP Flat Reporter 368 368 369 369 Outputs a TAP flat report. Like the `tap` reporter, test results are formatted to follow TAP standards, but test suites are formatted as a flat list rather than a nested hierarchy. 370 370 ··· 399 399 ``` 400 400 401 401 402 402 - ### Hanging process reporter 402 402 + ### Hanging Process Reporter 403 403 404 404 Displays a list of hanging processes, if any are preventing Vitest from exiting safely. The `hanging-process` reporter does not itself display test results, but can be used in conjunction with another reporter to monitor processes while tests run. Using this reporter can be resource-intensive, so should generally be reserved for debugging purposes in situations where Vitest consistently cannot exit the process. 405 405 ··· 417 417 ``` 418 418 ::: 419 419 420 420 - ## Custom reporters 420 420 + ## Custom Reporters 421 421 422 422 You can use third-party custom reporters installed from NPM by specifying their package name in the reporters' option: 423 423 ··· 441 441 npx vitest --reporter=./path/to/reporter.ts 442 442 ``` 443 443 444 444 - Custom reporters should implement the [Reporter interface](https://github.com/vitest-dev/vitest/blob/main/packages/vitest/src/types/reporter.ts). 444 444 + Custom reporters should implement the [Reporter interface](https://github.com/vitest-dev/vitest/blob/main/packages/vitest/src/types/reporter.ts).

+2 -2

docs/guide/testing-types.md

Reviewed

··· 63 63 64 64 The `This expression is not callable` part isn't all that helpful - the meaningful error is the next line, `Type 'ExpectString<number> has no call signatures`. This essentially means you passed a number but asserted it should be a string. 65 65 66 66 - If TypeScript added support for ["throw" types](https://github.com/microsoft/TypeScript/pull/40468) these error messagess could be improved significantly. Until then they will take a certain amount of squinting. 66 66 + If TypeScript added support for ["throw" types](https://github.com/microsoft/TypeScript/pull/40468) these error messages could be improved significantly. Until then they will take a certain amount of squinting. 67 67 68 68 #### Concrete "expected" objects vs typeargs 69 69 ··· 109 109 ``` 110 110 ::: 111 111 112 112 - ## Run typechecking 112 112 + ## Run Typechecking 113 113 114 114 Since Vitest 1.0, to enabled typechecking, just add [`--typecheck`](/config/#typecheck) flag to your Vitest command in `package.json`: 115 115

+1 -1

docs/guide/ui.md

Reviewed

··· 41 41 ::: 42 42 43 43 ::: tip 44 44 - To preview your HTML report, you can use [vite preview](https://vitejs.dev/guide/cli.html#vite-preview) command: 44 44 + To preview your HTML report, you can use the [vite preview](https://vitejs.dev/guide/cli.html#vite-preview) command: 45 45 46 46 ```sh 47 47 npx vite preview --outDir ./html

+1 -1

docs/guide/why.md

Reviewed

··· 8 8 This guide assumes that you are familiar with Vite. A good way to start learning more is to read the [Why Vite Guide](https://vitejs.dev/guide/why.html), and [Next generation frontend tooling with ViteJS](https://www.youtube.com/watch?v=UJypSr8IhKY), a stream where [Evan You](https://twitter.com/youyuxi) did a demo explaining the main concepts. 9 9 ::: 10 10 11 11 - ## The need for a Vite native test runner 11 11 + ## The Need for a Vite Native Test Runner 12 12 13 13 Vite's out-of-the-box support for common web patterns, features like glob imports and SSR primitives, and its many plugins and integrations are fostering a vibrant ecosystem. Its dev and build story are key to its success. For docs, there are several SSG-based alternatives powered by Vite. Vite's Unit Testing story hasn't been clear though. Existing options like [Jest](https://jestjs.io/) were created in a different context. There is a lot of duplication between Jest and Vite, forcing users to configure two different pipelines. 14 14

+6 -2

docs/guide/workspace.md

Reviewed

··· 1 1 + --- 2 2 + title: Workspace | Guide 3 3 + --- 4 4 + 1 5 # Workspace 2 6 3 3 - Vitest provides built-in support for monorepositories through a workspace configuration file. You can create a workspace to define your project's setups. 7 7 + Vitest provides built-in support for monorepos through a workspace configuration file. You can create a workspace to define your project's setups. 4 8 5 5 - ## Defining a workspace 9 9 + ## Defining a Workspace 6 10 7 11 A workspace should have a `vitest.workspace` or `vitest.projects` file in its root (in the same folder as your config file if you have one). Vitest supports `ts`/`js`/`json` extensions for this file. 8 12

+1 -1

packages/browser/README.md

Reviewed

··· 2 2 3 3 Browser runner for Vitest. 4 4 5 5 - > ⚠️ This package is **experimental**. While this package will be released along with other packages, it will not follow semver for breaking changes until we mark it as ready. 5 5 + > ⚠️ This package is **experimental**. While this package will be released along with other packages, it will not follow SemVer for breaking changes until we mark it as ready. 6 6 7 7 ## Progress 8 8

+2 -2

packages/vitest/src/node/cli.ts

Reviewed

··· 29 29 .option('--run', 'Disable watch mode') 30 30 .option('--mode <name>', 'Override Vite mode (default: test)') 31 31 .option('--globals', 'Inject apis globally') 32 32 - .option('--dom', 'Mock browser api with happy-dom') 32 32 + .option('--dom', 'Mock browser API with happy-dom') 33 33 .option('--browser [options]', 'Run tests in the browser (default: false)') 34 34 .option('--pool <pool>', 'Specify pool, if not running in the browser (default: threads)') 35 35 .option('--poolOptions <options>', 'Specify pool options') ··· 134 134 } 135 135 136 136 async function benchmark(cliFilters: string[], options: CliOptions): Promise<void> { 137 137 - console.warn(c.yellow('Benchmarking is an experimental feature.\nBreaking changes might not follow semver, please pin Vitest\'s version when using it.')) 137 137 + console.warn(c.yellow('Benchmarking is an experimental feature.\nBreaking changes might not follow SemVer, please pin Vitest\'s version when using it.')) 138 138 await start('benchmark', cliFilters, options) 139 139 } 140 140

+1 -1

packages/vitest/src/node/config.ts

Reviewed

··· 398 398 resolved.typecheck.enabled ??= false 399 399 400 400 if (resolved.typecheck.enabled) 401 401 - console.warn(c.yellow('Testing types with tsc and vue-tsc is an experimental feature.\nBreaking changes might not follow semver, please pin Vitest\'s version when using it.')) 401 401 + console.warn(c.yellow('Testing types with tsc and vue-tsc is an experimental feature.\nBreaking changes might not follow SemVer, please pin Vitest\'s version when using it.')) 402 402 403 403 resolved.browser ??= {} as any 404 404 resolved.browser.enabled ??= false

+1 -1

test/typescript/test/__snapshots__/runner.test.ts.snap

Reviewed

··· 89 89 90 90 exports[`should fail > typechecks empty "include" but with tests 1`] = ` 91 91 "Testing types with tsc and vue-tsc is an experimental feature. 92 92 - Breaking changes might not follow semver, please pin Vitest's version when using it. 92 92 + Breaking changes might not follow SemVer, please pin Vitest's version when using it. 93 93 94 94 ⎯⎯⎯⎯⎯⎯ Typecheck Error ⎯⎯⎯⎯⎯⎯⎯ 95 95 Error: error TS18003: No inputs were found in config file '<root>/tsconfig.vitest-temp.json'. Specified 'include' paths were '["src"]' and 'exclude' paths were '["**/dist/**"]'.