feat(config): support parallel test projects setup

[yamachi4416]

🔗 Linked issue

resolves #1307
resolves #1583

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

• avoided concurrent nuxt starts to prevent configuration retrieval failures
• repurposed examples/app-vitest-workspace for workspace tests, as the advised setup is covered in examples/app-vitest

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@nuxt/test-utils@1585

commit: f002d54

[coderabbitai]

Warning

Rate limit exceeded

@yamachi4416 has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 9 minutes and 51 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📝 Walkthrough

Walkthrough

This pull request reorganizes the app-vitest-workspace example from a single monolithic setup into a multi-app workspace with app1 and app2, each with separate Vitest configurations. The root vitest.config.ts is updated to auto-discover per-app config files using a glob pattern. Additionally, a concurrency-safe wrapper with a lock mechanism is introduced in src/config.ts around startNuxtAndGetViteConfig to serialize calls and prevent race conditions during Vite config initialization. Package dependencies and scripts are updated to support preparing both apps independently.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

🚥 Pre-merge checks | ✅ 6

✅ Passed checks (6 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'feat(config): support parallel test projects setup' accurately summarizes the main change, which adds concurrency-safe serialization to support parallel test project configurations.
Linked Issues check	✅ Passed	The PR successfully addresses the core requirement from issue #1583 by introducing a concurrency-safe wrapper (startNuxtAndGetViteConfig) with a lock mechanism to serialize Nuxt starts and prevent intermittent '#imports' specifier errors. The example workspace refactoring supports testing parallel project setups as intended.
Out of Scope Changes check	✅ Passed	All changes are within scope: the lock mechanism addresses the race condition root cause, workspace reorganization enables testing parallel setups, and package.json updates support the workspace structure.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Merge Conflict Detection	✅ Passed	✅ No merge conflicts detected when merging into main
Description check	✅ Passed	The PR description relates to the changeset by explaining the purpose of adding concurrency protection to Nuxt configuration retrieval and reorganizing examples for workspace testing.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[danielroe]

ideally Nuxt's default asyncContext should mean this isn't necessary:

nuxt/nuxt#30510

I wonder what's going wrong, that this isn't working?

[yamachi4416]

thank you for the review
agreed, investigation will follow to find why

[yamachi4416]

loadNuxt and buildNuxt run successfully in parallel.
however, when modules use different versions of @nuxt/kit, asyncContext appears to be undefined in those using the secondary version, causing a fallback to nuxtCtx and resulting in a reference to an incorrect Nuxt instance.