Give us feedback!

[patak-dev]

Hey! 👋🏼

In case you got to the repo but aren't there yet, consider joining our Discord. There is already a lot of movement on the server.

If you try out Vitest (see preview docs) and something isn't working please create an issue with a repro. Check out the examples, if you try to integrate Vitest in your framework and it doesn't work you can also directly send a PR with a new example even if it is failing. Contributors can work on that PR and fix it before merging it.

If you start using Vitest in your project, please send a PR to add it to the Projects using Vitest list

Or if you have any feedback related to how using Vitest feels to you, please comment in this thread.
Thanks! 🙌🏼

[atk]

Your development speed is so fast that one has to update 2-3 times a day to keep up with all the new goodness, which is almost negating the saved time of running vitest instead of jest ;-) Joking aside, keep up the great work!

[Aslemammad]

The best feedback that I can give is, "I started with trying to see how vitest works, now I'm a contributor myself 😄"

[edimitchel]

I hasn't been involved on a OSS project as I'm now with Vitest!
Knowing that @patak-dev and @antfu are leading the project makes me confident to invest time (incl. sleep time!).

One suggestion feedback I can gave is to provide an exhaustive (as much as possible) roadmap to be able to part easily on dev/docs..
I like the EPIC issue, but this was most of items already assigned to Anthony. Having same for small subjects for minor contributor would be great!

Thanks you all contributors for making a small OSS contributor!

[patak-dev]

Good feedback! I think it is hard to create a detailed roadmap at this point, development is too fast to keep up and too many things are changing daily. But since most open issues are features right now, you could consider the issue tracker as a short-term roadmap for the project https://github.com/antfu-sponsors/vitest/issues. @antfu has been adding tons of feat issues as he progress, and if you get them done first that is awesome, if you were trying to do them and somebody beats you, you could help review the PR and complete what is missing. The knowledge gained from trying to implement any of these feats is important if you plan to keep collaborating in the project anyways.

About docs, I have been adding issues under the documentation label: https://github.com/antfu-sponsors/vitest/labels/documentation, if anyone wants to tackle some of them, more than welcome. I just created one Epic issue for the features guide that could be completed by sending individual PRs by the people that have knowledge in each area #199

[DylanPiercey]

Hello! Firstly thanks all for the work on this project there's great promise here. Currently I've hardly kicked the tires but I hope to take more advantage of it in the future.

I do have a few questions/suggestions and feature requests that I thought I'd throw out there to get your opinions!

Isolating test environment instances

Currently it looks like the env approach is to copy globals into the top level node process. I've found in my experience this can be a bit error prone and also can sometimes lead to issues where you end up using a global from the wrong environment. It can also mean that code is written that wouldn't actually work natively, eg using setImmediate in a native jsdom context or browser would not normally work but here it will.

I wonder if it makes sense to make the env api leverage node's vm module? JSDOM also exposes a vm context we could use to run code directly in the jsdom vm.

Multi project setup

It looks like their is no jest projects equivalent which I personally find very useful to be able to have a standard config file (with a lot of shared config options also) for writing tests in both a node and browser/jsdom environment. It would be super cool to have this in vitest 🙏.

it.fails

Now this is a slightly obscure request but I thought I'd throw it out there. In Marko and some other repo's we maintain we use a mocha plugin called it-fails. This plugin allows you to include failing tests in your test suite, and when the test passes the suite will actually fail. There is also an equivalent api in ava.

I think the description from the ava docs explains the use case well.

This allows you to merge .failing tests before a fix is implemented without breaking CI. This is a great way to recognize good bug report PR's with a commit credit, even if the reporter is unable to actually fix the problem.

We find this incredibly useful especially in open source packages. But it's also useful when there are known issues that you want to document and track, with a reproduction, in a way that you can know when it has been fixed.

Cross env testing

