Skip to content
Merged
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
57 changes: 57 additions & 0 deletions docs/guide/common-errors.md
Original file line number Diff line number Diff line change
Expand Up @@ -64,6 +64,63 @@ vitest --pool=forks
```
:::

## Subpath imports with custom conditions are not resolved
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@copilot This is not only for sub path imports but any package condition in general. See #8764. Rewrite section with the framing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rewritten in b21497b - changed section title to "Custom package conditions are not resolved" and expanded examples to include both package exports and subpath imports, addressing issue #8764.


If you are using [Node.js subpath imports](https://nodejs.org/api/packages.html#subpath-imports) with custom conditions in your `package.json`, you may find that Vitest does not respect these conditions by default.

For example, if you have the following in your `package.json`:

```json
{
"imports": {
"#my-lib": {
"custom": "./lib/custom_lib.js",
"import": "./lib/node_lib.js"
}
}
}
```

By default, Vitest will only use the `import` and `default` conditions. To make Vitest respect custom conditions, you need to configure [`ssr.resolve.conditions`](https://vite.dev/config/ssr-options#ssr-resolve-conditions) in your Vitest config:

```ts [vitest.config.js]
import { defineConfig } from 'vitest/config'

export default defineConfig({
ssr: {
resolve: {
conditions: ['custom', 'import', 'default'],
},
},
})
```

::: tip Why `ssr.resolve.conditions` and not `resolve.conditions`?
Vitest inherits Vite's configuration convention where:
- `resolve.conditions` is used for client-side application code (browser environments)
- `ssr.resolve.conditions` is used for server-side application code (Node.js environments)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is incorrect, transform mode is based on the environment (jsdom/happy-dom use resolve.conditions), custom environments can define transformMode property

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in b21497b - clarified that transform mode is based on the environment (jsdom/happy-dom use resolve.conditions, node uses ssr.resolve.conditions), and custom environments can define transformMode property.


Since Vitest runs tests in a Node.js environment (unless using browser mode), it uses `ssr.resolve.conditions` for module resolution. This applies to both package exports and subpath imports.

For more information, see [Vite's SSR documentation](https://vite.dev/guide/ssr#ssr-externals).
:::

If you need to conditionally set conditions based on the runtime environment:

```ts [vitest.config.js]
import { defineConfig } from 'vitest/config'

const isRunningOnBun = 'bun' in process.versions

export default defineConfig({
ssr: {
resolve: {
conditions: isRunningOnBun ? ['bun', 'import', 'default'] : ['import', 'default'],
},
},
})
```

## Segfaults and native code errors

Running [native NodeJS modules](https://nodejs.org/api/addons.html) in `pool: 'threads'` can run into cryptic errors coming from the native code.
Expand Down