Yes, same with node:test https://nodejs.org/api/test.html

It's an excellent test runner and much, much faster than the others, especially if you set the "isolation" flag to "none".

Testing with Bun would only make sense if you're running it with Bun (or targeting Safari), right?

The problem is jest is run by megacorp Meta, so it won't be fixed in any reasonable timeframe because they're all about new features to make "impact". Its FOSS contributors are typically slow and working primarily to keep their jobs. Also, with node > 20.9.0 being broken and node = 20.9.0 not being a viable option by being insecure, so it's worth having a look at alternatives like bun or deno because it does seem to have lost its way too. I'm currently pinned to 20.9.0 for system dependencies, but use bun for new dev.

Circular dependencies almost always end up causing trouble *eventually* because the body of one of the modules involved has to be evaluated first (when the other participants in the cycle aren't a fully operational battlestation yet).

I've used p3rl.org/circular::require on perl projects before now to root out such dependencies and kill them with fire, and "figure out how to get equivalent technology in TS/JS codebases" is on my list of things to do.

Fundamentally, a circular dependency that currently (apparently) "works everywhere" should still be treated as an unexploded footbomb.

Excising them can absolutely be annoying and inconvenient, but IME not nearly as much as having the damn thing go off when a future maintainer makes an innocuous change an indeterminate amount of time later.

tl;dr: HUMBUG (and sorry I don't have a better answer yet)

I just started to use nodejs test runner in a new project. All configuration is basically:

node --experimental-transform-types --experimental-test-module-mocks --env-file test/test.env --test

It then automatically runs all my test/*.tests.ts files.

So nice to get rid of all that extra config. As this is still a tiny project, I can tolerate some API changes in these experimental features.

My experience using built in node:test and other rapidly evolving things is frustration around getting improvements. I test one of my projects with the oldest supported NodeJS version, and simply can’t use node:test there because the old node:test in Node 18 is missing a lot of features. It’s similar to building for Apple’s platforms - great stuff happens every new major version, but there’s no way to use new libraries with older OS versions. Gotta wait for all your users (and yourself) to update your whole runtime to get those new features.

Maybe if you are on Node 23 and you absolutely have everything you need, then node:test is okay, but I DO NOT recommend it.

I've been very happy with node:test (and deno:test), but also I migrated from mostly mocha as jest I found difficult to configure, especially without unnecessary bundling configurations as the ESM support among other things was broken for far too long (but mocha delivered it well). Most of my successful uses of jest were out-of-the-box configs in create-react-app and the Angular tools to strip uses of karma and replace them with jest. (Side rant: Seriously whoever thought that karma was a good idea for a test runner? "I love V8 so much I'm using Node's V8 to spin up another headless Chromium's V8 so I can V8 from inside V8." lolsob)

Yes we're using the built-in test runner and it's much better than jest.

Jest is full of unneeded magic (= complexity), whereas node:test is straightforward and has a better design. Highly recommended. You can turn off process isolation for extra speedup!

I was under the impression that playwright was (a very good) how your code behaves when actually running in a browser testing library, and vitest was a how your code behaves on its own testing library.

But I'd tend to have relatively independent test suites for my frontend model/state layer and the "how it behaves live in a browser" stuff because that way if I'm not currently iterating on my view components I can test the rest of my frontend code changes without having to faff with headless browser instances.

(obviously you'd then want to run both before committing, and again under CI before merge, but still)

Depending on how thin your model/state layer is (and if you have a Sufficiently Rich Backend then it can probably be very thin without that being an issue) your situation may not match mine, of course.

But y'know, free data point, worth exactly what you paid :D

Hi, I work at Speakeasy. Thanks for this. I'll look into this and correct the post. Thanks :)