nx
nx copied to clipboard
vitest CLI (and other vitest tools) do not work properly for monorepos
Current Behavior
The vitest CLI (e.g. npx vitest) does not work correctly for monorepos. The workspace configuration file is missing from automated file generation.
In contrast, for jest, a jest.config.ts file is generated in the project root that correctly configures jest. For example:
root/jest.config.ts
import { getJestProjects } from '@nx/jest';
export default {
projects: getJestProjects(),
};
A similar file for vitest is required but is missing. For example:
vitest.workspace.ts
import { getVitestProjects } from '@nx/vite';
export default [
...getVitestProjects()
];
Expected Behavior
The vitest CLI and other tools that support vitest should work with default project configuration.
GitHub Repo
not applicable
Steps to Reproduce
- See details of current behavior
Nx Report
not applicable
Failure Logs
not applicable
Operating System
- [X] macOS
- [ ] Linux
- [ ] Windows
- [ ] Other (Please specify)
Additional Information
No response
Any workaround?
You can add a vitest.workspace.ts file in the project root and add a glob for the specific projects you want. i.e. if using the default nx vite.config.ts then this is all you need
export default ['**/*/vite.config.ts'];
then you can do npx vitest without the need of prefixing with --root
you will need a minimum version of vitest v0.30.0 and would be best to add a 'name' property in the vite test configuration.
We'll look at adding this to the generated setup down the road, there are a handful of things that have to be considered for generating this setup + the migration needed for existing workspaces.
Thanks @barbados-clemens for the hint. One issue I stumbled was this error:
Error: Project name "channels" is not unique. All projects in a workspace should have unique names..
I fixed it by adding name in vite.config.json:
test: {
name: 'web-ui-components-channels',
globals: true,
cache: {
dir: '../../../../node_modules/.vitest',
},
environment: 'jsdom',
include: ['src/**/*.{test,spec}.{js,mjs,cjs,ts,mts,cts,jsx,tsx}'],
coverage: {
provider: 'v8',
},
},
Perhaps name could be set already in vitest generator.
@diginikkari Ah good point, yes all names will have to be unique just like jest. Nx will set that when support for it lands and I'll have a migration to add all those values to existing configs if not already present. I'll try to work on it in the coming weeks.
Is there any plans to support that? It was very easy to have shared setup (eg beforeAll) for jest which is missing with vitest
Any progress on providing support for vitest workspace in nx monorepos?
Yes, we will work on it in January
I'd also like to call out how annoying it is that when you run the test commands, it should stick around in watch mode for changes and reload. But NX just reports and the target being ran successfully and kills it.
If you try to run the same test command with --ui it will open up the browser but looses connection because NX has terminated the task again. 😢
Ah! Just as I post this I found that setting "watch": true in the project json fro the @nx/vite:test options seems to keep it open. 🤦♀️
Why is this config not the default though? If I do put this watch target configuration I can selectively run watch mode:
With this I can run both nx test project and nx run project:test which as expected it runs once, but also nx test project --watch , nx run project:test:watch and nx run project:test --watch work as expected and keep watch ON.
Edit:
Wooow, nice so with this config target setup nx test project --watch --ui works ok and shows in browser properly 😄
This should already work in Nx if you add a vitest.workspace.ts file at the root of your Nx workspace, as described here: https://github.com/nrwl/nx/issues/18204#issuecomment-1652003698 by @barbados-clemens
Here's a repository you can use as reference, which has both jest and vitest projects. Running npx vitest at the root will run the vitest tests:
https://github.com/mandarini/vitest-workspace-nx
I will add this to our generator, it seems like a useful addition.
Thank you everyone.
This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.