Vitest 5

[sheremet-va]

We wanted to start gathering feedback for the next major version. Vitest 4.1 is on its way and will include a lot of new features without any breaking changes (including tags, around hooks, --detect-async-leaks and a new test.extend syntax with type inference).

What are the feature that you would like to see in the next major and what are the bugs that you want us to prioritize?

What are the main pain points in your testing workflow right now?

Timeline

We generally do not have a strict timeline and try to align with Vite releases when possible. This time around Vite 8 will be released soon and it will be supported in Vitest 4.1, so we do not feel the pressure to release more breaking changes soon.

You can follow the current milestone for Vitest 5 here: https://github.com/vitest-dev/vitest/milestone/25

Experimental Features

We have released quite a few experimental features with the goal to improve debugging and testing performance. Consider leaving your feedback there:

• Stabilizing `fsModuleCache` #9221
• Stabilizing `openTelemetry` #9222
• Stabilizing `importDurations` (previously `printImportBreakdown`) #9224
• Stabilizing `viteModuleRunner` #9501

[sheremet-va]

What do people think about enabling clearMocks/mockReset or restoreMocks by default?

[kraenhansen]

As a continuation of the current browser mode, I want to run tests across all sorts of environments, regardless of their runtime APIs 💙 (React Native in particular)

[alexanderop]

being able to get code coverage for browser mode would be nice .

[Smrtnyk]

being able to get code coverage for browser mode would be nice .

isn't it already supported?

[sheremet-va]

Browser Mode supports both v8 (only for chromium browsers) and istanbul coverage providers

[alexanderop]

ah true my mistake now it works some months ago I could made it work nice

[MariusVatasoiu]

Improvements on browser mode. Probably it needs full bundle mode support to handle bigger projects.

[hcampos-professional]

Visual regression testing improvements and scalability. Namely, being able to update/accept baselines individually or in batch via the UI.

Alternatively, better extensibility of the browser mode UI to make it possible/easy to build, for example, a custom tab with custom previews and image review/acceptance UI. Currently we render our custom UI to the main iframe after tests end, which isn’t ideal.

And being able to use custom (async) comparators - e.g., in our case we would like to compare not against baseline images stored in the repo but against our own image store. We also use a hashing mechanism to avoid downloading baseline images unless there is a failure, which can speed CI up considerably given that we have several thousand baselines.

[sheremet-va]

You should already be able to use async comparators: https://vitest.dev/config/browser/expect.html#browser-expect-tomatchscreenshot-comparators

[macarie]

in our case we would like to compare not against baseline images stored in the repo but against our own image store

This looks like an interesting use-case, @hcampos-professional, would you mind expanding on it?

As far as I understand, custom comparators wouldn't really help here. Currently we check if there's a reference screenshot, if there isn't one, the test will fail as it creates a new one — unless running with --update, but then it would just write it and the test will always succeed. Users can hook into (sync) path resolution, but not into the file-read process.

Would it help if Vitest had an option to customize reference-reading (and writing, I believe)? This would allow downloading references just in time for decoding then everything else would keep working as if the file was local.

[porada]

React Server Components