iiinova — where your digital self keeps evolving

AriPerkkio @ariperkkio.dev · 28/09/2026

This Thursday we'll be discussing about Visual Regression Testing using @vitest.dev and @chromatic.com. Join me and @kylegach.com to hear how you can get VRT that's stable across your whole team, not just on your local machine. 📸

0139

AriPerkkio @ariperkkio.dev · 10/09/2026

Maybe worth to mention for inspiration if you end up building something for your case: ~6 years ago I built a tool for eslint plugins to do exactly this. It allows custom eslint plugins to test themselves against ~10K Github repos (or as many as they can in 6 hours) and see if they work as expected.

github.com

GitHub - AriPerkkio/eslint-remote-tester: CLI tool for testing given ESlint rules against multiple repositories at once.

CLI tool for testing given ESlint rules against multiple repositories at once. - AriPerkkio/eslint-remote-tester

030

Reposted by AriPerkkio

Chromatic @chromatic.com · 03/09/2026

Chromatic for @vitest.dev Browser Mode is live. 🧪📸 Browser Mode runs your component tests in a real browser. Now Chromatic checks how those components look by capturing the rendered UI. No new screenshot assertions. No second suite to maintain. 🧵 (1/4)

Vitest Visual Regression Testing with Chromatic

1244

AriPerkkio @ariperkkio.dev · 28/08/2026

Yes. I'm not a fan of forking widely used projects like this. Instead I would like the whole ecosystem to contribute in one shared project like the original istanbuljs repository. But this time forking was the only choice as istanbuljs has zero maintenance at this point.

010

AriPerkkio @ariperkkio.dev · 28/08/2026

Yes, definitely! We are already thinking about modernizing the most-used "html" reporter with features like dark mode and Vitest color theme. Feel free to open issues in github.com/vitest-dev/i...

010

AriPerkkio @ariperkkio.dev · 27/08/2026

The @vitest/istanbuljs fork is now ready and will ship in the next version of Vitest. Compared to the original istanbuljs packages it's ESM-only, ships its own typings, drops unnecessary runtime deps, and moves Node 8→22, Babel 7→8 (lib-instrument), React→Preact (html-spa reporter), and more!

github.com

Release v1.0.0 · vitest-dev/istanbuljs

