diff --git a/api/advanced/plugin.md b/api/advanced/plugin.md
index b1608efd..1940d115 100644
--- a/api/advanced/plugin.md
+++ b/api/advanced/plugin.md
@@ -117,7 +117,7 @@ vitest.config.project.push('my-project-name')
:::
::: tip 引用当前配置
-内联配置默认继承根配置。如果想改为继承特定的配置文件,请将 `extends` 属性设为该文件的路径。其他所有属性都会与用户定义的配置合并。
+内联配置默认继承顶级配置。如果想改为继承特定的配置文件,请将 `extends` 属性设为该文件的路径。其他所有属性都会与用户定义的配置合并。
项目的 `configFile` 可以在 Vite 的配置中访问:`project.vite.config.configFile`。
diff --git a/api/advanced/vitest.md b/api/advanced/vitest.md
index 732dc615..37f53b22 100644
--- a/api/advanced/vitest.md
+++ b/api/advanced/vitest.md
@@ -11,7 +11,7 @@ Since Vitest 5, this property is always `'test'`.
## config
-这是根配置(也叫全局配置)。如果你在配置中定义了多个项目,这些项目都会将这个配置视作它们的 `globalConfig` 并进行继承或引用。
+这是顶级配置(也叫全局配置)。如果你在配置中定义了多个项目,这些项目都会将这个配置视作它们的 `globalConfig` 并进行继承或引用。
::: warning
这是 Vitest 配置,它不扩展 _Vite_ 配置。它仅包含从 `test` 属性解析的值。
@@ -63,7 +63,7 @@ Vitest 会保证这个数组里至少有一个项目可用。如果用户在命
function getRootProject(): TestProject
```
-该方法会返回根测试项目。一般情况下,根项目并不会实际执行测试,也不会被加入到 `vitest.projects` 列表中,除非用户在配置中主动包含了根配置,或者没有定义任何独立的测试项目。
+该方法会返回根测试项目。一般情况下,根项目并不会实际执行测试,也不会被加入到 `vitest.projects` 列表中,除非用户在配置中主动包含了顶级配置,或者没有定义任何独立的测试项目。
根项目的主要目标是设置全局配置。实际上,`rootProject.config` 直接引用 `rootProject.globalConfig` 和 `vitest.config`:
diff --git a/blog/vitest-3-2.md b/blog/vitest-3-2.md
index ccc47170..ca4ae615 100644
--- a/blog/vitest-3-2.md
+++ b/blog/vitest-3-2.md
@@ -35,7 +35,7 @@ Vitest 3.2 专注于改进浏览器模式和 TypeScript 支持。此版本还包
## `workspace` 已弃用 {#workspace-is-deprecated}
-为了简化配置,团队决定弃用单独的 `vitest.workspace` 文件,推荐仅在根配置中使用 `projects` 选项。这也简化了全局选项的配置方式(因为当你没有根配置时,不需要再猜测如何添加报告器)。
+为了简化配置,团队决定弃用单独的 `vitest.workspace` 文件,推荐仅在顶级配置中使用 `projects` 选项。这也简化了全局选项的配置方式(因为当你没有顶级配置时,不需要再猜测如何添加报告器)。
我们还决定弃用 `workspace` 这个名称,因为它与 PNPM 等工具通过该选项提供 monorepo 支持功能存在冲突。Vitest 不会为这些项目分配独立的 `工作目录(CWD)`,而是将其视为子 Vitest 实例。这也为我们提供了更多空间,以便在不破坏其他功能的情况下为 monorepo 提供更好的解决方案。
diff --git a/config/attachmentsdir.md b/config/attachmentsdir.md
index 75890078..b9a62899 100644
--- a/config/attachmentsdir.md
+++ b/config/attachmentsdir.md
@@ -10,4 +10,4 @@ outline: deep
指定通过 [`context.annotate`](/guide/test-context#annotate) 创建的文件附件的存储目录。
-Vitest 会相对于根配置解析此路径。使用 [`projects`](/guide/projects) 时,所有项目共用同一个 `attachmentsDir`,无法为每个项目单独配置。
+Vitest 会相对于顶级配置解析此路径。使用 [`projects`](/guide/projects) 时,所有项目共用同一个 `attachmentsDir`,无法为每个项目单独配置。
diff --git a/config/browser/instances.md b/config/browser/instances.md
index 890432ea..900a226c 100644
--- a/config/browser/instances.md
+++ b/config/browser/instances.md
@@ -13,7 +13,7 @@ outline: deep
你可以指定大多数 [项目选项](/config/)(未标记图标的)以及部分 `browser` 选项,如 `browser.testerHtmlPath`。
::: warning
-每个浏览器配置都会继承根配置的选项:
+每个浏览器配置都会继承顶级配置的选项:
```ts{3,9} [vitest.config.ts]
export default defineConfig({
@@ -26,7 +26,7 @@ export default defineConfig({
{
// 将同时包含 "root" 和 "browser" 两个全局初始化文件
setupFile: ['./browser-setup-file.js'],
- // 隐式继承根配置的"testerHtmlPath" // [!code warning]
+ // 隐式继承顶级配置的"testerHtmlPath" // [!code warning]
// testerHtmlPath: './custom-path.html', // [!code warning]
},
],
diff --git a/config/experimental.md b/config/experimental.md
index a790a962..35e4a79d 100644
--- a/config/experimental.md
+++ b/config/experimental.md
@@ -185,7 +185,7 @@ vitest --experimental.importDurations.failOnDanger
控制 Vitest 是否使用 Vite 的 [模块运行器](https://cn.vite.dev/guide/api-environment-runtimes#modulerunner) 执行代码,或回退至原生 `import` 方式。
-如果在根配置中定义此选项,所有 [项目](/guide/projects) 将自动继承该设置。
+如果在顶级配置中定义此选项,所有 [项目](/guide/projects) 将自动继承该设置。
当测试运行环境与代码执行环境相同时(例如服务端后端或简单脚本),可考虑禁用模块运行器。但对于 `jsdom`/`happy-dom` 测试,我们仍建议使用 Vite 模块运行器或在 [浏览器模式](/guide/browser/) 中运行,因为这样无需添加额外的配置。
diff --git a/config/index.md b/config/index.md
index 3910f990..22aeeeb1 100644
--- a/config/index.md
+++ b/config/index.md
@@ -87,4 +87,4 @@ export default defineConfig(configEnv => mergeConfig(
## 配置选项 {#config-options}
-在 [项目](/guide/projects) 配置中不支持的配置选项旁边会显示 图标。这意味着它们只能在 Vitest 根配置文件中进行设置。
+在 [项目](/guide/projects) 配置中不支持的配置选项旁边会显示 图标。这意味着它们只能在 Vitest 顶级配置文件中进行设置。
diff --git a/config/sequence.md b/config/sequence.md
index 1f2b22cb..92fa82be 100644
--- a/config/sequence.md
+++ b/config/sequence.md
@@ -108,7 +108,7 @@ Vitest 通常使用缓存对测试进行排序,使耗时较长的测试优先
是否随机排列测试文件。请注意,启用此选项后,耗时较长的测试将无法优先开始执行。
-由于所有 [项目](/guide/projects) 共享同一套文件排序,因此此选项只能由根配置决定。各个项目仍可通过 [`sequence.shuffle.tests`](#sequence-shuffle-tests) 随机排列自身的测试用例。
+由于所有 [项目](/guide/projects) 共享同一套文件排序,因此此选项只能由顶级配置决定。各个项目仍可通过 [`sequence.shuffle.tests`](#sequence-shuffle-tests) 随机排列自身的测试用例。
### sequence.shuffle.tests {#sequence-shuffle-tests}
diff --git a/guide/advanced/benchmark-provider.md b/guide/advanced/benchmark-provider.md
index be8975ab..7872700c 100644
--- a/guide/advanced/benchmark-provider.md
+++ b/guide/advanced/benchmark-provider.md
@@ -1,5 +1,6 @@
# Custom Benchmark Provider 5.0.0 advanced {#custom-benchmark-provider}
+
::: warning
This is an advanced, experimental API. If you only need to run benchmarks with Vitest's built-in provider, read the [Benchmarking](/guide/benchmarking) guide instead.
:::
diff --git a/guide/advanced/index.md b/guide/advanced/index.md
index 073fff39..95b98289 100644
--- a/guide/advanced/index.md
+++ b/guide/advanced/index.md
@@ -1,5 +1,5 @@
---
-title: Advanced API
+title: 高级 API
---
# 快速起步 advanced {#getting-started}
@@ -90,8 +90,8 @@ function resolveConfig(
```
此方法使用自定义参数解析配置,而不会创建 Vite 服务器。如果未提供任何参数,root 将设为 process.cwd()。
-
-It returns the resolved Vite config. The fully resolved Vitest config, including every project, lives on its `test` property.
+
+该方法返回解析后的 Vite 配置。其 `test` 属性包含完整解析后的 Vitest 配置,其中包括所有项目。
```ts
import { resolveConfig } from 'vitest/node'
@@ -121,34 +121,33 @@ viteConfig.test.pool // 'threads'
另外请注意,`viteConfig.test` 不会被完全解析。如果你需要 Vitest 配置,请使用 `vitestConfig` 代替。
:::
-
-## Project Configuration Resolution
+## 解析项目配置 {#project-configuration-resolution}
-This section describes how the arguments of `startVitest`, `createVitest`, and `resolveConfig` interact with [test projects](/guide/projects). Without projects, all resolved options apply to the single root project and none of this matters.
+本节说明 `startVitest`、`createVitest` 和 `resolveConfig` 的参数如何影响 [测试项目](/guide/projects)。在没有项目配置的情况下,解析后的所有选项都会应用于唯一的顶级项目,因此无须考虑以下规则。
-The root configuration is resolved from three inputs, in ascending priority:
+顶级配置由以下三类输入解析而成,优先级从低到高依次为:
-1. the root config file
-2. `viteOverrides`, merged on top of the config file values
-3. CLI options (`options`), applied on top of everything else
+1. 顶级配置文件
+2. `viteOverrides`,其内容会覆盖配置文件中的对应值
+3. CLI 选项(`options`),其优先级高于其他所有配置
-Every project then resolves its own Vite config independently:
+每个项目随后独立解析其自身的 Vite 配置:
-- A project referenced as a config file or a directory resolves only its own file. It does not inherit any options from the root configuration.
-- An inline project inherits the root configuration by default (see [`extends`](/guide/projects#configuration)): the root config file is re-executed for the project, `viteOverrides` are merged on top of it, and the project's own options are merged last. Inheritance works even when there is no root config file, because `viteOverrides` are part of the effective root configuration.
-- With `extends: false`, an inline project resolves only its own options. With `extends: './path'`, the referenced file is re-executed instead of the root config file, and `viteOverrides` are not merged.
+- 通过配置文件或目录引用的项目只解析自身的配置文件,不会继承顶级配置中的任何选项。
+- 默认情况下,内联项目会继承顶级配置(参阅 [`extends`](/guide/projects#configuration))。会为该项目重新执行顶级配置文件,然后合并 `viteOverrides`,最后再合并项目自身的选项。即使不存在顶级配置文件,继承仍然有效,因为 `viteOverrides` 也属于最终生效的顶级配置。
+- 设置 `extends: false` 后,内联项目只解析自身的选项。设置 `extends: './path'` 后,会重新执行所引用的文件,而不是顶级配置文件,并且不会合并 `viteOverrides`。
-A few options are excluded from inheritance:
+以下选项不会按常规规则继承:
-- `plugins` from `viteOverrides` are never inherited. A config file is re-executed for every project, which creates fresh plugin instances, but plugin instances passed in `viteOverrides` belong to the root Vite server and cannot be shared with project servers.
-- `test.browser` and `test.tagsFilter` from `viteOverrides` are never inherited: `browser` describes the instances of a single project, and `tagsFilter` applies to the whole run.
-- `name` and `projects` are never inherited; the root `globalSetup` is not inherited because it already runs once per test run.
-- The project's own `tags` always replace the `tags` array merged from an extended config instead of being concatenated with it, so the same tag names can be redefined.
+- 永远不会继承 `viteOverrides` 中的 `plugins`。配置文件会为每个项目重新执行,从而创建新的插件实例;但通过 `viteOverrides` 传入的插件实例属于顶级 Vite 服务器,无法与项目服务器共享。
+- 永远不会继承 `viteOverrides` 中的 `test.browser` 和 `test.tagsFilter`。`browser` 描述单个项目的浏览器实例,而 `tagsFilter` 作用于整次测试运行。
+- 永远不会继承 `name` 和 `projects`。顶级配置中的 `globalSetup` 也不会被继承,因为它已经会在每次测试运行时执行一次。
+- 项目自身的 `tags` 始终会替换从被继承配置中合并而来的 `tags` 数组,而不是与其拼接,因此可以重新定义同名标签。
-Independently of `extends`, two groups of options reach every project:
+独立与 `extends` 机制,以下两组选项都会应用于每个项目:
-- A fixed subset of CLI options that configure how tests run (`--testTimeout`, `--retry`, `--pool`, and similar) is applied to every project at the highest priority, mirroring the root resolution.
-- Run-level options only make sense for the test run as a whole: every project receives the root's resolved `coverage`, `attachmentsDir`, and `mergeReportsLabel` values.
+- 一组用于控制测试运行方式的固定 CLI 选项,例如 `--testTimeout`、`--retry` 和 `--pool`,会以最高优先级应用于每个项目,与顶级配置的解析方式一致。
+- 运行级选项只对整次测试运行有意义,因此每个项目都会使用顶级配置解析后的 `coverage`、`attachmentsDir` 和 `mergeReportsLabel` 值。
## parseCLI
@@ -182,7 +181,7 @@ result.filter
function createCLI(options?: CliParseOptions): CAC
```
-Creates the Vitest command-line interface: a [`cac`](https://github.com/cacjs/cac) instance with all of Vitest's commands and options registered. [`parseCLI`](#parsecli) is built on top of it; use `createCLI` directly if you need the raw parser.
+创建 Vitest 命令行界面,返回一个注册了 Vitest 全部命令和选项的 [`cac`](https://github.com/cacjs/cac) 实例。[`parseCLI`](#parsecli) 基于该实例实现;如果需要直接使用原始解析器,请调用 `createCLI`。
```ts
import { createCLI } from 'vitest/node'
@@ -202,9 +201,9 @@ class PluginHarness {
}
```
-A container that Vitest passes to its internal plugins while the config is being resolved, before a [`Vitest`](/api/advanced/vitest) instance exists. It holds the [`Logger`](#logger), the package installer and the resolved version, and exposes the `Vitest` instance via `getVitest()` once it has been created (calling it earlier throws).
+这是一个容器,在配置解析期间、[`Vitest`](/api/advanced/vitest) 会将此容器传递给内部插件。它保存 [`Logger`](#logger)、包安装器和解析后的版本,并在 `Vitest` 实例创建后通过 `getVitest()` 提供该实例(如果提前调用此方法,则会抛出错误)。
-This is an advanced, plugin-facing API. You rarely construct one directly, but you can pass a shared instance to [`resolveConfig`](#resolveconfig) to reuse a logger and package installer.
+这是一个面向插件的高级 API。通常有很少机会直接实现它。但你可以向 [`resolveConfig`](#resolveconfig) 传递一个共享实例,以复用日志记录器和包安装器。
## Logger
@@ -217,7 +216,7 @@ class Logger {
}
```
-Vitest's terminal logger, exposed as [`vitest.logger`](/api/advanced/vitest). It handles formatted output, the error summary, the run banner and screen clearing. Construct one with custom `stdout`/`stderr` streams to capture or redirect Vitest's output when running it programmatically.
+Vitest 的终端日志记录器,通过 [`vitest.logger`](/api/advanced/vitest) 暴露。它负责格式化输出、错误摘要、运行横幅和终端清屏。以编程方式运行 Vitest 时,可以使用自定义的 `stdout`/`stderr` 流创建 `Logger`,以捕获或重定向 Vitest 的输出。
```ts
import { Logger } from 'vitest/node'
diff --git a/guide/advanced/pool.md b/guide/advanced/pool.md
index 5ae745c1..dd2d2ff8 100644
--- a/guide/advanced/pool.md
+++ b/guide/advanced/pool.md
@@ -1,5 +1,5 @@
# Custom Pool advanced {#custom-pool}
-
+
::: warning
This is an advanced, experimental and very low-level API. If you just want to [run tests](/guide/), you probably don't need this. It is primarily used by library authors.
:::
diff --git a/guide/browser/multiple-setups.md b/guide/browser/multiple-setups.md
index 9a36ddcb..610bba4c 100644
--- a/guide/browser/multiple-setups.md
+++ b/guide/browser/multiple-setups.md
@@ -82,7 +82,7 @@ test('ratio works', () => {
## 过滤 {#filtering}
-你可以使用 [`--project` 参数](/guide/cli#project) 来过滤要运行的项目。如果未手动分配项目名称,Vitest 会自动将浏览器名称作为项目名称。如果根配置已经有一个名称,Vitest 会将它们合并:`custom` -> `custom (browser)`。
+你可以使用 [`--project` 参数](/guide/cli#project) 来过滤要运行的项目。如果未手动分配项目名称,Vitest 会自动将浏览器名称作为项目名称。如果顶级配置已经有一个名称,Vitest 会将它们合并:`custom` -> `custom (browser)`。
```shell
$ vitest --project=chromium
diff --git a/guide/browser/visual-regression-testing.md b/guide/browser/visual-regression-testing.md
index 70025663..ba6432eb 100644
--- a/guide/browser/visual-regression-testing.md
+++ b/guide/browser/visual-regression-testing.md
@@ -2,7 +2,7 @@
title: 可视化回归测试
outline: [2, 3]
---
-
+
diff --git a/guide/cli-generated.md b/guide/cli-generated.md
index 0a0f87c4..1865d8cb 100644
--- a/guide/cli-generated.md
+++ b/guide/cli-generated.md
@@ -56,7 +56,7 @@
- **命令行终端:** `--api.port [port]`
-指定服务器端口。注意,如果端口已被使用,Vite 会自动尝试下一个可用端口,因此这可能不是服务器最终监听的实际端口。如果为 `true`,将设置为`51204`
+指定服务器端口。注意,如果端口已被使用,Vite 会自动尝试下一个可用端口,因此这可能不是服务器最终监听的实际端口。如果为 `true`,将设置为 `51204`
### api.host
@@ -200,7 +200,7 @@ Coverage reporters to use. Visit [`coverage.reporter`](/config/coverage#coverage
- **命令行终端:** `--coverage.thresholds.perFile `
- **配置:** [coverage.thresholds.perFile](/config/coverage#coverage-thresholds-perfile)
-检查每个文件的阈值。 `--coverage.thresholds.lines`, `--coverage.thresholds.functions`, `--coverage.thresholds.branches`, `--coverage.thresholds.statements` 为实际阈值(默认值:`false`)。对象形式仅在配置文件中可用。
+检查每个文件的阈值。`--coverage.thresholds.lines`, `--coverage.thresholds.functions`, `--coverage.thresholds.branches`, `--coverage.thresholds.statements` 为实际阈值(默认值:`false`)。对象形式仅在配置文件中可用。
### coverage.thresholds.autoUpdate
@@ -238,7 +238,7 @@ Coverage reporters to use. Visit [`coverage.reporter`](/config/coverage#coverage
- **命令行终端:** `--coverage.ignoreClassMethods `
- **配置:** [coverage.ignoreClassMethods](/config/coverage#coverage-ignoreclassmethods)
-覆盖时要忽略的类方法名称数组。更多信息请访问 [istanbuljs](https://github.com/istanbuljs/nyc#ignoring-methods) 。该选项仅适用于 istanbul providers(默认值:`[]`)
+覆盖时要忽略的类方法名称数组。更多信息请访问 [istanbuljs](https://github.com/istanbuljs/nyc#ignoring-methods)。该选项仅适用于 istanbul providers(默认值:`[]`)
### coverage.processingConcurrency
@@ -258,25 +258,25 @@ Coverage reporters to use. Visit [`coverage.reporter`](/config/coverage#coverage
- **命令行终端:** `--coverage.watermarks.statements `
-语句覆盖率高/低阈值,格式: `,`
+语句覆盖率高/低阈值,格式:`,`
### coverage.watermarks.lines
- **命令行终端:** `--coverage.watermarks.lines `
-行覆盖率高/低阈值,格式: `,`
+行覆盖率高/低阈值,格式:`,`
### coverage.watermarks.branches
- **命令行终端:** `--coverage.watermarks.branches `
-分支覆盖率高/低阈值,格式: `,`
+分支覆盖率高/低阈值,格式:`,`
### coverage.watermarks.functions
- **命令行终端:** `--coverage.watermarks.functions `
-函数覆盖率高/低阈值,格式: `,`
+函数覆盖率高/低阈值,格式:`,`
### coverage.changed
@@ -329,10 +329,10 @@ UI 模式和 HTML 报告器中提供的 HTML 覆盖率输出目录。
### injectCjsGlobals
-- **CLI:** `--injectCjsGlobals`
-- **Config:** [injectCjsGlobals](/config/injectcjsglobals)
+- **命令行终端:** `--injectCjsGlobals`
+- **配置:** [injectCjsGlobals](/config/injectcjsglobals)
-Inject CommonJS variables (`module`, `exports`, `require`, `__filename`, `__dirname`) into every test module. To disable, use `--no-inject-cjs-globals` (default: `true`)
+向每个测试模块中注入 CommonJS 变量(`module`、`exports`、`require`、`__filename`、`__dirname`)。如需禁用请使用 `--no-inject-cjs-globals`(默认值:`true`)。
### dom
@@ -383,10 +383,10 @@ Inject CommonJS variables (`module`, `exports`, `require`, `__filename`, `__dirn
### browser.dependencySourcemaps
-- **CLI:** `--browser.dependencySourcemaps`
-- **Config:** [browser.dependencySourcemaps](/config/browser/dependencysourcemaps)
+- **命令行终端:** `--browser.dependencySourcemaps`
+- **配置:** [browser.dependencySourcemaps](/config/browser/dependencysourcemaps)
-Serve sourcemaps of dependencies to the browser in headless runs, used by devtools when debugging into `node_modules`. Reported test errors are source-mapped either way. Use `--browser.dependencySourcemaps=false` to speed up test runs if you don't step into dependency code (default: `true`)
+在无头模式下运行测试时,向浏览器提供依赖项的 source map,供开发者工具调试 `node_modules` 中的代码。无论是否启用此选项,Vitest 都会使用 source map 映射测试错误。如果不需要单步调试依赖项代码,可使用 `--browser.dependencySourcemaps=false` 加快测试运行速度(默认值:`true`)
### browser.trackUnhandledErrors
@@ -506,13 +506,13 @@ Serve sourcemaps of dependencies to the browser in headless runs, used by devtoo
- **配置:** [dangerouslyIgnoreUnhandledErrors](/config/dangerouslyignoreunhandlederrors)
忽略任何未处理的错误
-
+
### changed
-- **CLI:** `--changed [since]`
-- **Config:** [changed](/config/changed)
+- **命令行终端:** `--changed [since]`
+- **配置:** [changed](/config/changed)
-Run tests that are affected by the changed files (default: `false`)
+运行受文件变更影响的测试(默认值:`false`)。
### sequence.shuffle.files
@@ -540,7 +540,7 @@ Run tests that are affected by the changed files (default: `false`)
- **命令行终端:** `--sequence.seed `
- **配置:** [sequence.seed](/config/sequence#sequence-seed)
-设置随机化种子。如果 --sequence.shuffle(随机序列)是`false`,则此选项无效。更多信息请参阅 ["随机种子"](https://en.wikipedia.org/wiki/Random_seed)。
+设置随机化种子。如果 --sequence.shuffle(随机序列)是 `false`,则此选项无效。更多信息请参阅 ["随机种子"](https://en.wikipedia.org/wiki/Random_seed)。
### sequence.hooks
@@ -594,7 +594,7 @@ Run tests that are affected by the changed files (default: `false`)
- **命令行终端:** `--retry.count `
- **配置:** [retry.count](/config/retry#retry-count)
-如果测试失败,重试特定次数(默认值: `0`)
+如果测试失败,重试特定次数(默认值:`0`)
### retry.delay
@@ -818,20 +818,20 @@ Use TypeScript build mode
- **配置:** [maxConcurrency](/config/maxconcurrency)
测试文件执行期间并发运行的测试和测试套件的最大数量(默认值:`5`)
-
+
### fsModuleCache
-- **CLI:** `--fsModuleCache`
-- **Config:** [fsModuleCache](/config/fsmodulecache)
+- **命令行终端:** `--fsModuleCache`
+- **配置:** [fsModuleCache](/config/fsmodulecache)
-Cache transformed modules on the file system and reuse them between reruns (default: `false`)
+将转换后的模块缓存到文件系统中,以便在重新运行测试时复用(默认值:`false`)
### fsModuleCachePath
-- **CLI:** `--fsModuleCachePath `
-- **Config:** [fsModuleCachePath](/config/fsmodulecachepath)
+- **命令行终端:** `--fsModuleCachePath `
+- **配置:** [fsModuleCachePath](/config/fsmodulecachepath)
-Directory where the `fsModuleCache` is stored (default: `node_modules/.vitest-cache`)
+`fsModuleCache` 的存储目录(默认值:`node_modules/.vitest-cache`)
### expect.requireAssertions
@@ -852,7 +852,7 @@ Directory where the `fsModuleCache` is stored (default: `node_modules/.vitest-ca
- **命令行终端:** `--expect.poll.timeout `
- **配置:** [expect.poll.timeout](/config/expect#expect-poll-timeout)
-断言的轮询超时(以毫秒为单位) `expect.poll()` (默认值: `1000`)
+断言的轮询超时(以毫秒为单位)`expect.poll()` (默认值: `1000`)
### printConsoleTrace
diff --git a/guide/extending-matchers.md b/guide/extending-matchers.md
index 21385855..7baaea9a 100644
--- a/guide/extending-matchers.md
+++ b/guide/extending-matchers.md
@@ -34,10 +34,10 @@ declare module 'vitest' {
}
}
```
-
-`R` is the assertion return type, and `T` is the type of the received value.
-Return `R` from matchers that run synchronously. This makes the return type `void` for a regular assertion and `Promise` when the assertion is used with `.resolves`, `.rejects`, [`expect.poll`](/api/expect#poll), or [`expect.element`](/api/browser/assertions). You can use `T` when an expected argument should have the same type as the received value:
+`R` 表示断言的返回类型,`T` 表示接收值的类型。
+
+同步执行的匹配器应返回 `R`。对于普通断言,返回类型为 `void`;与 `.resolves`、`.rejects`、[`expect.poll`](/api/expect#poll) 或 [`expect.element`](/api/browser/assertions) 一起使用时,返回类型则为 `Promise`。如果预期值参数需要与接收值保持相同类型,可以使用 `T`:
```ts
declare module 'vitest' {
@@ -74,7 +74,7 @@ type MatcherResult = SyncMatcherResult | Promise
```
::: warning
-If a matcher implementation is asynchronous, declare its return type as `Promise` instead of `R` and don't forget to `await` it in the test:
+如果匹配器采用异步实现,请将其返回类型声明为 `Promise`,而不是 `R`,并且不要忘记在测试中使用 `await`:
```ts
expect.extend({
@@ -97,7 +97,7 @@ await expect('foo').toBeAsyncAssertion()
:::
-断言的第一个参数是接收值(即 `expect(received)` 中的 received ),其余参数将直接传给断言。其余参数将直接传递给匹配器。自 4.1 起,Vitest 提供了多个类型供自定义匹配器使用:
+匹配器的第一个参数是接收值,即 `expect(received)` 中的 received,其余参数会直接传递给匹配器。自 4.1 起,Vitest 提供了多个类型供自定义匹配器使用:
```ts
import type {
diff --git a/guide/improving-performance.md b/guide/improving-performance.md
index 4677a5bc..f170d3aa 100644
--- a/guide/improving-performance.md
+++ b/guide/improving-performance.md
@@ -100,18 +100,18 @@ Duration 8.75s (transform 4.02s, setup 629ms, import 5.52s, tests 2.52s, enviro
# 第二次运行
Duration 5.90s (transform 842ms, setup 543ms, import 2.35s, tests 2.94s, environment 0ms, prepare 3ms)
```
-
-## Node Compile Cache
-Vitest supports Node's [on-disk compile cache](https://nodejs.org/api/cli.html#node_compile_cachedir): when the `NODE_COMPILE_CACHE` environment variable points at a directory, the V8 bytecode of Vitest's own modules and of your externalized dependencies is written to disk and reused by later runs instead of being recompiled. Vitest propagates the variable to every worker, and workers persist the modules they compiled when they shut down.
+## Node 编译缓存 {#node-compile-cache}
+
+Vitest 支持 Node 的[磁盘编译缓存](https://nodejs.org/api/cli.html#node_compile_cachedir)。将 `NODE_COMPILE_CACHE` 环境变量设置为一个目录后,Vitest 自身模块和外部化依赖项的 V8 字节码会写入磁盘,后续运行时可以直接复用,无须重新编译。Vitest 会将该环境变量传递给每个 worker;worker 关闭时,会把它所编译的模块持久化到磁盘。
```shell
NODE_COMPILE_CACHE=node_modules/.cache/node-compile-cache vitest
```
-The first run with an empty directory pays for serializing the compiled modules, so this is only worth enabling when the directory survives between runs: local runs, or CI pipelines that cache the directory. `NODE_DISABLE_COMPILE_CACHE=1` disables the cache entirely, taking precedence over `NODE_COMPILE_CACHE`.
+首次使用空目录时,序列化已编译模块会产生额外开销。因此,只有缓存目录能在多次运行之间保留,启用编译缓存才有收益。这适用于本地运行,也适用于会缓存该目录的 CI 流水线。设置 `NODE_DISABLE_COMPILE_CACHE=1` 可完全禁用编译缓存,其优先级高于 `NODE_COMPILE_CACHE`。
-Note that Vitest automatically disables the compile cache in workers when the `v8` coverage provider is enabled — V8 serializes cached scripts without the source positions that precise coverage relies on.
+请注意,启用 `v8` 覆盖率 provider 后,Vitest 会自动禁用 worker 中的编译缓存。这是因为 V8 序列化缓存脚本时不会保留精确覆盖率所需的源码位置信息。
## 运行池 {#pool}
@@ -164,7 +164,7 @@ VITEST_BLOB_LABEL=linux vitest run --reporter=blob --shard=1/3
```
::: details GitHub Actions 示例
-This setup is also used at https://github.com/vitest-tests/test-sharding.
+此配置也用于 https://github.com/vitest-tests/test-sharding。
```yaml
# 灵感来至于 https://playwright.dev/docs/test-sharding
diff --git a/guide/learn/mock-functions.md b/guide/learn/mock-functions.md
index 0f3c1f8e..8b551a7c 100644
--- a/guide/learn/mock-functions.md
+++ b/guide/learn/mock-functions.md
@@ -71,9 +71,9 @@ test('mock async return values', async () => {
await expect(fetchUser()).rejects.toThrow('Not found')
})
```
-
+
::: tip
-`mockReturnValue` always returns the same value regardless of the arguments the mock receives. If you need argument-specific return values, [`vi.when`](/api/vi#vi-when) lets you attach different behaviors for different argument combinations without writing your own `if/else` logic. See the [Conditional Mocking](/guide/recipes/conditional-mocking) recipe for details.
+无论模拟函数接收到什么参数,`mockReturnValue` 始终返回相同的值。如果需要根据参数返回不同的结果,可以使用 [`vi.when`](/api/vi#vi-when) 为不同的参数组合指定相应行为,无须自行编写 `if/else` 逻辑。详情请参阅 [条件模拟](/guide/recipes/conditional-mocking) 示例。
:::
## 模拟实现 {#mock-implementation}
diff --git a/guide/learn/setup-teardown.md b/guide/learn/setup-teardown.md
index 1823e439..1efd6e2f 100644
--- a/guide/learn/setup-teardown.md
+++ b/guide/learn/setup-teardown.md
@@ -41,12 +41,12 @@ test('can remove an item', () => {
test('can add an item', () => {
items.push('date')
expect(items).toHaveLength(4)
- // beforeEach reset the array to 3 items before this test ran,
- // proving that mutations from the previous test do not leak.
+ // 运行此测试前,beforeEach 会将数组重置为 3 项,
+ // 由此可见,上一个测试对数组的修改不会影响当前测试。
})
```
-
-Without these hooks, mutations like `pop` or `push` from earlier tests would affect subsequent ones, which is a classic source of flaky tests, while the hooks guarantee clean state for every test.
+
+如果没有这些钩子,先前测试中的 `pop` 或 `push` 等操作会影响后续测试,这也是测试结果不稳定的常见原因。使用这些钩子,可以确保每个测试开始时都处于干净的状态。
## 一次性初始化 {#one-time-setup}
diff --git a/guide/lifecycle.md b/guide/lifecycle.md
index 4fa8b9ed..c576c852 100644
--- a/guide/lifecycle.md
+++ b/guide/lifecycle.md
@@ -137,12 +137,12 @@ afterEach(() => {
- `beforeEach` 钩子执行(按定义顺序,或基于 [`sequence.hooks`](/config/sequence#sequence-hooks))
- 测试函数执行
- `afterEach` 钩子执行(默认以 `sequence.hooks: 'stack'` 倒序执行)
- - Cleanup functions returned from `beforeEach` hooks execute (reverse order by default with `sequence.hooks: 'stack'`)
+ - 执行 `beforeEach` 钩子返回的清理函数(默认以 `sequence.hooks: 'stack'` 倒序执行)
- [`onTestFinished`](/api/hooks#ontestfinished) 回调执行(始终倒序)
- 如果测试失败:[`onTestFailed`](/api/hooks#ontestfailed) 回调执行
- 注意:如果设置了 `repeats` 或 `retry`,上述所有步骤会再次执行
6. **[`afterAll`](/api/hooks#afterall) 钩子:** 套件中所有测试完成后执行一次
-7. **Cleanup functions returned from `beforeAll` hooks:** Run once after all tests in the suite complete
+7. **`beforeAll` 钩子返回的清理函数:** 套件中的所有测试完成后执行一次
**执行流程示例:**
@@ -166,7 +166,7 @@ describe('User API', () => {
console.log('beforeAll')
return function beforeAllCleanup() {
- // Runs once afterAll hooks have run
+ // 在 afterAll 钩子执行后运行一次
console.log('beforeAllCleanup')
}
})
@@ -183,7 +183,7 @@ describe('User API', () => {
console.log('beforeEach')
return function beforeEachCleanup() {
- // Runs after afterEach hooks have run
+ // 在 afterEach 钩子执行后运行
console.log('beforeEachCleanup')
}
})
diff --git a/guide/projects.md b/guide/projects.md
index 580e3f33..1743350f 100644
--- a/guide/projects.md
+++ b/guide/projects.md
@@ -98,7 +98,7 @@ export default defineConfig({
```
::: warning
-Vitest 不会将根目录的 `vitest.config` 文件视为项目,除非在配置中显式指定。因此,根配置只会影响全局选项,如 `reporters` 和 `coverage`。但 Vitest 总会执行根配置文件中指定的某些插件钩子,如 `apply`、`config`、`configResolved` 或 `configureServer`。Vitest 也会使用相同的插件执行全局设置和自定义覆盖提供者。
+Vitest 不会将根目录的 `vitest.config` 文件视为项目,除非在配置中显式指定。因此,顶级配置只会影响全局选项,如 `reporters` 和 `coverage`。但 Vitest 总会执行顶级配置文件中指定的某些插件钩子,如 `apply`、`config`、`configResolved` 或 `configureServer`。Vitest 也会使用相同的插件执行全局设置和自定义覆盖提供者。
:::
你也可以用配置文件路径来引用项目:
@@ -116,7 +116,7 @@ export default defineConfig({
此模式只会包含带有 `e2e` 或 `unit` 字样的 `vitest.config` 文件的项目。
你还可以使用内联配置定义项目。两种语法可以同时使用。
-
+
```ts [vitest.config.ts]
import { defineConfig } from 'vitest/config'
@@ -126,8 +126,8 @@ export default defineConfig({
// 匹配 packages 文件夹下的所有文件和文件夹
'packages/*',
{
- // inline projects inherit the options
- // from this config file by default
+ // 默认情况下,内联项目会继承
+ // 此配置文件中的选项
test: {
include: ['tests/**/*.{browser}.test.{ts,js}'],
// 建议内联配置时定义项目名称
@@ -136,8 +136,8 @@ export default defineConfig({
}
},
{
- // add "extends: false" to ignore
- // the options defined in this config file
+ // 添加 "extends: false" 可忽略
+ // 此配置文件中定义的选项
extends: false,
test: {
include: ['tests/**/*.{node}.test.{ts,js}'],
@@ -236,8 +236,8 @@ bun run test --project e2e --project unit
:::
## 配置说明 {#configuration}
-
-Projects defined with an inline configuration inherit all options from the root-level configuration. This is controlled by the `extends` option, which is enabled by default since Vitest 5.0:
+
+使用内联配置定义的项目会继承顶级配置中的所有选项。是否继承由 `extends` 选项控制。从 Vitest 5.0 开始,该选项默认启用:
```ts [vitest.config.ts]
import { defineConfig } from 'vitest/config'
@@ -249,15 +249,15 @@ export default defineConfig({
pool: 'threads',
projects: [
{
- // inherits options from this config like plugins and pool
- // (`extends: true` is the default)
+ // 继承此配置中的 plugins、pool 等选项
+ // (默认值为 `extends: true`)
test: {
name: 'unit',
include: ['**/*.unit.test.ts'],
},
},
{
- // won't inherit any options from this config
+ // 不继承此配置中的任何选项
extends: false,
test: {
name: 'integration',
@@ -269,7 +269,7 @@ export default defineConfig({
})
```
-The `extends` option also accepts a path to another config file if you want to inherit options from a config file other than the root config:
+如果要继承顶级配置以外的其他配置文件,还可以将该配置文件的路径传给 `extends`:
```ts [vitest.config.ts]
import { defineConfig } from 'vitest/config'
@@ -289,15 +289,15 @@ export default defineConfig({
})
```
-All options from the extended config are merged with the project's own options. Note that arrays like `setupFiles` are concatenated, not overridden. A few options are treated specially:
+继承的配置会与项目自身的配置合并。请注意,`setupFiles` 等数组选项会进行拼接,而不是被覆盖。以下选项会采用特殊的处理方式:
-- `name` and `projects` are never inherited.
-- `globalSetup` is not inherited from the root config: the root-level `globalSetup` already runs once per test run, so inheriting it would run the same files again for every project. It is still inherited when extending a non-root config file.
-- The project's own `tags` replace the inherited array instead of being merged with it.
+- `name` 和 `projects` 永远不会被继承。
+- 不会从顶级配置继承 `globalSetup`。顶级配置中的 `globalSetup` 已经会在每次测试运行时执行一次,如果继续继承,每个项目都会再次运行相同的文件。不过,继承非顶级配置文件时,`globalSetup` 仍会被继承。
+- 如果项目自身定义了 `tags`,该数组会直接替换继承的值,而不会与其合并。
-If you run Vitest through the [advanced API](/guide/advanced/), see [Project Configuration Resolution](/guide/advanced/#project-configuration-resolution) for how the programmatic configuration participates in inheritance.
+如果通过 [高级 API](/guide/advanced/) 运行 Vitest,请参阅 [项目配置解析](/guide/advanced/#project-configuration-resolution),了解通过编程方式传入的配置如何参与继承。
-Projects referenced as config files or directories do not inherit any options from the root config. You can create a shared config file and merge it with the project config yourself:
+通过配置文件或目录引用的项目不会继承顶级配置中的任何选项。你可以创建一个共享配置文件,再自行将其与项目配置合并:
```ts [packages/a/vitest.config.ts]
import { defineProject, mergeConfig } from 'vitest/config'
@@ -313,15 +313,15 @@ export default mergeConfig(
)
```
-::: danger Unsupported Options
-Some of the configuration options are not allowed in a project config. Most notably:
+::: danger 不支持的选项
+某些配置选项不允许在项目配置中使用。最值得注意的是:
-所有不支持在项目配置中使用的配置选项,在 ["配置"](/config/) 指南中会用 标记。它们必须在根配置文件中定义一次。
+项目配置中不能使用部分配置选项。在 [“配置”](/config/) 指南中,所有不支持项目配置的选项都会用 标记。这些选项只能在顶级配置文件中定义一次。
:::
-## Nested Projects
+## 嵌套项目 {#nested-projects}
-A project referenced as a config file (or a directory containing one) can declare `projects` itself. Such a config behaves like the root config: it doesn't run any tests on its own, it only provides the projects that do. This makes it possible to reference a workspace that already defines its own projects:
+通过配置文件(或包含配置文件的目录)引用的项目,也可以在自身配置中声明 `projects`。这类配置的行为与顶级配置相同:它本身不运行测试,只负责提供实际运行测试的项目。借助这种方式,可以直接引用已经定义了项目的工作区:
```ts [vitest.config.ts]
import { defineConfig } from 'vitest/config'
@@ -357,11 +357,11 @@ export default defineProject({
})
```
-Nested projects work the same way as projects defined in the root config: inline configurations extend the config that declares them (the `app` config here, not the root one), `extends` paths are resolved relative to it, and its own `globalSetup` is inherited by the extending projects [like any other non-root config](#configuration).
+嵌套项目的行为与顶级配置中定义的项目相同。内联配置会继承声明它们的配置(在本例中是 `app` 配置,而不是顶级配置),`extends` 中的路径也会相对于该配置进行解析。该配置自身的 `globalSetup` 也会被这些项目继承,这与其他 [非顶级配置](#configuration) 的行为一致。
-The names of nested projects are prefixed with the name of the config that declares them, so the example above creates the `app (unit)` and `app (e2e)` projects. The `--project` filter matches the prefix as well: `--project app` runs every project of the `app` config, while `--project "app (unit)"` runs only one of them.
+嵌套项目的名称会加上声明它们的配置名称作为前缀。因此,上面的示例会创建 `app (unit)` 和 `app (e2e)` 两个项目。`--project` 也可以匹配此前缀:`--project app` 会运行 `app` 配置中的所有项目,而 `--project "app (unit)"` 只运行其中一个项目。
-To also run the tests of the config that declares `projects`, reference its own config file:
+如果还要运行声明了 `projects` 的配置自身所包含的测试,需要在 `projects` 中引用该配置文件本身:
```ts [packages/app/vitest.config.ts]
import { defineProject } from 'vitest/config'
@@ -371,7 +371,7 @@ export default defineProject({
name: 'app',
include: ['**/*.test.ts'],
projects: [
- // the "app" project runs its own "include" alongside "app (unit)"
+ // "app" 项目会根据自身的 "include" 运行测试,并与 "app (unit)" 项目一同执行
'./vitest.config.ts',
{
test: {
@@ -384,4 +384,4 @@ export default defineProject({
})
```
-Note that only config files can define nested projects. The `projects` option inside an inline configuration is not supported.
+请注意,只有配置文件可以定义嵌套项目,内联配置中不支持 `projects` 选项。
diff --git a/guide/reporters.md b/guide/reporters.md
index a34cfd2e..c08f1640 100644
--- a/guide/reporters.md
+++ b/guide/reporters.md
@@ -56,14 +56,14 @@ export default defineConfig({
```
## 报告器输出 {#reporter-output}
-
-By default, Vitest's reporters print their output to the terminal. The `json`, `junit` and `html` reporters instead write to a scoped location under `.vitest/`:
-- `json` writes `.vitest/json/output.json`
-- `junit` writes `.vitest/junit/output.xml`
-- `html` writes `.vitest/index.html`
+默认情况下,Vitest 报告器会将结果输出到终端。`json`、`junit` 和 `html` 报告器除外,它们会将结果写入 `.vitest/` 下各自的默认位置:
-The `json` and `junit` locations can be overridden with the `outputFile` [configuration option](/config/outputfile) in your Vitest configuration file or via CLI. The `html` reporter uses its [`outputDir`](#html-reporter) option instead.
+- `json` 写入 `.vitest/json/output.json`
+- `junit` 写入 `.vitest/junit/output.xml`
+- `html` 写入 `.vitest/index.html`
+
+你可以在 Vitest 配置文件或 CLI 中通过 [`outputFile` 配置项](/config/outputfile) 更改 `json` 和 `junit` 的输出位置。`html` 报告器则使用自身的 [`outputDir`](#html-reporter) 选项。
:::code-group
@@ -82,7 +82,7 @@ export default defineConfig({
:::
-The `json` and `junit` reporters also accept `outputFile` as a reporter option, which takes precedence over the top-level `outputFile`:
+`json` 和 `junit` 报告器也支持在报告器选项中设置 `outputFile`,其优先级高于顶层的 `outputFile` 配置:
```ts [vitest.config.ts]
export default defineConfig({
@@ -92,7 +92,7 @@ export default defineConfig({
})
```
-To print the report to the terminal instead of writing it to a file, set the `stdout` option on the `json` or `junit` reporter. This is ignored when `outputFile` is set:
+如果要将报告打印到终端,而不是写入文件,可以为 `json` 或 `junit` 报告器启用 `stdout` 选项。设置 `outputFile` 时 `stdout` 会被忽略:
```ts [vitest.config.ts]
export default defineConfig({
@@ -103,7 +103,7 @@ export default defineConfig({
```
::: warning
-When `stdout` is enabled, the report can be interleaved with other output written directly to the terminal — for example `process.stdout.write` in a test file, or logs from the main process such as a global setup file — which can make the JSON or XML unparsable. Prefer the default file output when you need to consume the report programmatically.
+启用 `stdout` 后,报告内容可能会与其他直接写入终端的输出混杂在一起。例如,测试文件中的 `process.stdout.write`,或全局初始化文件等主进程日志,都可能导致 JSON 或 XML 无法解析。如果需要通过程序读取报告,建议使用默认的文件输出方式。
:::
## 组合报告器 {#combining-reporters}
@@ -354,8 +354,8 @@ export default defineConfig({
```
### JUnit 报告器 {#junit-reporter}
-
-以 JUnit XML 格式输出测试结果报告。 By default it is written to `.vitest/junit/output.xml`. To write it elsewhere, use the [`outputFile`](/config/outputfile) configuration option or the reporter's own `outputFile` option. To print it to the terminal instead, set the reporter's [`stdout`](#reporter-output) option.
+
+以 JUnit XML 格式输出测试结果报告。报告默认写入 `.vitest/junit/output.xml`。如果要更改输出位置,请使用 [`outputFile`](/config/outputfile) 配置项或报告器自身的 `outputFile` 选项。如果要改为输出到终端,请启用报告器的 [`stdout`](#reporter-output) 选项。
:::code-group
@@ -464,10 +464,9 @@ export default defineConfig({
输出的 XML 包含嵌套的 `testsuites` 和 `testcase` 标记。你可以使用环境变量 `VITEST_JUNIT_SUITE_NAME` 和 `VITEST_JUNIT_CLASSNAME` 分别配置它们的名称和类名属性。
-
### JSON 报告器 {#json-reporter}
-Generates a report of the test results in a JSON format compatible with Jest's `--json` option. By default it is written to `.vitest/json/output.json`. To write it elsewhere, use the [`outputFile`](/config/outputfile) configuration option or the reporter's own `outputFile` option. To print it to the terminal instead, set the reporter's [`stdout`](#reporter-output) option.
+以兼容 Jest `--json` 选项的 JSON 格式生成测试结果报告。报告默认写入 `.vitest/json/output.json`。如果要更改输出位置,请使用 [`outputFile`](/config/outputfile) 配置项或报告器自身的 `outputFile` 选项。如果要改为输出到终端,请启用报告器的 [`stdout`](#reporter-output) 选项。
:::code-group
diff --git a/guide/snapshot.md b/guide/snapshot.md
index 2c98c86c..323c2658 100644
--- a/guide/snapshot.md
+++ b/guide/snapshot.md
@@ -122,7 +122,7 @@ test('button looks correct', async () => {
})
```
-它会捕获屏幕截图并与参考图像进行比较,以检测意外的视觉变化。在 [视觉回归测试指南](/guide/browser/visual-regression-testing)中了解更多内容。
+它会捕获屏幕截图并与参考图像进行比较,以检测意外的视觉变化。在 [视觉回归测试指南](/guide/browser/visual-regression-testing) 中了解更多内容。
## ARIA 快照 4.1.4 {#aria-snapshots}
@@ -235,7 +235,7 @@ Pretty foo: Object {
可通过 `vitest` 提供的 `Snapshots` 组合式函数构建自定义快照匹配器。这些函数允许你在生成快照前对值进行转换,同时完整保留快照生命周期支持(创建、更新、内联重写)。
```ts
-import { expect, test, Snapshots } from 'vitest'
+import { expect, Snapshots, test } from 'vitest'
const { toMatchFileSnapshot, toMatchInlineSnapshot, toMatchSnapshot } = Snapshots
@@ -252,7 +252,7 @@ expect.extend({
})
test('file snapshot', () => {
- // create __snapshots__/demo.test.ts with
+ // 创建 __snapshots__/demo.test.ts,内容如下:
// > exports[`file snapshot 1`] = `"extra long"`
expect('extra long string oh my gerd').toMatchTrimmedSnapshot(10)
})
@@ -262,7 +262,7 @@ test('inline snapshot', () => {
})
test('raw file snapshot', async () => {
- // create raw-file.txt with:
+ // 创建 raw-file.txt,内容如下:
// > crazy long
await expect('crazy long string oh my gerd').toMatchTrimmedFileSnapshot('./raw-file.txt')
})
@@ -544,7 +544,7 @@ Vitest 提供了与 [Jest](https://jestjs.io/docs/snapshot-testing) 几乎兼容
### 2. `printBasicPrototype` 默认为 `false` {#_2-printbasicprototype-is-default-to-false}
-Jest 和 Vitest的快照功能均基于 `pretty-format` 实现,但 Vitest 在 [`@vitest/pretty-format`](https://npmx.dev/package/@vitest/pretty-format) 基础上应用了自定义的快照默认配置。具体而言,Vitest将 `printBasicPrototype` 设为 `false` 以生成更简洁的快照输出,而 Jest 29.0.0 以下版本默认将该值设为 `true`。
+Jest 和 Vitest 的快照功能均基于 `pretty-format` 实现,但 Vitest 在 [`@vitest/pretty-format`](https://npmx.dev/package/@vitest/pretty-format) 基础上应用了自定义的快照默认配置。具体而言,Vitest 将 `printBasicPrototype` 设为 `false` 以生成更简洁的快照输出,而 Jest 29.0.0 以下版本默认将该值设为 `true`。
```ts
import { expect, test } from 'vitest'