You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
await button.click() // Interactive methods work fine ✅
187
+
await expect.element(button).toBeVisible() // Querying elements does not work ❌
188
+
```
189
+
190
+
Ifyouneedtoworkwithcross-originiframes, 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'savailable.
`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.
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
+
exportdefaultdefineConfig({
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' })
awaitexpect(fetchUser(123)).rejects.toThrow('User 123 not found')
168
168
})
169
169
```
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
+
exportdefaultdefineConfig({
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:
0 commit comments