Repository navigation
defineConfig always injects vite-plus:vitest-resolver into vp build / vp dev even when Vitest isn't used #2307
Description
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-resolvervite-plus:auto-inline-matchervite-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
- Use
import { defineConfig } from "vite-plus"in an appvite.config.ts - Do not configure or run
vp test/ Vitest - Run
vp build(with plugin timings enabled) - Observe
vite-plus:vitest-resolvernear 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
testconfig, or - Add a config flag such as
test: false/vitest: falseto 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
Activity
SohelIslamImran commentedon Aug 3, 2026
Follow-up: PLUGIN_TIMINGS % is misleading (measurements)
We instrumented
vite-plus:vitest-resolverduring realvp buildruns and A/B-stripped the injectedvite-plus:*plugins. Absolute impact is much smaller than the warning suggests.Instrumentation (resolveId)
On build, the plugin only early-returns
null— it never does useful Vitest resolution work.A/B wall-clock (portal, warm)
built invite-plus:vitest-resolver87–90%vite-plus:*plugins@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
87%figure is share of plugin time, inflated by many cheap asyncresolveIdRust↔JS calls next to a fast Rolldown core.defineConfigconsumer onvp build/vp dev[PLUGIN_TIMINGS]warning even when Vitest isn’t used (and even when it is used — build still doesn’t need these hooks)vp test/ Vitest, or documenting an opt-outSorry 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 commentedon Aug 3, 2026
@SohelIslamImran Can you provide a minimal reproduction repository?
jasonkuhrt commentedon Nov 11, 2026
#3434 gives the resolver a
resolveIdhook filter, so its handler runs only forvitest,vitest/*,@vitest/*andvite-plus/testids. The plugin stays injected, so whether to inject it at all remains this issue's question.What it adds to the measurements above: the cost is the call into JavaScript, not the handler's body. The follow-up measured the body at 2.78 ms over 12,143 calls. On a generated graph that is all resolution, alternating the published 1.6.0
defineConfigand the filtered one, the build's median drops from 305 ms to 195 ms at 12,000resolveIdcalls, about 110 ms, and from 1,927 ms to 1,364 ms at 40,000. That is about 9 to 14 µs per skipped call on that graph, so one or two tenths of a second for the 12,000 to 16,000 calls measured above, which fits that A/B finding no clear difference. The script is in the PR.On v1.6.0
[PLUGIN_TIMINGS]no longer names the resolver: Rolldown 1.2.18 times each callback inside JavaScript and lists one only from one second (source), and the follow-up above measured it at 2.78 ms and 3.53 ms.