fix(vitest-plugin): stop importing the deprecated vitest subpaths

[adriencaccia]

Stacked on #74.

Vitest 4.1 moved the benchmark runner and the suite helpers to the main vitest entry point and deprecated the vitest/runners and vitest/suite subpaths, which now print a warning on every import — twice per worker, on every bench run.

A new compat module reads BenchmarkRunner and the TestRunner statics from the main entry when they are there, and falls back to the subpaths otherwise, so vitest 3.2 and 4.0 keep working as the peer dependency range advertises. Resolution needs a top-level await because the runner is used as a base class, so the two runner bundles are built for es2022; jsPlugins takes an optional target and keeps es2020 everywhere else.

Verified on Node 24.19.0:

• pnpm turbo run lint typecheck test green (29/29), zero deprecation warnings
• plugin benches clean in all four runner modes (disabled, walltime, simulation, memory), each confirmed to do real work
• build output byte-identical to the base branch except dist/analysis.mjs and dist/walltime.mjs, so the jsPlugins change is behaviour-neutral for every other entry point and package
• fallback path exercised: vitest 3.2.4 (examples/with-vitest-v3) and 4.0.18 (examples/with-typescript-esm) pass in disabled, walltime and simulation modes
• packed the plugin into standalone projects and ran all three modes with zero warnings: vitest 4.1.11 + vite 8.2.2, vitest 4.1.11 + vite 7.3.6, and vitest 3.2.7 + vite 7.3.6 (the fallback branch), each typechecking against the published .d.ts

[codspeed-hq]

Merging this PR will degrade performance by 10.31%

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 15 improved benchmarks
❌ 10 regressed benchmarks
✅ 213 untouched benchmarks

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	test_recursive_fibo_10	274.3 µs	11,690.2 µs	-97.65%
❌	Simulation	test_recursive_fibo_10	277.2 µs	725 µs	-61.77%
❌	WallTime	test sync baz 10	96 ns	120 ns	-20%
❌	Memory	two	2.1 KB	2.6 KB	-19.76%
❌	Simulation	short body	164.1 µs	198.2 µs	-17.23%
❌	Memory	short body	656 B	784 B	-16.33%
❌	WallTime	test_recursive_cached_fibo_10	2 µs	2.3 µs	-15.98%
❌	Simulation	short body	167.5 µs	198.2 µs	-15.49%
❌	Memory	one	2.2 KB	2.6 KB	-14.97%
❌	WallTime	switch 2	84 ns	96 ns	-12.5%
⚡	Simulation	switch 1	534.3 µs	203.2 µs	×2.6
⚡	Memory	recursive fibo 15 with hooks	656 B	432 B	+51.85%
⚡	WallTime	test sync baz 10	120 ns	96 ns	+25%
⚡	WallTime	test_iterative_fibo_10	120 ns	96 ns	+25%
⚡	Memory	end	2.6 KB	2.1 KB	+24.63%
⚡	Memory	short body	784 B	656 B	+19.51%
⚡	Memory	short body	784 B	656 B	+19.51%
⚡	WallTime	fibo darwin	11.9 ms	10 ms	+18.61%
⚡	WallTime	switch 1	84 ns	72 ns	+16.67%
⚡	WallTime	short body	2.2 µs	1.9 µs	+15.92%
...	...	...	...	...	...

ℹ️ Only the first 20 benchmarks are displayed. Go to the app to view all benchmarks.

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing feat/bump-vitest-4.1 (87ca2bf) with feat/vite-8-support (facdae6)}

[greptile-apps]

Greptile Summary

The PR introduces a Vitest compatibility layer that uses the non-deprecated Vitest 4.1 main-entry APIs while retaining fallback imports for Vitest 3.2 and 4.0.

• Routes benchmark runners and suite helpers through the new compatibility module.
• Enables ES2022 output only for runner bundles requiring top-level await.
• Makes the shared JavaScript build target configurable while retaining ES2020 elsewhere.
• Updates the instrumented-runner test to mock the compatibility boundary.

Confidence Score: 5/5

The PR appears safe to merge, with no concrete correctness, compatibility, or security failures identified.

The compatibility selection preserves the advertised Vitest fallback path, and the ES2022 target is limited to ESM runner bundles that require top-level await under the repository’s Node 22-or-newer runtime contract.

Important Files Changed

Filename	Overview
packages/vitest-plugin/src/compat.ts	Adds an asynchronous compatibility boundary selecting Vitest 4.1 main-entry APIs or supported legacy subpath exports.
packages/vitest-plugin/rollup.config.mjs	Targets ES2022 only for the analysis and wall-time ESM bundles that contain top-level await.
rollup.options.mjs	Adds an optional esbuild target while preserving ES2020 as the default for existing callers.
packages/vitest-plugin/src/analysis.ts	Redirects the benchmark runner and benchmark-function helper imports through the compatibility module without changing execution behavior.
packages/vitest-plugin/src/walltime/index.ts	Redirects the wall-time runner base class through the compatibility module.
packages/vitest-plugin/src/walltime/utils.ts	Retrieves benchmark options through the normalized compatibility API.
packages/vitest-plugin/src/common.ts	Retrieves suite hooks through the normalized compatibility API.
packages/vitest-plugin/src/tests/instrumented.test.ts	Updates the benchmark helper mock to target the new compatibility boundary.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Load Vitest compatibility module] --> B{Main entry exposes BenchmarkRunner and TestRunner?}
  B -->|Yes| C[Use BenchmarkRunner and TestRunner statics]
  B -->|No| D[Import vitest/runners and vitest/suite]
  C --> E[Export normalized runner and helper APIs]
  D --> E
  E --> F[Analysis runner]
  E --> G[Wall-time runner]

Loading

_{Reviews (1): Last reviewed commit: "fix(vitest-plugin): stop importing the d..." | Re-trigger Greptile}