Skip to content

chore(deps): upgrade tinybench to v6#7100

Open
jerome-benoit wants to merge 20 commits intovitest-dev:mainfrom
jerome-benoit:chore/tinybench-upgrade
Open

chore(deps): upgrade tinybench to v6#7100
jerome-benoit wants to merge 20 commits intovitest-dev:mainfrom
jerome-benoit:chore/tinybench-upgrade

Conversation

@jerome-benoit
Copy link

@jerome-benoit jerome-benoit commented Dec 18, 2024

Description

Upgrade tinybench from v2.9.0 to v6.0.0.

Breaking changes adapted:

  • TaskResult is now a discriminated union — BenchmarkResult redefined as standalone vitest-owned interface with BenchmarkStatistics type and createEmptyStatistics() helper for type-safe defaults
  • Deprecated top-level fields removed (hz, samples, mean, etc.) — using latency.*, throughput.* instead
  • retainSamples option (defaults to false) replaces manual samples.length = 0 clearing — mapped to vitest's includeSamples via centralized getBenchOptions
  • BenchEvent is now a typed class — event handlers use typed event API
  • BenchmarkResult.sampleCount renamed to samplesCount to align with Statistics.samplesCount

Bug fixes included:

  • Fix complete event handler crash when task errors — tinybench v6 fires complete after error, but errored tasks have no latency property. Added task state guard and error tracking
  • Fix errored benchmarks silently marked as pass — now correctly marked as fail
  • Replace Object.assign(result, task.result) with selective field extraction — prevents tinybench runtime metadata (runtime, runtimeVersion, timestampProviderName) from polluting BenchmarkResult and JSON output
  • Fix comparison display diffFixed check ('1.0.0''1.00') with proper else if chain

User-facing type change: BenchmarkResult.sampleCountBenchmarkResult.samplesCount. BenchTaskResult re-export is now the tinybench v6 TaskResult discriminated union.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

  • It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
  • Ideally, include a test that fails without this PR but passes with it.
  • Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.
  • Please check Allow edits by maintainers to make review process faster.

Tests

  • Run the tests with pnpm test:ci.

Documentation

  • If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

  • Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner.

Signed-off-by: Jérôme Benoit <jerome.benoit@piment-noir.org>
@jerome-benoit jerome-benoit marked this pull request as draft December 18, 2024 12:01
Signed-off-by: Jérôme Benoit <jerome.benoit@piment-noir.org>
Signed-off-by: Jérôme Benoit <jerome.benoit@piment-noir.org>
@netlify
Copy link

netlify bot commented Dec 18, 2024

Deploy Preview for vitest-dev ready!

Built without sensitive environment variables

Name Link
🔨 Latest commit 05afd1d
🔍 Latest deploy log https://app.netlify.com/projects/vitest-dev/deploys/69b5426b8777e20008eea95b
😎 Deploy Preview https://deploy-preview-7100--vitest-dev.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@gperdomor
Copy link

@jerome-benoit any progress with this?... Can you migrate this to v4? 🙏🏻

@jerome-benoit
Copy link
Author

It's still on my TODO list, but I had no time to finish the migration.

@gperdomor
Copy link

@jerome-benoit thank you for the quick response... I hope you find some time to finish 👍🏻

…rade

# Conflicts:
#	packages/vitest/src/runtime/runners/benchmark.ts
#	test/benchmark/test/reporter.test.ts
…stream merge

- Use latency.mean instead of deprecated mean in benchmark ranking sort
- Guard filter with benchmark?.latency to handle in-progress benchmarks
- Simplify error handler with null-safe access (e.task?.result?.error)
- Remove dead test:benchmark script referencing deleted workspace
@jerome-benoit jerome-benoit changed the title chore(deps): update tinybench to 3.x.x chore(deps): upgrade tinybench to v6 Mar 4, 2026
@jerome-benoit jerome-benoit marked this pull request as ready for review March 4, 2026 19:38
Copilot AI review requested due to automatic review settings March 4, 2026 19:38
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Upgrades Vitest’s benchmarking integration to work with tinybench@6, adapting internal result types and benchmark reporting/runner logic to match tinybench’s new discriminated-union results and latency/throughput statistics model.

Changes:

  • Bump tinybench dependency to ^6.0.0 (lockfile + package dependency).
  • Refactor runtime benchmark runner/types to use tinybench v6 task/results and map includeSamples to retainSamples.
  • Update benchmark reporters/tests to read from latency.* / throughput.* instead of deprecated top-level stats.

Reviewed changes

Copilot reviewed 10 out of 11 changed files in this pull request and generated 5 comments.

Show a summary per file
File Description
test/cli/test/benchmarking.test.ts Updates include-samples assertions to match v6 latency.samples behavior.
pnpm-lock.yaml Locks tinybench@6.0.0 and updates related dependency metadata.
packages/vitest/src/runtime/types/benchmark.ts Redefines benchmark result/statistics types for v6 (latency/throughput, samples handling).
packages/vitest/src/runtime/runners/benchmark.ts Refactors benchmark execution to Bench.run() and v6 events/results.
packages/vitest/src/runtime/benchmark.ts Tightens benchmark options storage/types and adds formatted name into options.
packages/vitest/src/public/index.ts Updates public type re-exports to new tinybench v6 aliases.
packages/vitest/src/node/reporters/benchmark/tableRender.ts Updates table rendering to use latency.* and compare via throughput.mean.
packages/vitest/src/node/reporters/benchmark/reporter.ts Updates sorting/ranking logic to use latency.mean.
packages/vitest/src/node/reporters/benchmark/json-formatter.ts Stops forcibly overriding samples in JSON output.
packages/vitest/src/node/reporters/base.ts Updates benchmark summary ratio calculation to use latency.mean.
packages/vitest/package.json Bumps tinybench dependency to ^6.0.0.
Files not reviewed (1)
  • pnpm-lock.yaml: Language not supported

