diff --git a/docs/api/expect.md b/docs/api/expect.md index ca467bbd7..98640fd69 100644 --- a/docs/api/expect.md +++ b/docs/api/expect.md @@ -767,7 +767,7 @@ test('matches snapshot', () => { }) ``` -## toMatchFileSnapshot 0.30.0+ {#tomatchfilesnapshot} +## toMatchFileSnapshot {#tomatchfilesnapshot} - **Type:** `(filepath: string, message?: string) => Promise` @@ -1246,7 +1246,7 @@ test('"id" is a number', () => { }) ``` -## expect.closeTo 1.0.0+ {#expect-closeto} +## expect.closeTo {#expect-closeto} - **Type:** `(expected: any, precision?: number) => any` @@ -1444,7 +1444,7 @@ Don't forget to include the ambient declaration file in your `tsconfig.json`. If you want to know more, checkout [guide on extending matchers](/guide/extending-matchers). ::: -## expect.addEqualityTesters 1.2.0+ {#expect-addequalitytesters} +## expect.addEqualityTesters {#expect-addequalitytesters} - **Type:** `(tester: Array) => void` diff --git a/docs/api/index.md b/docs/api/index.md index dc1addeef..d2303a8c9 100644 --- a/docs/api/index.md +++ b/docs/api/index.md @@ -47,7 +47,7 @@ When a test function returns a promise, the runner will wait until it is resolve In Jest, `TestFunction` can also be of type `(done: DoneCallback) => void`. If this form is used, the test will not be concluded until `done` is called. You can achieve the same using an `async` function, see the [Migration guide Done Callback section](/guide/migration#done-callback). ::: -Since Vitest 1.3.0 most options support both dot-syntax and object-syntax allowing you to use whatever style you prefer. +Most options support both dot-syntax and object-syntax allowing you to use whatever style you prefer. :::code-group ```ts [dot-syntax] twoslash @@ -57,7 +57,7 @@ test.skip('skipped test', () => { // some logic that fails right now }) ``` -```ts [object-syntax 1.3.0] twoslash +```ts [object-syntax] twoslash import { test } from 'vitest' test('skipped test', { skip: true }, () => { @@ -82,7 +82,7 @@ test('should work as expected', () => { }) ``` -### test.extend 0.32.3 {#test-extended} +### test.extend {#test-extended} - **Alias:** `it.extend` @@ -859,7 +859,7 @@ beforeEach(async () => { Here, the `beforeEach` ensures that user is added for each test. -Since Vitest v0.10.0, `beforeEach` also accepts an optional cleanup function (equivalent to `afterEach`). +`beforeEach` also accepts an optional cleanup function (equivalent to `afterEach`). ```ts import { beforeEach } from 'vitest' @@ -917,7 +917,7 @@ beforeAll(async () => { Here the `beforeAll` ensures that the mock data is set up before tests run. -Since Vitest v0.10.0, `beforeAll` also accepts an optional cleanup function (equivalent to `afterAll`). +`beforeAll` also accepts an optional cleanup function (equivalent to `afterAll`). ```ts import { beforeAll } from 'vitest' @@ -960,7 +960,7 @@ Vitest provides a few hooks that you can call _during_ the test execution to cle These hooks will throw an error if they are called outside of the test body. ::: -### onTestFinished 1.3.0 {#ontestfinished} +### onTestFinished {#ontestfinished} This hook is always called after the test has finished running. It is called after `afterEach` hooks since they can influence the test result. It receives a `TaskResult` object with the current test result. diff --git a/docs/api/vi.md b/docs/api/vi.md index 17dc0d6dd..725797444 100644 --- a/docs/api/vi.md +++ b/docs/api/vi.md @@ -17,7 +17,7 @@ This section describes the API that you can use when [mocking a module](/guide/m ### vi.mock - **Type**: `(path: string, factory?: (importOriginal: () => unknown) => unknown) => void` -- **Type**: `(path: Promise, factory?: (importOriginal: () => T) => unknown) => void` 2.0.0+ +- **Type**: `(path: Promise, factory?: (importOriginal: () => T) => unknown) => void` Substitutes all imported modules from provided `path` with another module. You can use configured Vite aliases inside a path. The call to `vi.mock` is hoisted, so it doesn't matter where you call it. It will always be executed before all imports. If you need to reference some variables outside of its scope, you can define them inside [`vi.hoisted`](#vi-hoisted) and reference them inside `vi.mock`. @@ -65,7 +65,7 @@ vi.mock('./path/to/module.js', async (importOriginal) => { }) ``` -Since 2.0.0, Vitest supports a module promise instead of a string in `vi.mock` method for better IDE support (when file is moved, path will be updated, `importOriginal` also inherits the type automatically). +Vitest supports a module promise instead of a string in `vi.mock` method for better IDE support (when file is moved, path will be updated, `importOriginal` also inherits the type automatically). ```ts vi.mock(import('./path/to/module.js'), async (importOriginal) => { @@ -443,7 +443,7 @@ console.log(cart.getApples()) // still 42! ``` ::: -### vi.stubEnv 0.26.0+ {#vi-stubenv} +### vi.stubEnv {#vi-stubenv} - **Type:** `(name: string, value: string) => Vitest` @@ -471,7 +471,7 @@ import.meta.env.MODE = 'test' ``` ::: -### vi.unstubAllEnvs 0.26.0+ {#vi-unstuballenvs} +### vi.unstubAllEnvs {#vi-unstuballenvs} - **Type:** `() => Vitest` @@ -529,7 +529,7 @@ window.innerWidth = 100 ``` ::: -### vi.unstubAllGlobals 0.26.0+ {#vi-unstuballglobals} +### vi.unstubAllGlobals {#vi-unstuballglobals} - **Type:** `() => Vitest` @@ -785,11 +785,11 @@ Mocking `nextTick` is not supported when running Vitest inside `node:child_proce The implementation is based internally on [`@sinonjs/fake-timers`](https://github.com/sinonjs/fake-timers). ::: tip -Since version `0.35.0` `vi.useFakeTimers()` no longer automatically mocks `process.nextTick`. -It can still be mocked by specifying the option in `toFake` argument: `vi.useFakeTimers({ toFake: ['nextTick'] })`. +`vi.useFakeTimers()` does not automatically mock `process.nextTick`. +But you can enable it by specifying the option in `toFake` argument: `vi.useFakeTimers({ toFake: ['nextTick'] })`. ::: -### vi.isFakeTimers 0.34.5+ {#vi-isfaketimers} +### vi.isFakeTimers {#vi-isfaketimers} - **Type:** `() => boolean` @@ -805,7 +805,7 @@ When timers are run out, you may call this method to return mocked timers to its A set of useful helper functions that Vitest provides. -### vi.waitFor 0.34.5+ {#vi-waitfor} +### vi.waitFor {#vi-waitfor} - **Type:** `(callback: WaitForCallback, options?: number | WaitForOptions) => Promise` @@ -864,7 +864,7 @@ test('Element exists in a DOM', async () => { If `vi.useFakeTimers` is used, `vi.waitFor` automatically calls `vi.advanceTimersByTime(interval)` in every check callback. -### vi.waitUntil 0.34.5+ {#vi-waituntil} +### vi.waitUntil {#vi-waituntil} - **Type:** `(callback: WaitUntilCallback, options?: number | WaitUntilOptions) => Promise` @@ -889,7 +889,7 @@ test('Element render correctly', async () => { }) ``` -### vi.hoisted 0.31.0+ {#vi-hoisted} +### vi.hoisted {#vi-hoisted} - **Type**: `(factory: () => T) => T` diff --git a/docs/config/index.md b/docs/config/index.md index 7c8ae5ef7..9e16a3856 100644 --- a/docs/config/index.md +++ b/docs/config/index.md @@ -55,7 +55,7 @@ Include globs for in-source test files. When defined, Vitest will run all matched files with `import.meta.vitest` inside. -### server 0.34.0+ {#server} +### server {#server} - **Type:** `{ sourcemap?, deps?, ... }` @@ -134,12 +134,12 @@ Directory to save cache files. Handling for dependencies resolution. -#### deps.optimizer 0.34.0+ {#deps-optimizer} +#### deps.optimizer {#deps-optimizer} - **Type:** `{ ssr?, web? }` - **See also:** [Dep Optimization Options](https://vitejs.dev/config/dep-optimization-options.html) -Enable dependency optimization. If you have a lot of tests, this might improve their performance. Before Vitest 0.34.0, it was named as `deps.experimentalOptimizer`. +Enable dependency optimization. If you have a lot of tests, this might improve their performance. When Vitest encounters the external library listed in `include`, it will be bundled into a single file using esbuild and imported as a whole module. This is good for several reasons: @@ -159,15 +159,11 @@ You will not be able to edit your `node_modules` code for debugging, since the c #### deps.optimizer.{mode}.enabled - **Type:** `boolean` -- **Default:** `false` since Vitest 1.3.0 +- **Default:** `false` Enable dependency optimization. -::: warning -This option only works with Vite 4.3.2 and higher. -::: - -#### deps.web 0.34.2+ {#deps-web} +#### deps.web {#deps-web} - **Type:** `{ transformAssets?, ... }` @@ -312,7 +308,7 @@ By providing an object instead of a string you can define individual outputs whe To provide object via CLI command, use the following syntax: `--outputFile.json=./path --outputFile.junit=./other-path`. -#### benchmark.outputJson 1.6.0 {#benchmark-outputJson} +#### benchmark.outputJson {#benchmark-outputJson} - **Type:** `string | undefined` - **Default:** `undefined` @@ -331,7 +327,7 @@ git checkout feature vitest bench --compare main.json ``` -#### benchmark.compare 1.6.0 {#benchmark-compare} +#### benchmark.compare {#benchmark-compare} - **Type:** `string | undefined` - **Default:** `undefined` @@ -475,7 +471,7 @@ export default { Vitest also exposes `builtinEnvironments` through `vitest/environments` entry, in case you just want to extend it. You can read more about extending environments in [our guide](/guide/environment). ::: tip -Since Vitest 1.3.0 jsdom environment exposes `jsdom` global variable equal to the current [JSDOM](https://github.com/jsdom/jsdom) instance. If you want TypeScript to recognize it, you can add `vitest/jsdom` to your `tsconfig.json` when you use this environment: +jsdom environment exposes `jsdom` global variable equal to the current [JSDOM](https://github.com/jsdom/jsdom) instance. If you want TypeScript to recognize it, you can add `vitest/jsdom` to your `tsconfig.json` when you use this environment: ```json { @@ -518,7 +514,7 @@ export default defineConfig({ }) ``` -### poolMatchGlobs 0.29.4+ {#poolmatchglobs} +### poolMatchGlobs {#poolmatchglobs} - **Type:** `[string, 'threads' | 'forks' | 'vmThreads' | 'vmForks' | 'typescript'][]` - **Default:** `[]` @@ -583,10 +579,10 @@ Custom [reporters](/guide/reporters) for output. Reporters can be [a Reporter in Write test results to a file when the `--reporter=json`, `--reporter=html` or `--reporter=junit` option is also specified. By providing an object instead of a string you can define individual outputs when using multiple reporters. -### pool 1.0.0+ {#pool} +### pool {#pool} - **Type:** `'threads' | 'forks' | 'vmThreads' | 'vmForks'` -- **Default:** `'forks'` (in v1 `'threads'`) +- **Default:** `'forks'` - **CLI:** `--pool=threads` Pool used to run tests in. @@ -629,7 +625,7 @@ Please, be aware of these issues when using this option. Vitest team cannot fix Similar as `vmThreads` pool but uses `child_process` instead of `worker_threads` via [tinypool](https://github.com/tinylibs/tinypool). Communication between tests and the main process is not as fast as with `vmThreads` pool. Process related APIs such as `process.chdir()` are available in `vmForks` pool. Please be aware that this pool has the same pitfalls listed in `vmThreads`. -### poolOptions 1.0.0+ {#pooloptions} +### poolOptions {#pooloptions} - **Type:** `Record<'threads' | 'forks' | 'vmThreads' | 'vmForks', {}>` - **Default:** `{}` @@ -900,7 +896,7 @@ Pass additional arguments to `node` process in the VM context. See [Command-line Be careful when using, it as some options may crash worker, e.g. --prof, --title. See https://github.com/nodejs/node/issues/41103. ::: -### fileParallelism 1.1.0+ {#fileparallelism} +### fileParallelism {#fileparallelism} - **Type:** `boolean` - **Default:** `true` @@ -912,13 +908,13 @@ Should all test files run in parallel. Setting this to `false` will override `ma This option doesn't affect tests running in the same file. If you want to run those in parallel, use `concurrent` option on [describe](/api/#describe-concurrent) or via [a config](#sequence-concurrent). ::: -### maxWorkers 1.1.0+ {#maxworkers} +### maxWorkers {#maxworkers} - **Type:** `number` Maximum number of workers to run tests in. `poolOptions.{threads,vmThreads}.maxThreads`/`poolOptions.forks.maxForks` has higher priority. -### minWorkers 1.1.0+ {#minworkers} +### minWorkers {#minworkers} - **Type:** `number` @@ -1004,9 +1000,9 @@ Multiple globalSetup files are possible. setup and teardown are executed sequent ::: ::: warning -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). +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). -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: +Beware that the global setup is running in a different global scope, so your tests don't have access to variables defined here. However, you can pass down serializable data to tests via `provide` method: :::code-group ```js [globalSetup.js] @@ -1149,7 +1145,7 @@ export default defineConfig({ #### coverage.all - **Type:** `boolean` -- **Default:** `true` (since Vitest `1.0.0`) +- **Default:** `true` - **Available for providers:** `'v8' | 'istanbul'` - **CLI:** `--coverage.all`, `--coverage.all=false` @@ -1213,7 +1209,7 @@ The reporter has three different types: } ``` -Since Vitest 1.2.0, you can also pass custom coverage reporters. See [Guide - Custom Coverage Reporter](/guide/coverage#custom-coverage-reporter) for more information. +You can also pass custom coverage reporters. See [Guide - Custom Coverage Reporter](/guide/coverage#custom-coverage-reporter) for more information. ```ts @@ -1230,12 +1226,12 @@ Since Vitest 1.2.0, you can also pass custom coverage reporters. See [Guide - Cu } ``` -Since Vitest 0.31.0, you can check your coverage report in Vitest UI: check [Vitest UI Coverage](/guide/coverage#vitest-ui) for more details. +You can check your coverage report in Vitest UI: check [Vitest UI Coverage](/guide/coverage#vitest-ui) for more details. -#### coverage.reportOnFailure 0.31.2+ {#coverage-reportonfailure} +#### coverage.reportOnFailure {#coverage-reportonfailure} - **Type:** `boolean` -- **Default:** `false` (since Vitest `0.34.0`) +- **Default:** `false` - **Available for providers:** `'v8' | 'istanbul'` - **CLI:** `--coverage.reportOnFailure`, `--coverage.reportOnFailure=false` @@ -1489,7 +1485,7 @@ Open Vitest UI (WIP) Listen to port and serve API. When set to true, the default port is 51204 -### browser 0.29.4+ {#browser} +### browser {#browser} - **Type:** `{ enabled?, name?, provider?, headless?, api?, slowHijackESM? }` - **Default:** `{ enabled: false, headless: process.env.CI, api: 63315 }` @@ -1540,7 +1536,7 @@ Run the browser in a `headless` mode. If you are running Vitest in CI, it will b Run every test in a separate iframe. -### browser.fileParallelism 1.3.0+ {#browser-fileparallelism} +### browser.fileParallelism {#browser-fileparallelism} - **Type:** `boolean` - **Default:** the same as [`fileParallelism`](#fileparallelism) @@ -1584,7 +1580,7 @@ export interface BrowserProvider { This is an advanced API for library authors. If you just need to run tests in a browser, use the [browser](#browser) option. ::: -#### browser.providerOptions 1.0.0+ {#browser-provideroptions} +#### browser.providerOptions {#browser-provideroptions} - **Type:** `BrowserProviderOptions` @@ -1619,7 +1615,7 @@ To have a better type safety when using built-in providers, you can add one of t ``` ::: -#### browser.slowHijackESM 0.31.0+ {#browser-slowhijackesm} +#### browser.slowHijackESM {#browser-slowhijackesm} - **Type:** `boolean` - **Default:** `false` @@ -1630,7 +1626,7 @@ This option has no effect on tests running inside Node.js. If you rely on spying on ES modules with `vi.spyOn`, you can enable this experimental feature to allow spying on module exports. -#### browser.indexScripts 1.6.0 {#browser-indexscripts} +#### browser.indexScripts {#browser-indexscripts} - **Type:** `BrowserScript[]` - **Default:** `[]` @@ -1670,7 +1666,7 @@ export interface BrowserScript { } ``` -#### browser.testerScripts 1.6.0 {#browser-testerscripts} +#### browser.testerScripts {#browser-testerscripts} - **Type:** `BrowserScript[]` - **Default:** `[]` @@ -1679,7 +1675,7 @@ Custom scripts that should be injected into the tester HTML before the tests env The script `src` and `content` will be processed by Vite plugins. -#### browser.commands 2.0.0 {#browser-commands} +#### browser.commands {#browser-commands} - **Type:** `Record` - **Default:** `{ readFile, writeFile, ... }` @@ -1707,21 +1703,21 @@ Will call [`.mockReset()`](/api/mock#mockreset) on all spies before each test. T Will call [`.mockRestore()`](/api/mock#mockrestore) on all spies before each test. This will clear mock history and reset its implementation to the original one. -### unstubEnvs 0.26.0+ {#unstubenvs} +### unstubEnvs {#unstubenvs} - **Type:** `boolean` - **Default:** `false` Will call [`vi.unstubAllEnvs`](/api/vi#vi-unstuballenvs) before each test. -### unstubGlobals 0.26.0+ {#unstubglobals} +### unstubGlobals {#unstubglobals} - **Type:** `boolean` - **Default:** `false` Will call [`vi.unstubAllGlobals`](/api/vi#vi-unstuballglobals) before each test. -### testTransformMode 0.34.0+ {#testtransformmode} +### testTransformMode {#testtransformmode} - **Type:** `{ web?, ssr? }` @@ -1755,7 +1751,7 @@ Beware that `plugins` field on this object will be ignored. If you need to extend snapshot serializer via pretty-format plugins, please, use [`expect.addSnapshotSerializer`](/api/expect#expect-addsnapshotserializer) API or [snapshotSerializers](#snapshotserializers) option. ::: -### snapshotSerializers 1.3.0+ {#snapshotserializers} +### snapshotSerializers {#snapshotserializers} - **Type:** `string[]` - **Default:** `[]` @@ -1903,7 +1899,7 @@ If you want files and tests to run randomly, you can enable it with this option, Vitest usually uses cache to sort tests, so long running tests start earlier - this makes tests run faster. If your files and tests will run in random order you will lose this performance improvement, but it may be useful to track tests that accidentally depend on another run previously. -#### sequence.shuffle.files 1.4.0+ {#sequence-shuffle-files} +#### sequence.shuffle.files {#sequence-shuffle-files} - **Type**: `boolean` - **Default**: `false` @@ -1911,7 +1907,7 @@ Vitest usually uses cache to sort tests, so long running tests start earlier - t Whether to randomize files, be aware that long running tests will not start earlier if you enable this option. -#### sequence.shuffle.tests 1.4.0+ {#sequence-shuffle-tests} +#### sequence.shuffle.tests {#sequence-shuffle-tests} - **Type**: `boolean` - **Default**: `false` @@ -1919,7 +1915,7 @@ Whether to randomize files, be aware that long running tests will not start earl Whether to randomize tests. -#### sequence.concurrent 0.32.2+ {#sequence-concurrent} +#### sequence.concurrent {#sequence-concurrent} - **Type**: `boolean` - **Default**: `false` @@ -1951,7 +1947,7 @@ Changes the order in which hooks are executed. This option doesn't affect [`onTestFinished`](/api/#ontestfinished). It is always called in reverse order. ::: -#### sequence.setupFiles 0.29.3+ {#sequence-setupfiles} +#### sequence.setupFiles {#sequence-setupfiles} - **Type**: `'list' | 'parallel'` - **Default**: `'parallel'` @@ -1966,7 +1962,7 @@ Changes the order in which setup files are executed. Options for configuring [typechecking](/guide/testing-types) test environment. -#### typecheck.enabled 1.0.0+ {#typecheck-enabled} +#### typecheck.enabled {#typecheck-enabled} - **Type**: `boolean` - **Default**: `false` @@ -1974,7 +1970,7 @@ Options for configuring [typechecking](/guide/testing-types) test environment. Enable typechecking alongside your regular tests. -#### typecheck.only 1.0.0+ {#typecheck-only} +#### typecheck.only {#typecheck-only} - **Type**: `boolean` - **Default**: `false` @@ -2041,7 +2037,7 @@ Path to custom tsconfig, relative to the project root. The number of milliseconds after which a test is considered slow and reported as such in the results. -### chaiConfig 0.30.0+ {#chaiconfig} +### chaiConfig {#chaiconfig} - **Type:** `{ includeStack?, showDiff?, truncateThreshold? }` - **Default:** `{ includeStack: false, showDiff: true, truncateThreshold: 40 }` @@ -2071,7 +2067,7 @@ Sets length threshold for actual and expected values in assertion errors. If thi This config option affects truncating values in `test.each` titles and inside the assertion error message. -### bail 0.31.0+ {#bail} +### bail {#bail} - **Type:** `number` - **Default:** `0` @@ -2081,7 +2077,7 @@ Stop test execution when given number of tests have failed. 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. -### retry 0.32.3+ {#retry} +### retry {#retry} - **Type:** `number` - **Default:** `0` @@ -2109,7 +2105,7 @@ export default defineConfig({ }) ``` -### onStackTrace 1.0.0+ {#onstacktrace} +### onStackTrace {#onstacktrace} - **Type**: `(error: Error, frame: ParsedStack) => boolean | void` @@ -2136,7 +2132,7 @@ export default defineConfig({ }) ``` -### diff 0.34.5+ {#diff} +### diff - **Type:** `string` - **CLI:** `--diff=` @@ -2240,7 +2236,7 @@ Relevant only when using with `shouldAdvanceTime: true`. increment mocked time b Tells fake timers to clear "native" (i.e. not fake) timers by delegating to their respective handlers. These are not cleared by default, leading to potentially unexpected behavior if timers existed prior to starting fake timers session. -### workspace 1.1.0+ {#workspace} +### workspace {#workspace} - **Type:** `string` - **CLI:** `--workspace=./file.js` @@ -2248,7 +2244,7 @@ Tells fake timers to clear "native" (i.e. not fake) timers by delegating to thei Path to a [workspace](/guide/workspace) config file relative to [root](#root). -### isolate 1.1.0+ {#isolate} +### isolate - **Type:** `boolean` - **Default:** `true` @@ -2262,7 +2258,7 @@ Disabling this option might [improve performance](/guide/improving-performance) You can disable isolation for specific pools by using [`poolOptions`](#pooloptions) property. ::: -### includeTaskLocation 1.4.0+ {#includeTaskLocation} +### includeTaskLocation {#includeTaskLocation} - **Type:** `boolean` - **Default:** `false` @@ -2275,7 +2271,7 @@ The `location` property has `column` and `line` values that correspond to the `t This option has no effect if you do not use custom code that relies on this. ::: -### snapshotEnvironment 1.6.0 {#snapshotEnvironment} +### snapshotEnvironment {#snapshotEnvironment} - **Type:** `string` diff --git a/docs/guide/browser.md b/docs/guide/browser.md index c49eb8c06..009b94424 100644 --- a/docs/guide/browser.md +++ b/docs/guide/browser.md @@ -119,7 +119,7 @@ npx vitest --browser.name=chrome --browser.headless In this case, Vitest will run in headless mode using the Chrome browser. -## Context 2.0.0 {#context} +## Context Vitest exposes a context module via `@vitest/browser/context` entry point. As of 2.0, it exposes a small set of utilities that might be useful to you in tests. @@ -157,7 +157,7 @@ export const page: { } ``` -## Commands 2.0.0 {#commands} +## Commands Command is a function that invokes another function on the server and passes down the result back to the browser. Vitest exposes several built-in commands you can use in your browser tests. diff --git a/docs/guide/coverage.md b/docs/guide/coverage.md index 09f1c59d3..b62628b94 100644 --- a/docs/guide/coverage.md +++ b/docs/guide/coverage.md @@ -8,10 +8,6 @@ Vitest supports Native code coverage via [`v8`](https://v8.dev/blog/javascript-c ## Coverage Providers -:::tip -Since Vitest v0.22.0 -::: - Both `v8` and `istanbul` support are optional. By default, `v8` will be used. You can select the coverage tool by setting `test.coverage.provider` to `v8` or `istanbul`: @@ -220,7 +216,7 @@ To see all configurable options for coverage, see the [coverage Config Reference ## Vitest UI -Since Vitest 0.31.0, you can check your coverage report in [Vitest UI](/guide/ui). +You can check your coverage report in [Vitest UI](/guide/ui). Vitest UI will enable coverage report when it is enabled explicitly and the html coverage reporter is present, otherwise it will not be available: - enable `coverage.enabled=true` in your configuration or run Vitest with `--coverage.enabled=true` flag diff --git a/docs/guide/environment.md b/docs/guide/environment.md index c324913c9..d6f899fe2 100644 --- a/docs/guide/environment.md +++ b/docs/guide/environment.md @@ -31,7 +31,7 @@ Or you can also set [`environmentMatchGlobs`](https://vitest.dev/config/#environ ## Custom Environment -Starting from 0.23.0, you can create your own package to extend Vitest environment. To do so, create package with the name `vitest-environment-${name}` or specify a path to a valid JS/TS file (supported since 0.34.0). That package should export an object with the shape of `Environment`: +You can create your own package to extend Vitest environment. To do so, create package with the name `vitest-environment-${name}` or specify a path to a valid JS/TS file. That package should export an object with the shape of `Environment`: ```ts twoslash import type { Environment } from 'vitest' @@ -64,7 +64,7 @@ export default { ``` ::: warning -Since 0.34.0 Vitest requires `transformMode` option on environment object. It should be equal to `ssr` or `web`. This value determines how plugins will transform source code. If it's set to `ssr`, plugin hooks will receive `ssr: true` when transforming or resolving files. Otherwise, `ssr` is set to `false`. +Vitest requires `transformMode` option on environment object. It should be equal to `ssr` or `web`. This value determines how plugins will transform source code. If it's set to `ssr`, plugin hooks will receive `ssr: true` when transforming or resolving files. Otherwise, `ssr` is set to `false`. ::: You also have access to default Vitest environments through `vitest/environments` entry: diff --git a/docs/guide/extending-matchers.md b/docs/guide/extending-matchers.md index 82b542ef1..1c650cc85 100644 --- a/docs/guide/extending-matchers.md +++ b/docs/guide/extending-matchers.md @@ -23,7 +23,7 @@ expect.extend({ }) ``` -If you are using TypeScript, since Vitest 0.31.0 you can extend default `Assertion` interface in an ambient declaration file (e.g: `vitest.d.ts`) with the code below: +If you are using TypeScript, you can extend default `Assertion` interface in an ambient declaration file (e.g: `vitest.d.ts`) with the code below: ```ts import type { Assertion, AsymmetricMatchersContaining } from 'vitest' diff --git a/docs/guide/features.md b/docs/guide/features.md index fdc6679c3..66381496d 100644 --- a/docs/guide/features.md +++ b/docs/guide/features.md @@ -187,8 +187,7 @@ Learn more at [In-source testing](/guide/in-source). ## Benchmarking Experimental {#benchmarking} -Since Vitest 0.23.0, you can run benchmark tests with [`bench`](/api/#bench) -function via [Tinybench](https://github.com/tinylibs/tinybench) to compare performance results. +You can run benchmark tests with [`bench`](/api/#bench) function via [Tinybench](https://github.com/tinylibs/tinybench) to compare performance results. ```ts twoslash import { bench, describe } from 'vitest' @@ -215,7 +214,7 @@ describe('sort', () => { ## Type Testing Experimental {#type-testing} -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. +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. ```ts import { assertType, expectTypeOf } from 'vitest' diff --git a/docs/guide/migration.md b/docs/guide/migration.md index 681cb9b92..5b3a6f11d 100644 --- a/docs/guide/migration.md +++ b/docs/guide/migration.md @@ -7,11 +7,76 @@ outline: deep ## Migrating to Vitest 2.0 +### Default pool is `forks` + +Vitest 2.0 changes the default configuration for `pool` to `'forks'` for better stability. You can read the full motivation in [PR](https://github.com/vitest-dev/vitest/pull/5047). + +If you've used `poolOptions` without specifying a `pool`, you might need to update the configuration: + +```ts +export default defineConfig({ + test: { + poolOptions: { + threads: { // [!code --] + singleThread: true, // [!code --] + }, // [!code --] + forks: { // [!code ++] + singleFork: true, // [!code ++] + }, // [!code ++] + } + } +}) +``` + ### Hooks are running in a stack Before Vitest 2.0, all hooks were running in parallel. In 2.0, all hooks run serially. In addition to this, `afterAll`/`afterEach` are running in a reverse order. -You can revert to the previous behaviour by changing [`sequence.hooks`](/config/#sequence-hooks) to `'parallel'`. +You can revert to the previous behaviour by changing [`sequence.hooks`](/config/#sequence-hooks) to `'parallel'`: + +```ts +export default defineConfig({ + test: { + sequence: { // [!code ++] + hooks: 'parallel', // [!code ++] + }, // [!code ++] + }, +}) +``` + +### `suite.concurrent` runs all its tests concurrently + +Previously, specifying `concurrent` on a suite would still group concurrent tests by suites and run them together one by one. Now, it follows jest's behaviour and runs all of them at once (still limited by [`maxConcurrency`](/config/#maxConcurrency)) + +### enable V8 coverage's `coverage.ignoreEmptyLines` by default + +Changes default value of `coverage.ignoreEmptyLines` to `true`. This change will have major impact on users' code coverage reports. It is likely that projects using coverage thresholds need to adjust those values after this. This change affects only the default `coverage.provider: 'v8'`. + +### No more `watchExclude` option + +Vitest uses Vite's watcher. You can add your excludes to `server.watch.ignored` instead: + +```ts +export default defineConfig({ + server: { // [!code ++] + watch: { // [!code ++] + ignored: ['!node_modules/examplejs'] // [!code ++] + } // [!code ++] + } // [!code ++] +}) +``` + +### `--segfault-retry` removed + +With the changes to default pool, this option is no longer needed. If you experience segfault errors, try switching to `'forks'` pool. If the problem persists, please open a new issue with a reproduction. + +### Empty task in suite tasks removed + +This is the change to the advanced [task API](/advanced/runner#your-task-function). Previously, traversing `.suite` would eventually lead to the empty internal suite that was used instead of a file task. + +This makes `.suite` optional; if the task is defined at the top level, it will not have a suite. You can fallback to the `.file` property that is now present on all tasks (including the file task itself, so be careful not to fall into the endless recursion). + +This change also removes the file from `expect.getState().currentTestName` and makes `expect.getState().testPath` required. ## Migrating to Vitest 1.0 diff --git a/docs/guide/reporters.md b/docs/guide/reporters.md index 7bced6f09..28399a03f 100644 --- a/docs/guide/reporters.md +++ b/docs/guide/reporters.md @@ -28,10 +28,6 @@ export default defineConfig({ Some reporters can be customized by passing additional options to them. Reporter specific options are described in sections below. -:::tip -Since Vitest v1.3.0 -::: - ```ts export default defineConfig({ test: { @@ -444,7 +440,7 @@ export default defineConfig({ ``` ::: -### Github Actions Reporter 1.3.0+ {#github-actions-reporter} +### Github Actions Reporter {#github-actions-reporter} Output [workflow commands](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-error-message) to provide annotations for test failures. This reporter is automatically enabled with a [`default`](#default-reporter) reporter when `process.env.GITHUB_ACTIONS === 'true'`. diff --git a/docs/guide/test-context.md b/docs/guide/test-context.md index 2172f698a..88dd8e093 100644 --- a/docs/guide/test-context.md +++ b/docs/guide/test-context.md @@ -70,10 +70,6 @@ Vitest provides two different ways to help you extend the test context. ### `test.extend` -::: warning -This API is available since Vitest 0.32.3. -::: - Like [Playwright](https://playwright.dev/docs/api/class-test#test-extend), you can use this method to define your own `test` API with custom fixtures and reuse it anywhere. For example, we first create `myTest` with two fixtures, `todos` and `archive`. @@ -163,10 +159,6 @@ When using `test.extend()` with fixtures, you should always use the object destr #### Automatic fixture -::: warning -This feature is available since Vitest 1.3.0. -::: - Vitest also supports the tuple syntax for fixtures, allowing you to pass options for each fixture. For example, you can use it to explicitly initialize a fixture, even if it's not being used in tests. ```ts diff --git a/docs/guide/testing-types.md b/docs/guide/testing-types.md index e0a8574cb..ef8d6d760 100644 --- a/docs/guide/testing-types.md +++ b/docs/guide/testing-types.md @@ -117,7 +117,7 @@ assertType(answr) // ## Run Typechecking -Since Vitest 1.0, to enable typechecking, just add [`--typecheck`](/config/#typecheck) flag to your Vitest command in `package.json`: +To enable typechecking, just add [`--typecheck`](/config/#typecheck) flag to your Vitest command in `package.json`: ```json { diff --git a/docs/guide/ui.md b/docs/guide/ui.md index 6797091f9..4209ccbe0 100644 --- a/docs/guide/ui.md +++ b/docs/guide/ui.md @@ -21,7 +21,7 @@ Then you can visit the Vitest UI at Vitest UI -Since Vitest 0.26.0, UI can also be used as a reporter. Use `'html'` reporter in your Vitest configuration to generate HTML output and preview the results of your tests: +UI can also be used as a reporter. Use `'html'` reporter in your Vitest configuration to generate HTML output and preview the results of your tests: ```ts // vitest.config.ts @@ -33,7 +33,7 @@ export default { } ``` -Since Vitest 0.31.0, you can check your coverage report in Vitest UI: check [Vitest UI Coverage](/guide/coverage#vitest-ui) for more details. +You can check your coverage report in Vitest UI: see [Vitest UI Coverage](/guide/coverage#vitest-ui) for more details. ::: warning If you still want to see how your tests are running in real time in the terminal, don't forget to add `default` reporter to `reporters` option: `['default', 'html']`.