On: Should you use Jest as a testing library? (2022)

[codefined]

Vitest[0] is a drop in replacement to Jest that we've had exceptional success with. Faster test runs, more reliable, default TS and ESM support, etc.

[0] https://vitest.dev/

[xer0x → codefined]

Vitest may not be a good drop in replacement either. It uses Workers for multi-threading via Tinypool. For us, we use the AWS SDK and the binaries in it would cause Vitest to crash. After wasting a lot of time, we had to retreat back to Jest.

I really like Vitest, and it's a great fit for lots of projects. I'm a bit sad it wasn't for ours.

[shitlord → xer0x]

Just curious, were you using v2 or v3 of the AWS SDK? I was going to try Vitest after reading these comments, but maybe it's not feasible right now.

[seniorsassycat → codefined]

Big fan of vitest, I like typescript and esm support out of the box and without adding dependencies like types/jest or ts-jest. I've filed bugs and pull requests and the maintainers have been responsive

[deanc → codefined]

It is most definitely not drop in. I looked into this yesterday funnily enough and you can expect to have to make many syntax changes to your test files.

[thatswrong0 → codefined]

It's an _almost_ drop in replacement - when I tried migrating our tests recently (because of memory leak issues / slowness resulting from Jest + a Node upgrade) I found I had to manually finagle a lot of our mocks to get them working.

[seniorsassycat → codefined]

Does vitest have this same issue or make a trade off to avoid it like jest-light-runner

[ehsanu1 → codefined]

That seems tied to Vite though?

[zerace → ehsanu1]

It's actually not! You can use vitest in a node environment as well just fine.