docs: replace Vitest 2.2 mentions (vitest-dev#7025)

docs/advanced/api.md

@@ -140,9 +140,9 @@ export default function setup({ provide }) {
 ```
 :::
 
-## TestProject <Version>2.2.0</Version> {#testproject}
+## TestProject <Version>3.0.0</Version> {#testproject}
 
-- **Alias**: `WorkspaceProject` before 2.2.0
+- **Alias**: `WorkspaceProject` before 3.0.0
 
 ### name
 

docs/advanced/pool.md

@@ -49,7 +49,7 @@ export default defineConfig({
 ```
 
 ::: info
-The `workspace` field was introduced in Vitest 2.2. To define a workspace in Vitest <2.2, create a separate `vitest.workspace.ts` file.
+The `workspace` field was introduced in Vitest 3. To define a workspace in [Vitest <3](https://v2.vitest.dev/), create a separate `vitest.workspace.ts` file.
 :::
 
 ## API

docs/api/expect.md

@@ -82,7 +82,7 @@ test('element exists', async () => {
 ```
 
 ::: warning
-`expect.poll` makes every assertion asynchronous, so you need to await it. Since Vitest 2.2, if you forget to await it, the test will fail with a warning to do so.
+`expect.poll` makes every assertion asynchronous, so you need to await it. Since Vitest 3, if you forget to await it, the test will fail with a warning to do so.
 
 `expect.poll` doesn't work with several matchers:
 
@@ -465,7 +465,7 @@ test('structurally the same, but semantically different', () => {
 
 - **Type:** `(received: string) => Awaitable<void>`
 
-`toContain` asserts if the actual value is in an array. `toContain` can also check whether a string is a substring of another string. Since Vitest 1.0, if you are running tests in a browser-like environment, this assertion can also check if class is contained in a `classList`, or an element is inside another one.
+`toContain` asserts if the actual value is in an array. `toContain` can also check whether a string is a substring of another string. If you are running tests in a browser-like environment, this assertion can also check if class is contained in a `classList`, or an element is inside another one.
 
 ```ts
 import { expect, test } from 'vitest'
@@ -876,7 +876,7 @@ test('spy function', () => {
 })
 ```
 
-## toHaveBeenCalledBefore <Version>2.2.0</Version> {#tohavebeencalledbefore}
+## toHaveBeenCalledBefore <Version>3.0.0</Version> {#tohavebeencalledbefore}
 
 - **Type**: `(mock: MockInstance, failIfNoFirstInvocation?: boolean) => Awaitable<void>`
 
@@ -895,7 +895,7 @@ test('calls mock1 before mock2', () => {
 })
 ```
 
-## toHaveBeenCalledAfter <Version>2.2.0</Version> {#tohavebeencalledafter}
+## toHaveBeenCalledAfter <Version>3.0.0</Version> {#tohavebeencalledafter}
 
 - **Type**: `(mock: MockInstance, failIfNoFirstInvocation?: boolean) => Awaitable<void>`
 
@@ -914,7 +914,7 @@ test('calls mock1 after mock2', () => {
 })
 ```
 
-## toHaveBeenCalledExactlyOnceWith <Version>2.2.0</Version> {#tohavebeencalledexactlyoncewith}
+## toHaveBeenCalledExactlyOnceWith <Version>3.0.0</Version> {#tohavebeencalledexactlyoncewith}
 
 - **Type**: `(...args: any[]) => Awaitable<void>`
 
@@ -1248,7 +1248,7 @@ test('buyApples returns new stock id', async () => {
 :::warning
 If the assertion is not awaited, then you will have a false-positive test that will pass every time. To make sure that assertions are actually called, you may use [`expect.assertions(number)`](#expect-assertions).
 
-Since Vitest 2.2, if a method is not awaited, Vitest will show a warning at the end of the test. In Vitest 3, the test will be marked as "failed" if the assertion is not awaited.
+Since Vitest 3, if a method is not awaited, Vitest will show a warning at the end of the test. In Vitest 4, the test will be marked as "failed" if the assertion is not awaited.
 :::
 
 ## rejects
@@ -1279,7 +1279,7 @@ test('buyApples throws an error when no id provided', async () => {
 :::warning
 If the assertion is not awaited, then you will have a false-positive test that will pass every time. To make sure that assertions were actually called, you can use [`expect.assertions(number)`](#expect-assertions).
 
-Since Vitest 2.2, if a method is not awaited, Vitest will show a warning at the end of the test. In Vitest 3, the test will be marked as "failed" if the assertion is not awaited.
+Since Vitest 3, if a method is not awaited, Vitest will show a warning at the end of the test. In Vitest 4, the test will be marked as "failed" if the assertion is not awaited.
 :::
 
 ## expect.assertions

docs/api/vi.md

@@ -33,7 +33,7 @@ If the `factory` function is defined, all imports will return its result. Vitest
 
 Unlike in `jest`, the factory can be asynchronous. You can use [`vi.importActual`](#vi-importactual) or a helper with the factory passed in as the first argument, and get the original module inside.
 
-Since Vitest 2.1, you can also provide an object with a `spy` property instead of a factory function. If `spy` is `true`, then Vitest will automock the module as usual, but it won't override the implementation of exports. This is useful if you just want to assert that the exported method was called correctly by another method.
+You can also provide an object with a `spy` property instead of a factory function. If `spy` is `true`, then Vitest will automock the module as usual, but it won't override the implementation of exports. This is useful if you just want to assert that the exported method was called correctly by another method.
 
 ```ts
 import { calculator } from './src/calculator.ts'

docs/config/index.md

@@ -26,7 +26,7 @@ export default defineConfig({
 })
 ```
 
-The `<reference types="vitest" />` will stop working in Vitest 3, but you can start migrating to `vitest/config` in Vitest 2.1:
+The `<reference types="vitest" />` will stop working in Vitest 4, but you can already start migrating to `vitest/config`:
 
 ```ts [vite.config.js]
 /// <reference types="vitest/config" />
@@ -579,8 +579,8 @@ These options are passed down to `setup` method of current [`environment`](#envi
 - **Type:** `[string, EnvironmentName][]`
 - **Default:** `[]`
 
-::: warning
-This API was deprecated in Vitest 2.2. Use [workspace](/guide/workspace) to define different configurations instead.
+::: danger DEPRECATED
+This API was deprecated in Vitest 3. Use [workspace](/guide/workspace) to define different configurations instead.
 
 ```ts
 export default defineConfig({
@@ -626,8 +626,8 @@ export default defineConfig({
 - **Type:** `[string, 'threads' | 'forks' | 'vmThreads' | 'vmForks' | 'typescript'][]`
 - **Default:** `[]`
 
-::: warning
-This API was deprecated in Vitest 2.2. Use [workspace](/guide/workspace) to define different configurations instead:
+::: danger DEPRECATED
+This API was deprecated in Vitest 3. Use [workspace](/guide/workspace) to define different configurations instead:
 
 ```ts
 export default defineConfig({
@@ -1193,7 +1193,7 @@ import { inject } from 'vitest'
 
 inject('wsPort') === 3000
 ```
-```ts [globalSetup.ts <Version>2.2.0</Version>]
+```ts [globalSetup.ts <Version>3.0.0</Version>]
 import type { TestProject } from 'vitest/node'
 
 export default function setup(project: TestProject) {
@@ -1221,7 +1221,7 @@ declare module 'vitest' {
 ```
 :::
 
-Since Vitest 2.2.0, you can define a custom callback function to be called when Vitest reruns tests. If the function is asynchronous, the runner will wait for it to complete before executing tests. Note that you cannot destruct the `project` like `{ onTestsRerun }` because it relies on the context.
+Since Vitest 3, you can define a custom callback function to be called when Vitest reruns tests. If the function is asynchronous, the runner will wait for it to complete before executing tests. Note that you cannot destruct the `project` like `{ onTestsRerun }` because it relies on the context.
 
 ```ts [globalSetup.ts]
 import type { TestProject } from 'vitest/node'
@@ -2571,7 +2571,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).
 
-Since Vitest 2.2, you can also define the workspace array in the root config. If the `workspace` is defined in the config manually, Vitest will ignore the `vitest.workspace` file in the root.
+Since Vitest 3, you can also define the workspace array in the root config. If the `workspace` is defined in the config manually, Vitest will ignore the `vitest.workspace` file in the root.
 
 ### isolate
 

docs/guide/browser/locators.md

@@ -389,7 +389,7 @@ It is recommended to use this only after the other locators don't work for your
 
 ## Methods
 
-All methods are asynchronous and must be awaited. Since Vitest 2.2, tests will fail if a method is not awaited.
+All methods are asynchronous and must be awaited. Since Vitest 3, tests will fail if a method is not awaited.
 
 ### click
 

docs/guide/environment.md

@@ -16,7 +16,7 @@ By default, you can use these environments:
 ::: info
 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.external`](/config/#server-deps-external). 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.external`.
 
-Since Vitest 2.0.4 the `require` of CSS and assets inside the external dependencies are resolved automatically.
+The `require` of CSS and assets inside the external dependencies are resolved automatically.
 :::
 
 ::: warning

docs/guide/filtering.md

@@ -24,7 +24,7 @@ basic/foo.test.ts
 
 You can also use the `-t, --testNamePattern <pattern>` option to filter tests by full name. This can be helpful when you want to filter by the name defined within a file rather than the filename itself.
 
-Since Vitest 2.2, you can also specify the test by filename and line number:
+Since Vitest 3, you can also specify the test by filename and line number:
 
 ```bash
 $ vitest basic/foo.test.ts:10

docs/guide/reporters.md

@@ -373,7 +373,7 @@ Example of a JSON report:
 ```
 
 ::: info
-Since Vitest 2.2, the JSON reporter includes coverage information in `coverageMap` if coverage is enabled.
+Since Vitest 3, the JSON reporter includes coverage information in `coverageMap` if coverage is enabled.
 :::
 
 ### HTML Reporter

docs/guide/test-context.md

@@ -180,7 +180,7 @@ test('works correctly')
 
 #### Default fixture
 
-Since Vitest 2.2, you can provide different values in different [projects](/guide/workspace). To enable this feature, pass down `{ injected: true }` to the options. If the key is not specified in the [project configuration](/config/#provide), then the default value will be used.
+Since Vitest 3, you can provide different values in different [projects](/guide/workspace). To enable this feature, pass down `{ injected: true }` to the options. If the key is not specified in the [project configuration](/config/#provide), then the default value will be used.
 
 :::code-group
 ```ts [fixtures.test.ts]

docs/guide/workspace.md

@@ -16,7 +16,7 @@ Vitest provides a way to define multiple project configurations within a single
 
 A workspace must include a `vitest.workspace` or `vitest.projects` file in its root directory (located in the same folder as your root configuration file or working directory if it doesn't exist). Note that `projects` is just an alias and does not change the behavior or semantics of this feature. Vitest supports `ts`, `js`, and `json` extensions for this file.
 
-Since Vitest 2.2, you can also define a workspace in the root config. In this case, Vitest will ignore the `vitest.workspace` file in the root, if one exists.
+Since Vitest 3, you can also define a workspace in the root config. In this case, Vitest will ignore the `vitest.workspace` file in the root, if one exists.
 
 ::: tip NAMING
 Please note that this feature is named `workspace`, not `workspaces` (without an "s" at the end).
@@ -30,7 +30,7 @@ export default [
   'packages/*'
 ]
 ```
-```ts [vitest.config.ts <Version>2.2.0</Version>]
+```ts [vitest.config.ts <Version>3.0.0</Version>]
 import { defineConfig } from 'vitest/config'
 
 export default defineConfig({
@@ -41,7 +41,7 @@ export default defineConfig({
 ```
 :::
 
-Vitest will treat every folder in `packages` as a separate project even if it doesn't have a config file inside. Since Vitest 2.1, if this glob pattern matches any file it will be considered a Vitest config even if it doesn't have a `vitest` in its name.
+Vitest will treat every folder in `packages` as a separate project even if it doesn't have a config file inside. If this glob pattern matches any file it will be considered a Vitest config even if it doesn't have a `vitest` in its name.
 
 ::: warning
 Vitest does not treat the root `vitest.config` file as a workspace project unless it is explicitly specified in the workspace configuration. Consequently, the root configuration will only influence global options such as `reporters` and `coverage`.
@@ -55,7 +55,7 @@ export default [
   'packages/*/vitest.config.{e2e,unit}.ts'
 ]
 ```
-```ts [vitest.config.ts <Version>2.2.0</Version>]
+```ts [vitest.config.ts <Version>3.0.0</Version>]
 import { defineConfig } from 'vitest/config'
 
 export default defineConfig({
@@ -97,7 +97,7 @@ export default defineWorkspace([
   }
 ])
 ```
-```ts [vitest.config.ts <Version>2.2.0</Version>]
+```ts [vitest.config.ts <Version>3.0.0</Version>]
 import { defineConfig } from 'vitest/config'
 
 export default defineConfig({
@@ -140,7 +140,7 @@ If you do not use inline configurations, you can create a small JSON file in you
   "packages/*"
 ]
 ```
-```ts [vitest.config.ts <Version>2.2.0</Version>]
+```ts [vitest.config.ts <Version>3.0.0</Version>]
 import { defineConfig } from 'vitest/config'
 
 export default defineConfig({
@@ -272,7 +272,7 @@ export default defineWorkspace([
   },
 ])
 ```
-```ts [vitest.config.ts <Version>2.2.0</Version>]
+```ts [vitest.config.ts <Version>3.0.0</Version>]
 import { defineConfig } from 'vitest/config'
 import react from '@vitejs/plugin-react'