Repository navigation
Support vitest 5 - #86
GuillaumeLagrange wants to merge 7 commits into
Conversation
25ef927 to
e04f0da
Compare
Merging this PR will degrade performance by 17.78%
|
| Mode | Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|---|
| ❌ |
Simulation | switch 1 |
244.7 µs | 1,322.1 µs | -81.5% |
| ❌ |
Simulation | recursive fibo 10 |
299.8 µs | 1,373.9 µs | -78.18% |
| ❌ |
Simulation | test_recursive_fibo_10 |
288.5 µs | 723.7 µs | -60.13% |
| ❌ | Simulation | short body 2 |
104.2 µs | 155.2 µs | -32.89% |
| ❌ |
Simulation | switch 1 |
244.6 µs | 281.1 µs | -12.98% |
| ⚡ |
Simulation | recursive fibo 10 |
1,379.6 µs | 300.3 µs | ×4.6 |
| ⚡ | Simulation | recursive fibo 15 |
636.6 µs | 351 µs | +81.4% |
| ⚡ | Simulation | short body |
196.5 µs | 155.2 µs | +26.63% |
| ⚡ | Simulation | short body |
220.3 µs | 177 µs | +24.46% |
| ⚡ | WallTime | switch 2 |
96 ns | 84 ns | +14.29% |
| 🆕 | WallTime | iterative fibo 15 |
N/A | 624 ns | N/A |
| 🆕 | WallTime | iterative fibo 20 |
N/A | 648 ns | N/A |
| 🆕 | WallTime | recursive fibo 15 |
N/A | 20.4 µs | N/A |
| 🆕 | WallTime | recursive fibo 20 |
N/A | 219 µs | N/A |
| 🆕 | WallTime | iterative |
N/A | 588 ns | N/A |
| 🆕 | WallTime | recursive |
N/A | 20.2 µs | N/A |
| 🆕 | WallTime | iterative |
N/A | 600 ns | N/A |
| 🆕 | WallTime | recursive |
N/A | 219 µs | N/A |
| 🆕 | WallTime | fibo 10 |
N/A | 2.3 µs | N/A |
| 🆕 | WallTime | fibo 15 |
N/A | 20.3 µs | N/A |
| ... | ... | ... | ... | ... | ... |
ℹ️ 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 cod-2931-prepare-compatibility-with-vitest-5 (4cc5194) with main (f8564bb)
Footnotes
-
53 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩
f511dee to
c3a356b
Compare
|
eec7ec7 to
eb2042e
Compare
|
Hi @GuillaumeLagrange, what's the status of this PR? We would need it for Astro |
Hey! The support for the benchmark provider has been merged and released upstream by vitest, we plan to merge and release this PR early this week! Don't hesitate to continue pinging me to get updates, and sorry about the delay |
d6abe82 to
9007e6e
Compare
|
Hi @GuillaumeLagrange, what's the status of this PR? I would need it for various projects. Thanks! |
`getGitDir` only accepted a `.git` directory, but in a git worktree or a submodule `.git` is a file pointing at the real git dir. Every benchmark URI lookup then threw "Could not find a git repository", so running any plugin under CodSpeed from a worktree failed. Accept a `.git` entry of either kind. Inside a submodule, URIs are now relative to the submodule root instead of the parent repository, which matches `git rev-parse --show-toplevel`. Walk up the directories directly instead of going through `find-up`, which was only used here and is ESM-only, and drop the dependency. Co-Authored-By: Claude <noreply@anthropic.com>
The unit tests load `@codspeed/core` from its build, which bundles its dependencies, so `find-up` and its dependencies were never loaded from `node_modules`. Core no longer depends on them either. Only `stack-trace` still needs the ESM transform. Co-Authored-By: Claude <noreply@anthropic.com>
A plugin behaves differently depending on whether CodSpeed drives the run, and each mode takes a different path through the plugin, so all three have to be run when developing or reviewing one. Write down the commands and the expected output per mode, and ignore the local `.codspeed` result directory those runs produce. Co-Authored-By: Claude <noreply@anthropic.com>
9007e6e to
986310d
Compare
986310d to
4cc5194
Compare
Vitest 5 removed the dedicated `NodeBenchmarkRunner` and the `vitest/runners` / `vitest/suite` entrypoints. Benchmarks are now declared through a `bench` test-context fixture and executed by a `benchmark.provider`: a module Vitest hands the registered functions, their options and the declaring test, and whose results it treats as authoritative. Read the version of the running Vitest from `vitest/node`, which resolves through the `vitest` peer dependency, and select the integration behind a `VitestBackend` abstraction so the rest of the plugin never inspects the version: - v3/4 keep the custom benchmark runner per instrument mode. Their Vitest lookups move behind `legacy/compat`, which owns the types of the removed benchmark backend so the package type-checks against Vitest 5. - v5 registers CodSpeed as the benchmark provider, which runs the analysis and walltime modes off the registrations it receives. On v5, benchmark URIs carry the registration name after the test path, so a test declaring several benchmarks through `bench.compare()` reports one benchmark per registration. Gate the injection on the instrument mode: Vitest 5 clones its benchmark project after the Vite config hooks ran, so a benchmark run can no longer be detected from the incoming config, and CodSpeed only ever drives benchmark runs. Without CodSpeed the plugin injects nothing and Vitest runs the benchmarks through its own tinybench provider. Vitest 5 also runs `globalSetup` once per project, including the cloned benchmark project, so make setup and teardown idempotent instead of failing the run on the second teardown. Bump the plugin's own dev dependency to Vitest 5 and move its benches to the fixture API, reading imported bindings into a local before the measured loop so the module-runner getters stay out of the samples. Workspace links would make every example resolve the plugin's own Vitest dev dependency, so inject the plugin into the examples that use it: each copy resolves the example's Vitest, as in a real install, and is resynced after every build. Refs COD-2931 Co-Authored-By: Claude <noreply@anthropic.com>
Now that the plugin's own dev dependency tracks Vitest 5, add a dedicated Vitest 4 example so the legacy (v3/4) benchmark seam keeps explicit coverage alongside the existing with-vitest-v3 example. Mirrors that example, pinning vitest ^4.1.9. Refs COD-2931 Co-Authored-By: Claude <noreply@anthropic.com>
Benchmark the plugin against Vitest 5 in CI the way the v3 and v4 examples do for their majors, using the `bench` fixture and `bench.compare()`. Refs COD-2931 Co-Authored-By: Claude <noreply@anthropic.com>
Benchmarks are declared through the `bench` test-context fixture on Vitest 5; keep the top-level `bench()` form as a note for Vitest 3 and 4. Drop the fallback log line from the sample output, which the plugin no longer prints. Refs COD-2931 Co-Authored-By: Claude <noreply@anthropic.com>
4cc5194 to
cdec199
Compare
TL;DR
@codspeed/vitest-pluginnow supports Vitest 5 as well as 3 and 4. The plugin detects which Vitest is installed and hooks into it the right way. Users on Vitest 3/4 see no change.What changes for users
vitestpeer range is now^3.2 || ^4 || ^5.On Vitest 5, benchmarks are written with Vitest's new
benchfixture, and CodSpeed picks them up as-is:Each
bench()in abench.compare()group is reported as its own benchmark:file.bench.ts::fibo 15::recursive.Without CodSpeed, the plugin does nothing and Vitest runs benchmarks normally.
How it works
Vitest 5 removed the benchmark runner the plugin used to extend. Benchmarks now run through a
benchmark.providermodule instead.src/legacy/.src/v5/provider.ts). It runs each benchmark once under instrumentation in simulation mode, or drives tinybench and records walltime results in walltime mode.src/vitestBackend.tspicks one of the two from theversionexported byvitest/node. Sincevitestis a peer dependency, that's the Vitest running the plugin. Code shared by both lives insrc/instrument.ts.globalSetupnow tolerates running twice, since Vitest 5 runs it once per project and clones a separate benchmark project.Also in this PR
getGitDirnow finds the repository root when.gitis a file (git worktrees, submodules). Before, every plugin failed with "Could not find a git repository" when run from a worktree. Inside a submodule, benchmark URIs are now relative to the submodule. Also drops thefind-updependency.with-vitest-v4andwith-vitest-v5examples, so CI covers every supported major.build.CLAUDE.mddocuments how to exercise a plugin in the three CodSpeed modes.Testing
Ran locally:
pnpm turbo run build lint typecheck format test test/integpasses.with-vitest-v3,with-vitest-v4,with-vitest-v5andwith-typescript-esmexamples, plus the plugin's own benches, in fallback, simulation and walltime modes.vitestwith--rootfrom a directory that has a different Vitest installed picks the right integration.Known limitations
[CodSpeed] Checked …lines only show with--reporter=verbose.mongoMeasurement.start/stoparound benchmarks, unlike the Vitest 3/4 runner.Refs COD-2931