Skip to content

Commit 3530b69

Browse files
authored
Merge pull request #972 from vitest-dev/sync-1a64d60c-1
docs(en): merge docs-cn/sync-docs into docs-cn/dev @ 1a64d60
2 parents 4393761 + f0f99d3 commit 3530b69

7 files changed

Lines changed: 127 additions & 8 deletions

File tree

api/browser/assertions.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -52,9 +52,9 @@ interface ExpectPollOptions {
5252
message?: string
5353
}
5454
```
55-
55+
<!-- TODO: translation -->
5656
::: tip
57-
`expect.element` `expect.poll(() => element)`的简写,工作方式完全相同。
57+
Like [`expect.poll`](/api/expect#poll), `expect.element` retries DOM assertions until they pass or the timeout is reached. When it receives a locator, Vitest resolves it with [`locator.findElement()`](/api/browser/locators#findelement) before running the DOM assertion. The `timeout` option applies to the whole retry operation. The `interval` option controls how often failed DOM assertions are retried, but locator resolution uses `findElement`'s own increasing retry intervals.
5858

5959
`toHaveTextContent` 以及其他所有断言在常规的 `expect` 中仍然可用,但没有内置的重试机制:
6060

api/browser/context.md

Lines changed: 15 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -175,9 +175,23 @@ const frame = page.frameLocator(
175175
await frame.getByText('Hello World').click() // ✅
176176
await frame.click() // ❌ 不可用
177177
```
178+
<!-- TODO: translation -->
179+
::: danger IMPORTANT
180+
By default `frameLocator` does not support querying elements with `expect.element()` in cross-origin iframes. Interactive methods, such as `.click()` work fine. This is different behaviour than Playwright.
181+
182+
```ts
183+
const frame = page.frameLocator(page.getByTestId('cross-origin-iframe'))
184+
const button = frame.getByRole('button', { name: 'Submit' })
185+
186+
await button.click() // Interactive methods work fine ✅
187+
await expect.element(button).toBeVisible() // Querying elements does not work ❌
188+
```
189+
190+
If you need to work with cross-origin iframes, you'll need to pass `args: ["--disable-web-security"]` in [`launchOptions`](/config/browser/playwright.html#launchoptions). Or alternatively create a custom [browser command](/api/browser/commands.html#custom-commands) that accesses the iframe on server side where it's available.
191+
:::
178192

179193
::: danger IMPORTANT
180-
目前,`frameLocator` 方法仅支持 `playwright` 提供者。
194+
At the moment, the `frameLocator` method is only supported by the `playwright` provider.
181195

182196
交互方法(如 `click``fill`)在 iframe 内的元素上始终可用,但使用 `expect.element` 进行断言时要求 iframe 具有[同源策略](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy)。
183197
:::