You can also share your feedback on Copilot code review. Take the survey.

jerome-benoit and others added 7 commits March 4, 2026 21:08
Guard complete handler against errored/aborted tasks to prevent TypeError crash. Track error state to correctly mark failed benchmarks. Replace Object.assign with selective field extraction to prevent tinybench runtime metadata from leaking into BenchmarkResult and JSON output.

Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-opencode)

Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
Move retainSamples (includeSamples → retainSamples) mapping from the runner call site into getBenchOptions, which now takes the runner config and returns ready-to-use tinybench BenchOptions.

Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-opencode)

Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
Rename numberOfSamples to samplesCount to match tinybench Statistics.samplesCount.

Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-opencode)

Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
@jerome-benoit
Copy link
Author

Hey @sheremet-va @hi-ogawa @AriPerkkio 👋

This PR is finally ready for review! It's been sitting around since December 2024, but it's now fully up to date with main and covers the complete tinybench v2.9.0 → v6.0.0 upgrade.

Beyond the API migration, this includes a few correctness fixes found during an audit of the benchmarking code path (error handling in the complete event, Object.assign result pollution, diffFixed comparison bug). All details in the PR description.

CI is green (the browser test flake on the previous run was from the upstream merge and has since been fixed). Happy to address any feedback. Thanks!

@sheremet-va
Copy link
Member

Hey! Thank you for the PR and sorry for the lack of communication, but we currently don't want to accept PRs targeting benchmarking features because we have a big rewrite on our road map that changes the whole architecture to not treat bench functions as tests: #7850

By accepting this PR we might introduce bugs that need to be fixed in an already kind of softly deprecated feature, so I would rather avoid any turbulence at this time.

@jerome-benoit
Copy link
Author

By accepting this PR we might introduce bugs that need to be fixed in an already kind of softly deprecated feature, so I would rather avoid any turbulence at this time.

Fair enough. But given the actual minimal code churn and the obviousness of the trivial fixes (data structure fields rename, proper condition and code flow, grouped steps, ... and all of it relying on a library version that does not has single bug report since), I do not see how it be worse with it. The current implementation is buggy. Making it just works better will not introduce any maintenance overhead, at all, unless the revamp has already started and that PR will introduce conflicts in another PR.

@sheremet-va
Copy link
Member

Fair enough. But given the actual minimal code churn and the obviousness of the trivial fixes (data structure fields rename, proper condition and code flow, grouped steps, ... and all of it relying on a library version that does not has single bug report since), I do not see how it be worse with it. The current implementation is buggy. Making it just works better will not introduce any maintenance overhead, at all, unless the revamp has already started and that PR will introduce conflicts in another PR.

It could be worse because it can break existing integrations, like codespeed, or it might not! There are almost no tests for benchmarking, so it is hard to catch. The changes in interfaces is already breaking enough, for example.

Basically, I don't want to break the ecosystem multiple times.

@jerome-benoit
Copy link
Author

It could be worse because it can break existing integrations, like codespeed, or it might not! There are almost no tests for benchmarking, so it is hard to catch.

It can't be worse, the code is already telling it.

The changes in interfaces is already breaking enough, for example.

It can be reverted to keep the exact same API if it's an issue for a minor revision beta cycle.

Basically, I don't want to break the ecosystem multiple times.

Understood but here it's basically trivial bug fixes that can be made totally transparent if needed.: vitest already abstract out tinybench internals: API, tunables, in and out data structure, ...

I can add simplified tests ported from tinybench to vitest API in another PR to ensure that PR will pass a more comprehensive of real world usage tests suite for benchmark.

@sheremet-va
Copy link
Member

All of these just increases maintenance, someone needs to write write this, then review this, triage the issue to see if it needs to be reverted. Benchmarking has a very low priority at the moment, it won't be merged anyway. And when priority increases, the work will be focused on the new API.

@jerome-benoit
Copy link
Author

jerome-benoit commented Mar 8, 2026

All of these just increases maintenance, someone needs to write write this, then review this, triage the issue to see if it needs to be reverted.

Discouraging external contributions made by people having a clue on what they are doing is a very bad move for a project maintenance point of view. Especially on a low priority and under maintained component orthogonal to the project main use case. And is even worse if the proposal is offering a baseline unit tests integration that will establish a solid TDD for any future enhancements.
If your goal was to make potential valuable contribution to the project go away, it's a complete success :)

@sheremet-va
Copy link
Member

All of these just increases maintenance, someone needs to write write this, then review this, triage the issue to see if it needs to be reverted.

Discouraging external contributions made by people having a clue on what they are doing is a very bad move for a project maintenance point of view. Especially on a low priority and under maintained component orthogonal to the project main use case. And is even worse if the proposal is offering a baseline unit tests integration that will establish a solid TDD for any future enhancements. If your goal was to make potential valuable contribution to the project go away, it's a complete success :)

Anything added to benchmarking will be removed and rewritten within half a year, the feature in its current state is deprecated. So yes, we discourage any contribution to it as I said in my initial comment. Please, do not take this personally.

As a person who has a clue on what you are doing and whose opinion on benchmarking I respect, you should leave feedback on the next iteration of benchmarking here: #7850

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants