Vitest 1.0 Roadmap

[sheremet-va]

Good day everyone 👋🏻

First of all, I wanted to say thank you to everyone who contributed to this project (we have 325 contributors!) for the past year and a half. We wouldn't be where we are today without your support!

The Vitest team announces that we are planning to do the first official stable release alongside Vite 5. To accomplish this goal, we need to close some of the longstanding issues. Here is a list of things that in my opinion should be closed before we can say Vitest is stable:

High Priority

• Remove "experimental" status from "experimentalOptimizer", enable it by default
• Deprecate deps.inline/deps.external/deps.registerNodeLoader. Users should enable deps.optimizer instead to better align with how Vite processes dependencies. This should help Vitest work out of the box for many libraries and frameworks that rely on optimizeDeps.
• Introduce server option to pass down options for Vite Node instead of deps.inline/deps.exclude #3522
• Add more examples with enabled deps.optimizer #3523
• Add separate guide for deps.optimizer #3524
• Add support for running tests using VM (opens up Bun support (we can reuse the same mechanism instead of workers/child_process for now) and speeds up tests for those who think memory trade-offs are justified)
• feat: experimental Vite Runtime API vitejs/vite#12165 (postponed)
• ecosystem-ci for Vitest #3595

Medium Priority

• Improve browser support. Fix the issue with @vitest/utils. Reduce test flakiness.
• Implement module mocking in browser mode #3046
• [RFC] Testing types with expectTypeOf and assertType #1954 (to close this, we need more tests and support for running typechecking per workspace)
• Run vitest typecheck together with normal test in one watch #2299
• Add support for running tests in strict Node.js mode. (Do not inject exports/module/__filename/__dirname, throw error on invalid ESM/CJS file)

The Vitest team will prioritize these tasks over other enhancements. This means we will postpone adding new features until Vitest 1.0 is released.

One thing that should be mentioned is that Vitest 1.0 release will drop support for Vite 4 and Vite 3 since it relies on optimizeDeps having noDiscovery option. This also means Vitest will not support Node.js 16 anymore.

[jd-solanki]

Will browser mode get stable with this release?

[nstepien]

optimizer

• Enabling it with server: { open: true }, opens the browser for some reason.
• deps: { experimentalOptimizer: { web: { enabled: true } } } seems to break @vitejs/plugin-react, though we can disable it in tests:

  Error: @vitejs/plugin-react can't detect preamble. Something is wrong.

  • Feel free to try it out in our repo
• Is it possible to use it to optimize barrel files across tests?

Add support for running tests using VM

I think this links to the wrong issue?

browser support

We're evaluating using vitest browser in this branch, some feedback:

• It's not an "environment", so a test with // @vitest-environment node would still run in the browser
  • we need to test our lib in a nodejs environment to make sure importing the library works, and ssr works
• we don't have access to playwright's page object, which we would need to to trigger native user interactions that are required for some APIs like element.setPointerCapture() or input.showPicker()
  • this limits the usefulness of browser tests
• flakiness

  TypeError: Failed to fetch dynamically imported module: http://localhost:63315/@fs/D:/repos/react-data-grid/test/columnOrder.test.ts?browserv=1686938338502

• No sourcemaps support?
  • stack traces are unusable
• Not a blocker but we get this React spam for each individual test file:

  stdout | unknown test
  %cDownload the React DevTools for a better development experience: https://reactjs.org/link/react-devtools font-weight:bold

And maybe more, please feel free to checkout our branch and try it for yourself.

[sheremet-va]

• Enabling it with server: { open: true }, opens the browser for some reason.

Are you sure it is connected to the optimizer?

seems to break @vitejs/plugin-react

This is a known issue. The fix in the plugin is already merged, but new version is not released yet.

I think this links to the wrong issue?

Thank you, I updated the issue.

It's not an "environment"

And it won't be. "environment" is a feature not supported in browser mode. Browser mode is a runner. Current recommendation is to use it with inline workspace project.

we don't have access to playwright's page object

This is something which will be discussed separately, we support different providers with different browser/page contexts, so it's a bit tricky.

No sourcemaps support?

Feel free to open a separate issue for this.

Overall, browser support is not stable and it's considered experimental. I don't think it will be stable enough for the release, but it would be nice to at least reduce flakiness.

we get this React spam for each individual test file

There is an option test.onConsoleLog that you can use to silence annoying logs.

[nstepien]

Are you sure it is connected to the optimizer?

It happens with

experimentalOptimizer: { web: { enabled: true } }

but not with

experimentalOptimizer: { web: { enabled: false } }

🤷‍♂️

The fix in the plugin is already merged, but new version is not released yet.

That's great to hear, thanks.

Current recommendation is to use it with inline workspace project.
There is an option test.onConsoleLog that you can use to silence annoying logs.

We'll take a look, thanks!

[nickmccurdy]

Will browser mode get stable with this release?

@jd-solanki It should be improved:

• Improve browser support. Fix the issue with @vitest/utils. Reduce test flakiness.

[Aslemammad]

Will browser mode get stable with this release?

@jd-solanki I don't think so, I have so many things to do with @userquin on the browser mode, so many ideas and solutions that need to be experimented with properly. But soon after we get the iframes feature done, we get more chances to experiment with stuff, because many of the ideas depend on this mode which is not merged yet.
But we'll try our best to get it stable.

The current browser DX is not the perfect thing we can get to, there are many things that that need to be improved.

[ghiscoding]

@sheremet-va it could be nice to include this old and unfinished PR #2827 to get expect.closeTo()

• now implemented via PR feat(expect): support expect.closeTo api #4260 :)

[GuskiS]

Can #2334 be looked at to support async event listeners so we can properly close node servers during HMR?

[sheremet-va]

Vitest 1.0 is going to be released on December 4th. The biggest user-facing change is the formatting of snapshots (#3961). There will be a migration guide from 0.34.x to 1.0.

We are planning to follow SemVer strictly so it is possible that 2.0 will be released soon after if there is an urgent breaking change that needs to be made. (Note: experimental API does not follow SemVer - this includes the public createVitest method, typechecking, benchmarking, and browser mode). Generally speaking, we don't want to have a lot of breaking changes.

[michaelfaith]

Great news! Thanks for the update

[GuskiS]

Good news. However, what's the plan with vitejs/vite#12165 ? It seems to be postponed now.

[ghiscoding]

JSDOM v23 also just came out, which dropped Node 16, it's probably better to update it in Vitest before the 1.0 release, Vitest still references v22

vitest/packages/vitest/package.json

Line 183 in ca87027

"jsdom": "^22.1.0",

@GuskiS last month it was mentioned in one of the PR where I asked about vite-node

From the Vitest 1.0 roadmap, it looks like migrating vite-node into Vite is the biggest task left but I assume this might not happen right away since Vite 5 is very close to be shipped?

@sheremet-va replied

vite-node will not be in Vite 5, yes.

[sheremet-va]

1.0 is published:

• https://github.com/vitest-dev/vitest/releases/tag/v1.0.0
• https://www.npmjs.com/package/vitest

If you have any issues, please refer to the migration guide first. If you still have problems, open a separate issue.