rules_vitest configures Vitest to work optimally with Bazel and rules_js. Custom configuration may conflict with the default rules_vitest configurations and care should be taken when configuring Vitest.
vite, vitest, react (optional), jsdom (optional) must be installed at root
We have not figured out why yet, but it seems to be an issue with ESM imports under Bazel
Similar to pnpm, rules_js uses a virtual store for npm packages. This can cause issues with Vitest and may require package hoisting similar to pnpm. See the pnpm public hoist pattern documentation for details and rules_js public_hoist_packages for configuring rules_js package hoisting.
Vitest is designed to run as a standalone long running application, often having a slow startup time then running incrementally using caching for performance. This conflicts with Bazel which designed for short-lived processes that can be run in parallel and cached.
Common performance issues include:
Vitest runs tests concurrently using workers. This conflicts with Bazel which also runs tests and actions in parallel. Vitest concurrency will be configured by rules_vitest to work optimally with Bazel actions and Bazel test sharding.
When ESM modules are transpiled to CommonJS different transpilers may produce different variants of CommonJS.
For example SWC (normally used in bazel with rules_swc) transpiles ESM imports to align with ESM standards as closely as possible at runtime, even when transpiled to CommonJS. This leads to the same Module mocking with ESM issue as native ESM modules.
See the SWC test for examples and more information.
Other transpilers such as babel or tsc may have similar issues or configuration to workaround such issues.