v1.0.0 First stable release of @vitest/istanbuljs, a fork of istanbuljs/istanbuljs maintained by the Vitest team. The fork starts at upstream commit 28ffdbc (see vitest-dev/vitest#9433 for backgrou...

24411

AriPerkkio @ariperkkio.dev · 05/08/2026

Yeah it might cause unexpected changes in visual testing. Though same issue will happen with the "playwright install chromium" too. I've had so bad experience trying to setup stable visual testing infra myself that I just gave up on that approach many years ago. Now I'd recommend Chromatic+Vitest 🤝

120

AriPerkkio @ariperkkio.dev · 05/08/2026

Yes definitely. For projects that don't target specific browser versions it should be enough. If you are testing how some specific browser version works, a typical "playwright install chromium" might not be good option either.

120

AriPerkkio @ariperkkio.dev · 05/08/2026

Yes! Apparently Ubuntu has had it pre-installed for a while. I've wasted so much CI time and energy installing chromium over and over again.

020

AriPerkkio @ariperkkio.dev · 05/08/2026

TIL when running Vitest browser mode (or plain Playwright) on Github Actions on Ubuntu, you can skip the slow "playwright install chromium" step completely by providing channel option. This makes Playwright use the pre-installed Chrome. So many projects out there that could speed their CIs with this

Github PR diff view showing removal of "playwright install" step, and addition of "launchOptions.channel: 'chrome'" on Vitest Playwright provider.

41149

Reposted by AriPerkkio

James @43081j.com · 30/06/2026

is the distributed code readable? yes - don't ship a sourcemap. no - make the distributed code readable.

1262

Reposted by AriPerkkio

Chromatic @chromatic.com · 11/06/2026

Get first access to our @vitest.dev plugin, which adds Chromatic’s visual testing and review to your browser tests. It’s built by @ariperkkio.dev, a Vitest core maintainer. It’s free to use while in beta and requires no changes to your test files. Read on for more info 🧵

Early access. Vitest Browser Mode visual tests in Chromatic for free (while in beta for the summer)

1163

AriPerkkio @ariperkkio.dev · 01/06/2026

Building this integration has been amazing opportunity to dogfood all APIs we've added into @vitest.dev in past years. It's using features like new Reporter APIs, Vitest plugin hooks, browser commands, CDP, test tags and much more! Vitest is definitely one of the most extensible JS tools out there.

1237

AriPerkkio @ariperkkio.dev · 31/05/2026

If you've published a package using staged publishing before this fix, all that's needed now is to re-publish the same package and @npmx.dev will display the trusted publishing label again 🤝

npmx timeline of ast-v8-to-istanbul package. Trusted publishing was removed on May 25th, and re-enabled on May 31st.

0292

AriPerkkio @ariperkkio.dev · 29/05/2026

Which coverage metrics do you find the most useful? Which ones would be good defaults for typical users? JS coverage ecosystem relies on defaults that were set ~12 years ago. Modern tools could break the cycle, but changing this old defaults is scary.

110

Reposted by AriPerkkio

Chromatic @chromatic.com · 28/05/2026

We’re launching early access for Vitest visual testing with Chromatic! ⚡️ Built with @vitest.dev core maintainer ariperkkio.dev, Chromatic adds visual testing to the browser tests you already write. 🧵 (1/4)

vitest-chromatic-integration-early-access-program

3538

AriPerkkio @ariperkkio.dev · 13/05/2026

Testing terminal output is hard. Especially in cases that involve clearing screen partially while maintaining stable log output elsewhere on screen. With ansivision it's possible to simulate what output all the ansi codes would render visually in real terminal. No need to use heavy node-pty anymore.

github.com

GitHub - 43081j/ansivision: A library to time-travel through terminal output and more.

A library to time-travel through terminal output and more. - 43081j/ansivision

080

AriPerkkio @ariperkkio.dev · 13/05/2026

Thanks, it works! We can finally test Vitest's fast-updating SummaryReporter with this! I always thought it would be too difficult to simulate terminal's behaviour, but this library does it perfectly 💯 Also found one edge-case bug in Vitest while setting this up. 🙃

Test case validating Vitest's SummaryReporter using ansivision-package. Inline snapshot describes changes of test summary, showing test run progress.

070

AriPerkkio @ariperkkio.dev · 10/05/2026

So writing on multiple cursor positions on a single line causes multiple frames? We use synchronized updates to define what is a frame.

github.com

110

AriPerkkio @ariperkkio.dev · 10/05/2026

Looks interesting! What makes "a frame"? If text gets updated but cursor isn't set to the last row, how can it detect a new frame? Or does it flush changes on interval? We could probably use this to test summary reporter: github.com/vitest-dev/v...

github.com

feat(reporters): `summary` option for `verbose` and `default` reporters by AriPerkkio · Pull Request #6893 · vitest-dev/vitest

Description Closes Test summary during watch mode run #3732 Fixes [Bug] Terminal output is cut off while async test is executing #6590 Fixes Terminal UI flickering #6177 Requires fix(child_proce...

120

AriPerkkio @ariperkkio.dev · 02/05/2026

Before or after summer so that forests won't be full of mosquitoes. April-May or September-October I'd say. Summer time is great to visit too if you can handle all the bugs. But northern Finland is definitely full of mosquitoes.

120

AriPerkkio @ariperkkio.dev · 28/04/2026

But if you are happy with Jest and all its trade-offs, and value 7 second speed difference more than Vitest, migrating to Vitest might not be the solution here.

000

AriPerkkio @ariperkkio.dev · 28/04/2026

It depends very much on your code. This article explained some differences well. Comparing just Jest vs Vitest, without any additional plugins or integrations, you should see somewhat similar speed when isolation is enabled and ~10x faster speeds on Vitest when isolation is disabled.

medium.com

Why your Vitest test suite is slow (and how to fix it)

After weeks of configuration and tweakings, my team and I finally made it, we’ve migrated from Jest to Vitest!

110

AriPerkkio @ariperkkio.dev · 27/04/2026

Using `pool: 'vmThreads'` or 'vmForks' might save you those 7 seconds. It has same memory leaks and node:vm issues that Jest has. vitest.dev/config/pool....

vitest.dev

Vitest

Next generation testing framework powered by Vite

100

AriPerkkio @ariperkkio.dev · 26/04/2026

V8 will remain the default in Vitest 5. Maybe we can get built-in oxc based instrumentation in Vitest 5 though. Then based on feedback, stability and backwards compatibility, we could default to that in Vitest 6. Changing defaults needs time.

010

AriPerkkio @ariperkkio.dev · 24/04/2026

Oulu is fun small city until the long dark winter comes up. Days with just 3 hours of "sun" are not that fun. But summer is great. visitoulu.fi/en/ I've seen people trying to learn the language for years until they gave up.

visitoulu.fi

Oulu is European Capital of Culture 2026! - Visit Oulu

The best travel tips for Oulu! Events, restaurants, accommodation, activities, attractions, fun facts – all gathered for you here.

120

AriPerkkio @ariperkkio.dev · 15/04/2026

There's some impressive work going on with 3rd party oxc powered coverage instrumentation that can replace Babel based istanbul-lib-instrument 👀 > 8-11x faster than babel-plugin-istanbul, 13-15x faster than swc-plugin-coverage-instrument (Rust/WASM), 25-30x faster than istanbul-lib-instrument.

github.com

GitHub - fallow-rs/oxc-coverage-instrument: Istanbul-compatible JavaScript/TypeScript coverage instrumentation using the Oxc AST

Istanbul-compatible JavaScript/TypeScript coverage instrumentation using the Oxc AST - fallow-rs/oxc-coverage-instrument

1257

AriPerkkio @ariperkkio.dev · 14/04/2026

Good choice! One day we'll got to rent a castle in Islay and do OSS retreat there. So far I've visited there twice - though no castles back then.

130

AriPerkkio @ariperkkio.dev · 10/04/2026

Outage that affects only one package, not both?

110

AriPerkkio @ariperkkio.dev · 10/04/2026

@vitest.dev just surpassed Jest in npm weekly downloads 📈 npmx.dev/compare?pack...

31055

AriPerkkio @ariperkkio.dev · 09/04/2026

Is there a story behind the name Sätteri? Sounds like a Finnish surname. 👀

100

AriPerkkio @ariperkkio.dev · 18/03/2026

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

110

AriPerkkio @ariperkkio.dev · 18/03/2026

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

110

AriPerkkio @ariperkkio.dev · 18/03/2026

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.

github.com

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.

2368

Reposted by AriPerkkio

Younes Jaaidi @younesjd.dev · 16/03/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 ❤️)

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.

2458

AriPerkkio @ariperkkio.dev · 24/02/2026

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.

100

AriPerkkio @ariperkkio.dev · 23/02/2026

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. 🙃

430

Reposted by AriPerkkio

VoidZero @voidzero.dev · 18/02/2026

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! 🔥

2569

AriPerkkio @ariperkkio.dev · 17/02/2026

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.

010

AriPerkkio @ariperkkio.dev · 16/02/2026

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)

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.

27311

AriPerkkio @ariperkkio.dev · 09/02/2026

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

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

5594

AriPerkkio @ariperkkio.dev · 03/02/2026

Great to have you back! 🫶

110

AriPerkkio @ariperkkio.dev · 22/01/2026

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.

020

AriPerkkio @ariperkkio.dev · 12/01/2026

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...

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

1174

Reposted by AriPerkkio

VoidZero @voidzero.dev · 05/01/2026

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. 🎉

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

2333

AriPerkkio @ariperkkio.dev · 08/12/2025

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.

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.

0162

Reposted by AriPerkkio

Vladimir @vladimir.berlin · 20/11/2025

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!

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

45510

AriPerkkio @ariperkkio.dev · 13/11/2025

Project is at github.com/AriPerkkio/a... Same tests run in browser and JSDOM:

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

110