test: use vitest workspaces #32121
test: use vitest workspaces #32121
Conversation
|
|
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
There was a problem hiding this comment.
Pull Request Overview
This PR refactors the Vitest configuration to adopt workspaces using the new nuxt/test-utils v3.19, simplifying test setup.
- Removed the standalone nuxt config file (vitest.nuxt.config.ts) since nuxt tests are now managed via a workspace in vitest.config.ts
- Added workspace definitions for "fixtures", "unit", and "nuxt" projects in vitest.config.ts
- Updated package.json test commands to target specific workspace projects
Reviewed Changes
Copilot reviewed 3 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| vitest.nuxt.config.ts | Removed configuration as its functionality is merged into the workspace |
| vitest.config.ts | Added and updated workspace definitions for test projects |
| package.json | Adjusted test commands to support the new workspace-based configuration |
Files not reviewed (1)
- pnpm-lock.yaml: Language not supported
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
WalkthroughThe Vitest testing configuration was refactored from a single global setup to a multi-workspace structure within Note ⚡️ AI Code Reviews for VS Code, Cursor, WindsurfCodeRabbit now has a plugin for VS Code, Cursor and Windsurf. This brings AI code reviews directly in the code editor. Each commit is reviewed immediately, finding bugs before the PR is raised. Seamless context handoff to your AI code agent ensures that you can easily incorporate review feedback. Note ⚡️ Faster reviews with cachingCodeRabbit now supports caching for code and dependencies, helping speed up reviews. This means quicker feedback, reduced wait times, and a smoother review experience overall. Cached data is encrypted and stored securely. This feature will be automatically enabled for all accounts on May 16th. To opt out, configure 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (4)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
vitest.config.ts (2)
11-12: Duplicate or overly-broad coverage exclusion pattern
'**/test/'is already fully covered by Vitest’s defaultcoverageConfigDefaults.exclude(test,**/*.test.*, etc.). Keeping redundant globs makes the list harder to maintain and slightly slows glob-resolution on large workspaces.- exclude: [...coverageConfigDefaults.exclude, 'playground', '**/test/', 'scripts', 'vitest.nuxt.config.ts'], + exclude: [...coverageConfigDefaults.exclude, 'playground', 'scripts', 'vitest.nuxt.config.ts'],
24-33: Alias points to built artefacts – consider targeting source for faster iteration
'#app': resolve('./packages/nuxt/dist/app')aliases the built output.
During unit tests it is usually faster (and yields better stack traces) to alias to the TypeScript source (./packages/nuxt/src/app) and let esbuild transform it on-the-fly.If the dist path is intentional (e.g. to mimic production), add an inline comment explaining the choice to prevent accidental “optimisation”.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
package.jsonis excluded by!package.json,!**/package.jsonpnpm-lock.yamlis excluded by!**/pnpm-lock.yaml,!pnpm-lock.yaml
📒 Files selected for processing (2)
vitest.config.ts(1 hunks)vitest.nuxt.config.ts(0 hunks)
💤 Files with no reviewable changes (1)
- vitest.nuxt.config.ts
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: build
- GitHub Check: code
🔇 Additional comments (2)
vitest.config.ts (2)
15-22: Fixture workspace configuration looks solidTest patterns, timeout differentiation for Windows, and explicit exclusion of e2e paths are all sensible. 👍
43-70:✅ Verification successful
Top-level
awaitinside a plain object risks breaking older Node/Vitest runnersAlthough Node ≥ 20 and recent Vitest versions accept top-level
await, many CI images (and some editors’ TS servers) still pin older Node or use CommonJS transpilation for*.tsconfigs, leading to a syntax error.Wrap the config in an async factory to guarantee support:
-export default defineConfig({ +export default defineConfig(async () => ({ ... - await defineVitestProject({ + await defineVitestProject({ test: { name: 'nuxt', ... }, }), ... -}) +}))Ensure the CI matrix uses a Node version that supports top-level
await(≥ 14.8 when ESM, but ≥ 16 is safer) if you keep the current style.
Let’s verify the Node versions specified in our CI workflows to ensure top-level
awaitis safe:
🏁 Script executed:
#!/bin/bash set -e # Search for Node.js setup in GitHub Actions workflows rg -n "uses:.*actions/setup-node" -n .github/workflows || echo "No setup-node found in workflows" # Search for explicit node-version fields rg -n "node-version" -n .github/workflows || echo "No node-version fields found in workflows"Length of output: 2751
Let’s inspect the Node matrix in
.github/workflows/ci.ymlto see which versions are tested:
🏁 Script executed:
#!/bin/bash set -e # Show the matrix definition around line 290 sed -n '250,330p' .github/workflows/ci.ymlLength of output: 2628
Top-level await is safe with Node 20 in CI
Verified that all GitHub Actions workflows (lts/*and the explicitnode: [20]matrix) run on Node 20. Top-levelawaitinvitest.config.tsis fully supported—no async factory wrapper is needed.
@nuxt/kit
nuxt
@nuxt/schema
@nuxt/rspack-builder
@nuxt/vite-builder
@nuxt/webpack-builder
commit: |
CodSpeed Performance ReportMerging #32121 will not alter performanceComparing Summary
|
package.json
Outdated
| @@ -26,12 +26,12 @@ | |||
| "play:preview": "nuxi preview playground", | |||
| "test": "pnpm test:fixtures && pnpm test:fixtures:dev && pnpm test:fixtures:webpack && pnpm test:unit && pnpm test:runtime && pnpm test:types && pnpm typecheck", | |||
There was a problem hiding this comment.
I think it shoud be possible to combine at least test:runtime, test:unit, test:fixtures into a single vitest run (or vitest run --project fixtures --project unit --project nuxt) command. I think this can speedup the tests because vitest can decide the order :)
There was a problem hiding this comment.
This might also speed up ci here:
Lines 188 to 192 in 9c45060
There was a problem hiding this comment.
sadly vitest workspace extend is limited to configs, not other workspace projects. But I think we can even get the dev and webpack variants as separate projects (to put them into one command):
pseudo code:
const fixturesProject = {
test: {
// config here
},
}
export default defineConfig({
test: {
workspace: [
defu(fixturesProject, { test: {env: {name: 'fixtures'}),
defu(fixturesProject, { test: {env: {TEST_ENV: 'dev', name: 'fixtures:dev'})
],
},
})There was a problem hiding this comment.
there are a lot of variants and I'm not sure they we should add them all as separate projects
🔗 Linked issue
📚 Description
using new nuxt/test-utils v3.19, we can now adopt vitest workspaces for simpler configuration