api/expect.md

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -105,11 +105,13 @@ test('expect.soft test', () => {
105105

106106
```ts
107107
interface ExpectPoll extends ExpectStatic {
108-
(actual: () => T, options?: { interval?: number; timeout?: number; message?: string }): Promise<Assertions<T>>
108+
(actual: (options: { signal: AbortSignal }) => T, options?: { interval?: number; timeout?: number; message?: string }): Promise<Assertions<Awaited<T>>>
109109
}
110110
```
111+
<!-- TODO: translation -->
112+
`expect.poll` reruns the _assertion_ until it is succeeded. You can configure how often Vitest retries and how long it waits by setting `interval` and `timeout` options. The `timeout` applies to the whole polling operation, including pending callback and async matcher execution.
111113

112-
`expect.poll` 重新运行断言,直到成功为止。你可以通过设置 `interval``timeout` 选项来配置 Vitest 应重新运行 `expect.poll` 回调的次数。
114+
The callback receives an `AbortSignal` that is aborted when the poll timeout is reached.
113115

114116
如果在 `expect.poll` 回调中抛出错误,Vitest 将重试直到超时为止。
115117

api/mock.md

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -702,7 +702,9 @@ MyClass.mock.instances[0] === a
702702
若构造函数显式返回值,该值不会存入 `instances`,而会出现在 `results` 中:
703703

704704
```js
705-
const Spy = vi.fn(() => ({ method: vi.fn() }))
705+
const Spy = vi.fn(function () {
706+
return { method: vi.fn() }
707+
})
706708
const a = new Spy()
707709
708710
Spy.mock.instances[0] !== a

config/browser/locators.md

Lines changed: 49 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -27,3 +27,52 @@ outline: deep
2727
const locator = page.getByText('Hello, World', { exact: true })
2828
await locator.click()
2929
```
30+
<!-- TODO: translation -->
31+
## browser.locators.errorFormat <Version>5.0.0</Version> {#browser-locators-errorformat}
32+
33+
- **Type:** `'html' | 'aria' | 'all'`
34+
- **Default:** `'all'`
35+
36+
Controls what Vitest prints when a locator cannot find an element. Vitest prints information for the DOM subtree where the locator search ran, or `document.body` for page-level locators.
37+
38+
- `'html'` prints that DOM subtree as HTML using [`utils.prettyDOM`](/api/browser/context#prettydom).
39+
- `'aria'` prints that DOM subtree as an [ARIA snapshot](/guide/browser/aria-snapshots), which focuses on accessible roles, names, and state.
40+
- `'all'` prints the ARIA snapshot first, followed by the HTML output.
41+
42+
```ts
43+
import { defineConfig } from 'vitest/config'
44+
45+
export default defineConfig({
46+
test: {
47+
browser: {
48+
enabled: true,
49+
locators: {
50+
errorFormat: 'aria',
51+
},
52+
},
53+
},
54+
})
55+
```
56+
57+
For example, `all` displays a following error:
58+
59+
```html
60+
VitestBrowserElementError: Cannot find element with locator: getByRole('button', { name: 'Save' })
61+
62+
ARIA tree:
63+
- main:
64+
- heading "Settings" [level=1]
65+
- button "Cancel"
66+
67+
HTML:
68+
<body>
69+
<main>
70+
<h1>
71+
Settings
72+
</h1>
73+
<button>
74+
Cancel
75+
</button>
76+
</main>
77+
</body>
78+
```

guide/common-errors.md

Lines changed: 52 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -167,3 +167,55 @@ test('rejects for missing user', async () => {
167167
await expect(fetchUser(123)).rejects.toThrow('User 123 not found')
168168
})
169169
```
170+
<!-- TODO: translation -->
171+
## Package fails to load in Vitest but works in your app
172+
173+
Some packages work in an app build but fail in Vitest because they are only valid after a bundler has rewritten or resolved them. When Vitest externalizes a dependency, Node.js loads it directly, so Node's ESM and package rules apply. See Node.js documentation on [ECMAScript modules](https://nodejs.org/docs/latest/api/esm.html) and [packages](https://nodejs.org/docs/latest/api/packages.html) for the precise rules.
174+
175+
Common examples include packages that:
176+
177+
- ship ESM syntax in `.js` files without `"type": "module"`
178+
- use extensionless relative imports in ESM files
179+
- have incorrect `exports`, `imports`, `main`, or `module` entries
180+
- mix CommonJS and ESM entry points in a way that only works after bundling
181+
- import CSS or other non-JavaScript files that are expected to be handled by a bundler
182+
183+
You might see errors such as:
184+
185+
- `Cannot find module './relative-path' imported from ...`
186+
- `Unexpected token 'export'`
187+
- `Cannot use import statement outside a module`
188+
- `Module ... seems to be an ES Module but shipped in a CommonJS package.`
189+
- `Unknown file extension ".css"`
190+
191+
When possible, fix the package so Node.js can load it directly: add `"type": "module"` for ESM `.js` files, use `.mjs`, include explicit file extensions in ESM imports, and make sure `exports` points to files Node.js can load.
192+
193+
If you cannot fix the package itself, inline it so Vite handles it instead of passing it to Node.js as an external dependency. Inline the whole dependency chain that leads to the invalid package. If your source imports `wrapper-package`, and `wrapper-package` imports `broken-package`, inline both packages:
194+
195+
```ts [vitest.config.js]
196+
import { defineConfig } from 'vitest/config'
197+
198+
export default defineConfig({
199+
test: {
200+
server: {
201+
deps: {
202+
inline: ['wrapper-package', 'broken-package'],
203+
},
204+
},
205+
},
206+
})
207+
```
208+
209+
You can also use Vite's [`ssr.resolve.noExternal`](https://vite.dev/config/ssr-options#ssr-resolve-noexternal) for the same purpose. Vitest merges `ssr.resolve.noExternal` into [`server.deps.inline`](/config/server#server-deps-inline), so this is useful when the dependency also needs to be bundled by Vite in SSR builds:
210+
211+
```ts [vitest.config.js]
212+
import { defineConfig } from 'vitest/config'
213+
214+
export default defineConfig({
215+
ssr: {
216+
resolve: {
217+
noExternal: ['wrapper-package', 'broken-package'],
218+
},
219+
},
220+
})
221+
```

guide/index.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -41,8 +41,8 @@ bun add -D vitest
4141

4242
:::
4343

44-
:::tip 提示
45-
Vitest 需要 Vite >=v6.0.0 和 Node >=v20.0.0
44+
:::tip
45+
Vitest 需要 Vite >=v6.4.0 and 和 >=v22.12.0
4646
:::
4747

4848
如果在 `package.json` 中安装一份 `vitest` 的副本,可以使用上面列出的方法之一。然而,如果更倾向于直接运行 `vitest` ,可以使用 `npx vitest``npx` 会随着 npm 和 Node.js 一起被安装)。

0 commit comments

Comments
 (0)