Skip to content

Commit 93d506c

Browse files
hi-ogawacodex
andauthored
docs: document how to workaround bad packages that fail to load as external on node (#10243)
Co-authored-by: Codex <noreply@openai.com>
1 parent b2af5d5 commit 93d506c

1 file changed

Lines changed: 52 additions & 0 deletions

File tree

guide/common-errors.md

Lines changed: 52 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -165,3 +165,55 @@ test('rejects for missing user', async () => {
165165
await expect(fetchUser(123)).rejects.toThrow('User 123 not found')
166166
})
167167
```
168+
169+
## Package fails to load in Vitest but works in your app
170+
171+
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.
172+
173+
Common examples include packages that:
174+
175+
- ship ESM syntax in `.js` files without `"type": "module"`
176+
- use extensionless relative imports in ESM files
177+
- have incorrect `exports`, `imports`, `main`, or `module` entries
178+
- mix CommonJS and ESM entry points in a way that only works after bundling
179+
- import CSS or other non-JavaScript files that are expected to be handled by a bundler
180+
181+
You might see errors such as:
182+
183+
- `Cannot find module './relative-path' imported from ...`
184+
- `Unexpected token 'export'`
185+
- `Cannot use import statement outside a module`
186+
- `Module ... seems to be an ES Module but shipped in a CommonJS package.`
187+
- `Unknown file extension ".css"`
188+
189+
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.
190+
191+
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:
192+
193+
```ts [vitest.config.js]
194+
import { defineConfig } from 'vitest/config'
195+
196+
export default defineConfig({
197+
test: {
198+
server: {
199+
deps: {
200+
inline: ['wrapper-package', 'broken-package'],
201+
},
202+
},
203+
},
204+
})
205+
```
206+
207+
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:
208+
209+
```ts [vitest.config.js]
210+
import { defineConfig } from 'vitest/config'
211+
212+
export default defineConfig({
213+
ssr: {
214+
resolve: {
215+
noExternal: ['wrapper-package', 'broken-package'],
216+
},
217+
},
218+
})
219+
```

0 commit comments

Comments
 (0)