Yes! Glad to hear this. I often enjoy more writing the tests than the actual implementation.

Thanks for the kind words! And your guidance along the way has had huge impact on my career and OSS journey 🫶

test(reporters): add outputFile tests by AriPerkkio · Pull Request #978 · vitest-dev/vitest Adds missing test cases for outputFile configuration. I'm working on another bug fix and thought let's merge these ones first.

This day 4 years ago I sent my first PR to @vitest.dev. Back then it was on v0.7.4 with 80K weekly downloads. After one year and +70 more PRs, @antfu.me and @erus.dev invited me to join the team.
Today we are at v4.1.0 with 35M weekly downloads. Maybe in 2030 we'll have Vitest 8 with 140M downloads.

Slack DM from November 15th, 2024. Younes Jaaidi: "My speculation is that Vitest will surpass Jest usage by Q1 2026 🔮". Brandon Roberts replies: "2026! 💀"

npmx.dev chart showing Jest vs Vitest monthly downloads from Nov 2024 to Mar 2026. Vitest grows from ~30M to 155.5M, surpassing Jest which sits at 143.3M. The lines cross around Q1 2026.

I just need a few more of you to migrate to @vitest.dev so I can prove that crystal balls work 🔮 😉

(the charts from npmx.dev are so neat ❤️)

Nothing in progress yet. In the first step I'd like to see Github Action adding some label when PR is detected to be from a bot account. Closing the PR automatically might be too aggressive.

We need Github action that posts output of this site to the PR if it's detected as non-human. It would speed up reviewing PRs a lot. I also started this morning by looking at confusing PR that was from automated account. 🙃

Flaky tests and memory leaks are the worst.

@vitest.dev now has a flag that catches uncleared intervals, lingering servers, and other async operations leaking across your tests.

Available in the latest 4.1 beta. Big shout out to @ariperkkio.dev from the Vitest team for landing this PR! 🔥

Yes exactly! In addition to performance impact, one downside is that this is Node-only feature. With CDP we could probably detect unresolved fetch calls, but would still be unable to point those to specific stacktraces.

Terminal output of Vitest's test run results. The results contain error message of asynchronous resource leaking. Code block pointing to a fetch call that is missing await.

In the next version of Vitest you can track leaking asynchronous resources via `--detect-async-leaks` option! Available in v4.1.0-beta.4 release. 🔍
(notice missing await in the example)

Github organization invitation with text "You've been invited to the Storybook organization!".

Excited to announce that I've officially joined @chromatic.com! My main focus will be working around features related to @vitest.dev 🤝

Great to have you back! 🫶

As tags are detected by actually running the test file, filtering by filenames will be faster. This is actually why tags feature request was initially rejected.

Partial screenshot from Github issue with text: "Alternative Get someone from Vitest team into Istanbuljs organization and as maintainer of istanbuljs/istanbuljs package"

I'd like to avoid forking Istanbuljs monorepo just for Vitest. Any istanbuljs Github organization members here who could make me a maintainer there? (@kentcdodds.com, @jasonkurian.dev 👋)
github.com/vitest-dev/v...

Chart of weekly Vitest downloads, showing a peak of 20.18 million downloads at the beginning of December 2025.

Vitest hit 20 million weekly downloads in December, right before Christmas break. To put that into context: 5 million @vitest.dev weekly downloads were reached in June 2024, meaning a 4x increase in just 1.5 years. 🎉

Two istanbul coverage reports side-by-side. Left one titled "vite@7 + esbuild", right one "vite@8-beta + rolldown + oxc". Report on the right demonstrates how ignore hints work without @preserve keyword.

When using vite@8-beta with Vitest users no longer need to add magical '@preserve' keywords in their coverage ignore hints. Originally this work-around was needed due to esbuild's (intentional) lack of support for comment preserving. Oxc has built-in support for JS coverage tools' ignore hints.

A screenshot of Vitest terminal showing the times for two runs. The first run takes 9.65s, the second run takes 5.90s.

Vitest 4.0.11 adds an experimental `fsModuleCache` flag to cache module transforms between reruns. Learn more: vitest.dev/config/exper...

This is an opt-in feature, please let us know how it works for you!

And example of a single test file that imports a lot of files (~1500). Almost a 50% boost!

Github CI report showing aria-live-capture project's browser tests running faster than JSDOM.

Project is at github.com/AriPerkkio/a...

Same tests run in browser and JSDOM:

I'm also using browser mode for testing library that does headless stuff on DOM. No components or anything visual. It's more reliable for end-users and actually runs faster than JSDOM.

download StackBlitz projects instantly no authentication or API keys required – just replace the domain. How it works original link: https://stackblitz.com/edit/nuxtblitz download link: https://stackblitz.zip/edit/nuxtblitz (the only difference is that .com is replaced with .zip)

⚡ ever wanted to download @stackblitz.com projects without opening the site?

you now can 🎉

🌐 web: replace stackblitz.com w/ stackblitz.zip in any edit url
🖥️ cli: `npx stackblitz-zip <url>` or `npx stackblitz-clone <url>`
📦 npm: `npm i stackblitz-zip`

built for myself to grab repros from issues

In the early days of experimental browser mode I tried to do this with Astro without success. I ended up with conclusion that Astro doesn't expose APIs for rendering smaller parts of the application. It would be amazing to have this supported 🤩

Excited to see Typesafe CSF factories solve RFC I wrote two years ago. No more explicit TS typings! github.com/storybookjs/...

My talk slides are available here hiroshi-talks.vercel.app/2025-10-25/1 also with source code in github.com/hi-ogawa/talks It was a great experience to talk with many awesome folks in person! Thanks @vuefes.bsky.social for the opportunity!

Announcing Vitest 4.0 Vitest 4.0 Release Announcement

Vitest 4 is out!

- Browser Mode is Stable
- Visual Regression Testing
- Improved Debugging
- Pool Stabilization
- New APIs
- Bug Fixes

Stay updated with our blog post:

vitest.dev/blog/vitest-4

It's mainly because we needed more control of pool architecture on Vitest's side, and didn't want to break Tinypool's public API for all its others users by rewriting everything. Tinypool might be perfect for some users, but for Vitest it was blocker in many ways.

feat!: rewrite pools without `tinypool` by AriPerkkio · Pull Request #8705 · vitest-dev/vitest Description Removes Tinypool and adds new custom internal pool for Vitest only. Some previous thoughts I wrote ~2 months ago about this below. Vitest uses tinypool for orchestrating how test file...

After maintaining Tinypool for over 2 years I'm happy to see next version of Vitest dropping it. I've written some reasoning about this in the linked PR. Even though this change is significant for Vitest, I'm more confident about it than making new changes in Tinypool.
github.com/vitest-dev/v...

VoidZero's @erus.dev talks about the upcoming @vitest.dev features including the new report API and multi-browser configuration as well as what to expect in Vitest 4

🧪 Full video in comments

Watch VoidZero’s @overlookmotel.bsky.social explain how oxlint tackles JS-Rust interoperability to maintain high performance for plugins.

Full video in comment 👇

Is this open source? Link please 👀

If the CLI app that's being tested uses chalk/picocolors, there won't be colors in the app as they check for TTY. In threads pool this doesn't happen as there's no separate process in-between.

I don't think it does. Probably the CLI app you are testing disables its colors when ran in child_process with `stdio: 'pipe'`. If I remember correctly, chalk does some TTY checks for reasons no one knows. Tinylib's color lib had same check copy-pasted.