defineConfig always injects vite-plus:vitest-resolver into vp build / vp dev even when Vitest isn't used

[cursor]

Describe the bug

defineConfig from vite-plus always prepends Vitest-only plugins into every Vite config, including for vp build / vp dev:

• vite-plus:vitest-resolver
• vite-plus:auto-inline-matcher
• vite-plus:coverage-version-guard

Projects that use Vite+ for toolchain (fmt / lint / build) but run tests with another runner (e.g. Bun's bun:test) still pay for these plugins on every production build.

Rolldown/Vite plugin timings report:

[PLUGIN_TIMINGS] Your build spent significant time in plugins. Here is a breakdown:
  - vite-plus:vitest-resolver (87%)

The resolver is an enforce: "pre" resolveId hook, so it runs on every module resolve. It early-returns for non-vitest / @vitest/* ids, but with a large graph that still dominates plugin time.

There is no documented opt-out. lazyPlugins only gates user plugins during config-metadata loads; it does not skip these injected plugins on build/dev. vite-plus/prefer-vite-plus-imports also pushes app configs to import defineConfig from vite-plus rather than vite, so switching away isn't a clean escape hatch.

Reproduction

1. Use import { defineConfig } from "vite-plus" in an app vite.config.ts
2. Do not configure or run vp test / Vitest
3. Run vp build (with plugin timings enabled)
4. Observe vite-plus:vitest-resolver near the top of [PLUGIN_TIMINGS]

Expected

Vitest helper plugins should only be injected when running tests (vp test / Vitest), or there should be an explicit opt-out for projects that don't use Vitest.

System Info

• vite-plus: 0.2.5
• Tests: Bun (bun:test), not Vitest
• Apps build via vp build

Suggested fix

• Gate injection on test command / presence of test config, or
• Add a config flag such as test: false / vitest: false to skip injection, or
• Document a supported way to opt out without fighting prefer-vite-plus-imports

Related

• Implementation that introduced/patched the resolver: fix(test): patch vitest resolver #356
• Auto-inline matcher: fix(test): auto-inline packages that use expect.extend() to fix module instance splitting #1113
• lazyPlugins (user plugins only): feat: add lazyPlugins() helper for conditional plugin loading #1215

[SohelIslamImran]

Follow-up: PLUGIN_TIMINGS % is misleading (measurements)

We instrumented vite-plus:vitest-resolver during real vp build runs and A/B-stripped the injected vite-plus:* plugins. Absolute impact is much smaller than the warning suggests.

Instrumentation (resolveId)

App	resolveId calls	Vitest hits	JS time inside hook
portal	12,143	0	2.78 ms
web	15,973	0	3.53 ms

On build, the plugin only early-returns null — it never does useful Vitest resolution work.

A/B wall-clock (portal, warm)

Config	built in	Top PLUGIN_TIMINGS entry
with vitest-resolver	11.21–11.28s	vite-plus:vitest-resolver 87–90%
stripped vite-plus:* plugins	11.42–11.95s	@rolldown/plugin-babel ~81%

Stripping the plugins did not speed up the build (noise / slightly slower). It only changed who owns the pie chart.

Corrected framing

• Not a meaningful build bottleneck for us (~3ms JS work; wall-clock unchanged).
• The 87% figure is share of plugin time, inflated by many cheap async resolveId Rust↔JS calls next to a fast Rolldown core.
• The remaining issue is still valid as a design / DX request:
  • Vitest helper plugins are injected for every defineConfig consumer on vp build / vp dev
  • That produces a noisy [PLUGIN_TIMINGS] warning even when Vitest isn’t used (and even when it is used — build still doesn’t need these hooks)
  • Prefer gating injection to vp test / Vitest, or documenting an opt-out

Sorry for the initial overstatement of perf impact — happy to close if you consider the warning acceptable, but gating/opt-out would still remove false alarms for Bun/bun:test-only (and Vitest) users.

[fengmk2]

@SohelIslamImran Can you provide a minimal reproduction repository?