Alright and now we get to the pie in the sky portion. One problem we the Marko team have had for a long time with regard to testing is how do you test code that is partly server rendered, and partly client rendered. That is, how do you test partially hydrated content?

What we need to make this ergonomic is the ability to server render a template, and the execute the client side partial hydration code for that same template. This is tricky to get right, but I do think that as we see more and more solutions that enable some form of partial hydration it could be a great selling feature for a new test runner.

What this has looked like in our internal test suites is essentially creating an isolated JSDOM instance (similar to what I described above) and loading that with the hydration code. Something like

import template from "./index.marko";
import createBrowser from "...";

it("hydrates", async () => {
  // perform initial server render and get raw html.
  const html = await template.renderToString();

  // create a browser environment that we can load modules into, and give it the initial html.
  const browser = createBrowser(html);
  
  // load the hydration code for the component in the browser context.
  await browser.import("./index.marko");
  
  // run tests against hydrated markup.
  expect(browser.document...).to...;
});

Not sure that these tools make sense to bring into vitest, but we actually use jsdom-context-require for this which is a wrapper around context-require. These modules allow you to create isolated nodejs vm contexts with their own isolated CJS require's. In an ESM world though I'm not quite sure what that would look like.

[patak-dev]

All three sound interesting to explore to me, we should check with @antfu and others in the team but I think it will be easier if there are separate feature requests for them. @DylanPiercey would you mind breaking this feedback into three issues?
I needed .fails to test a feature a few days ago. I searched the Jest issues tracker and looks like they discussed something similar but didn't get implemented (.failing).
If you plan to work on some of these features, please drop a line when you create the issues. I think we need bug and feature requests templates :)

[privatenumber]

Just tried out Vitest and I'm really loving it so far. Awesome work! ❤️

Feedback

• Running vitest and immediately going into watch mode felt unintuitive. Especially in cases where I would replace jest with vitest in commit hooks or CI (it would just freeze up and block the process because it's waiting).
• I'd like to use Vitest in Node only packages in-place of jest. I understand why Vite is a peer dependency, but felt a little strange having to install it since I'm not doing any web dev or bundling. Curious what your thoughts on abstracting the testing framework out to be a lighter ESM only framework, and making that a dependency of Vitest to add the plugin support.
• Saw Chai is being re-exported via Vitest so I tried migrating my Jest assertions. Navigating the Chai docs was a little much. Since it's been around for so long, it also feels like they're in maintenance mode -- I would find issues that are years old that have no updates. Maybe I'm just not used to their style but in the future I would love to see your take on a new next-gen assertion library.
• Saw Vite supports Node.js >=14.14.0. Since Node 12 is still in LTS, would be nice if it can be supported. It would definitely help in projects that still need to support Node 12.

[antfu]

Thanks for the feedback.

• Watch: We made the default because we think for most of the time when doing development, the watch mode is more preferable since we can detect the changed files based on the module graph. (it might not match with the behaviour we used to, but I think it's something worth experimenting with to see if there are more possibilities for better DX) You can use the same command in CI as it will detect the process.env.CI env to use the run mode in CI.
• The main goal of Vitest is to run Vite as the transformer and resolver. I believe there are quite a few ESM-only frameworks that are lighter and faster, which unfortunately is not one of our goals. You can definitely use Vitest as the Node-only test, it's just a matter of installing Vite. We could make Vite as a direct dep if needed.
• For now, Chai does hide certain complexity for us to iterate faster. In the future, if it's necessary, we could make a lighter and more efficient solution ourselves. Just like how we did with Sinon and Piscina /cc @Aslemammad @sheremet-va 👀
• From what I see, v12's ESM support is not very complete - or maybe I am wrong. Feel free to investigate the work need to have it support v12, if it's only a few lines of code, I am happy to receive a PR for it. Otherwise, I would not consider it as a priority since we are still in development, and v12 will be dropping within a few months.

[Azema4ka]

You guys have a great library, I'd like to see a roadmap to understand what direction you're going in.