--project filter is applied after inline workspace project initialization

[edison1105]

Describe the bug

vp test --project is expected to run only the matching workspace project, but inline workspace projects are still initialized before the project filter is applied.

Reproduction

https://github.com/edison1105/vite-plus-project-filter-repro

Steps to reproduce

clone https://github.com/edison1105/vite-plus-project-filter-repro

Install

vp install

Repro

vp test --project unit

Expected

Only the unit project is initialized, and unit.spec.ts passes.

Actual

vite-plus still initializes the filtered-out broken project, loads broken.config.ts, and throws before the unit project can run.

Additional

While working on vuejs/core#14618, I found that vp test --project does not filter inline workspace projects early enough. Filtered-out inline projects are still initialized before the project filter is applied.

System Info

Environment:
  Version       24.14.0
  Source        .node-version
  Source Path   /Users/edison/Desktop/Learning/demos/.node-version
  Project Root  /Users/edison/Desktop/Learning/demos

Tool Paths:
  node  /Users/edison/.vite-plus/js_runtime/node/24.14.0/bin/node
  npm   /Users/edison/.vite-plus/js_runtime/node/24.14.0/bin/npm
  npx   /Users/edison/.vite-plus/js_runtime/node/24.14.0/bin/npx

Used Package Manager

pnpm

Logs

Validations

• Read the Contributing Guidelines.
• Check that there isn't already an issue for the same bug.
• Confirm this is a Vite+ issue and not an upstream issue (Vite, Vitest, tsdown, Rolldown, or Oxc).
• The provided reproduction is a minimal reproducible example.

[fengmk2]

@edison1105 I'll take a look soon. There happens to be a new version release today, so let's see if we can catch this timing.

[claude]

Analysis

Summary: When using vp test --project <name> with a Vitest workspace that contains inline project configs (objects in the array), the bundled Vitest initializes all projects before applying the --project filter. If any filtered-out project has a broken config, it throws before the target project can run.

---

Relevant code

vite-plus bundles and patches Vitest from vitest@4.1.1 (aliased as vitest-dev in devDependencies). The bundled output lives in packages/test/dist/ (generated at build time). Post-processing patches are applied in packages/test/build.ts.

The workspace initialization lives in dist/chunks/cli-api.*.js. The current patches applied in build.ts are:

• patchVitestCoreResolver() – resolves vite-plus/test imports
• patchServerDepsInline() – auto-inlines packages that use expect.extend() (@testing-library/jest-dom/vitest setup fails with "Invalid Chai property: toBeInTheDocument" #897)
• patchMockerHoistedModule() – recognizes @voidzero-dev packages in mocker

None of these patches touch the workspace project initialization / filtering order.

---

Root cause

In Vitest's workspace loading flow, inline project definitions (plain objects rather than file paths) are passed directly to project initialization. The --project filter (ctx.config.project) is applied after all projects are created and initialized — so broken inline projects throw during initialization before the filter can exclude them.

This appears to be a known upstream Vitest issue. It may already be fixed in a Vitest version newer than 4.1.1 (the version currently bundled).

---

Is it fixable? Yes

Two approaches:

Option A – Upgrade bundled Vitest (preferred if upstream already fixed it)

Check if the issue has been resolved in a newer Vitest release (≥ 4.1.2 or 4.2.x). If so, bumping vitest-dev: npm:vitest@^4.x.x in packages/test/package.json and rebuilding would be sufficient.

Option B – Add a patch in packages/test/build.ts

If the fix isn't upstream yet, add a new patchWorkspaceProjectFilter() function to build.ts that patches dist/chunks/cli-api.*.js to apply the --project filter before inline project initialization. The patch would:

1. Find the workspace project initialization loop in the dist bundle (roughly where Vitest iterates over workspace entries and calls createWorkspaceProject() / project.setup() for each entry).
2. Wrap the initialization of each inline project in a check: if a project name can be resolved from the inline config before full initialization, skip it if it doesn't match --project filters.

For inline projects defined as objects { name: 'broken', ... }, the name property is available without any initialization, so the filter can be applied early.

---

Suggested implementation plan

1. Check upstream Vitest: Look at the Vitest changelog/PRs for any fix to --project filter + inline workspace project initialization. If fixed, go to step 3.

2. Write a patchWorkspaceProjectFilter() function in packages/test/build.ts:

   • Target file: dist/chunks/cli-api.*.js
   • Find the loop that processes workspace project entries
   • For inline project entries (objects with a name field), add an early-exit guard: check if the name matches the --project filter pattern before calling the initialization function
   • Add a throw new Error(...) guard to detect when the code pattern has changed after a Vitest upgrade

3. Add a snap test reproducing the issue: a workspace with two inline projects where one has a broken config, verify vp test --project working-project succeeds.

4. Call the new patch from the main build sequence in build.ts (after step 9 alongside the other patches).

---

Concerns

• The exact code pattern to patch in the dist bundle can only be confirmed by running pnpm install in packages/test/ and inspecting the generated dist/chunks/cli-api.*.js — the patch string must match exactly.
• If the fix lands upstream in Vitest 4.x, Option A is cleaner and avoids a fragile string-based patch.
• If patching inline project initialization, care must be taken not to break cases where inline project names use glob patterns (e.g. --project=packages*).

[fengmk2]

@edison1105 https://github.com/why-reproductions-are-required/vite-plus-project-filter-repro/blob/fix-vitest/package.json I see the same error after switching to Vitest as well, so it likely needs to be fixed on the Vitest side.
cc @sheremet-va

[sheremet-va]

This is expected behavior. The name can be set or overridden in the config. We also run the config hook in all plugins, see vitest-dev/vitest#9849

This also aligns with how projects: ['./path-to-config.js'] would work.