[eyelidlessness]

It will have some impact, but that erosion will be limited by how readily portable it is (I’d assume very, but haven’t looked at the source) and how attractive a target it’ll be for abstractions.

The former is table stakes if it has any chance of displacing test frameworks which are already widely used for both server and client code. I would be shocked if it’s an issue though, there’s very little to gain from coupling a test framework to Node specifics (its own non-test APIs, V8 bindings, NAPI, etc) unless you’re heavily invested in that focus. (I say this as someone who’s worked on such a project off and on for a while, and even then the primary motivation is to make testing itself more portable without sacrificing performance or tooling.)

The latter—attractiveness as a low level API to build on—remains to be seen. This is something Node generally does well with its novel APIs. But it’s a very crowded space already. And from what I’ve seen looking at the APIs, they don’t offer a whole lot more than basic correctness that can be skipped to quickly prototype and iterate abstraction ideas.

Otherwise it’ll be a reasonable default for very Node-specific greenfield projects. Which is welcome! But it’s also a somewhat niche audience. Portability is going to matter to almost all Node users already, and abstraction will matter to a largely overlapping segment of users who are accustomed to a much richer set of built in and extensible testing semantics.

I don’t want to dismiss the effort or its prospects outright! I just think it’s become increasingly clear that Node’s influence relative to the JS ecosystem is shrinking as the diversity of runtimes increases and as compatibility between them becomes more important.