I second this. The tsx library is zero config and always "just works" in my experience, which puts it miles ahead of ts-node, imo.

Seconded again. While tsx usually just works ts-node almost never just works. tsx is perhaps unfortunately named though so it may confuse people at first since it has nothing to do with jsx syntax.

Thank you for bringing this up, I almost ignored this project since I assumed it had something to do with TypeScript + JSX.

The JS ecosystem sure struggles with naming things.

The _programming_ ecosystem sure struggles with naming things.

Fair enough

I own the npm package node-ts, which has thousands of installs per week just because people confuse it with ts-node.

I didn't intend to typo-squat. Actually, my package is older than ts-node and was just a pun because it is an API for TeamSpeak written in TypeScript.

It's named as such to mirror `npx`

tsx has very slow startup performance, I prefer https://github.com/swc-project/swc-node which is around twice as fast.

Does swc-node work with code coverage calculation libraries? For a long time tsx didn’t (and it’s still pretty finicky) so that kept me from using it.

Not sure what features those need, but at least the stack traces are correct in swc-node, so maybe worth a try.

We have not seen this whatsoever. How big is your project? `tsx` is almost instantaneous in a server-side project of ours.

A hello world here takes 400ms on tsx and 250ms on swc-node for me.

Basically it boils down to swc being faster than esbuild, see their benchmarks:

https://swc.rs/docs/benchmarks

Tsx’s only reset-in-console mode is <Enter>, which makes it impossible to develop cli apps in watch mode.

You cannot run tsx from a non-project cwd if you’re using tsconfig/paths.

And personally I find its maintainers relatively unpleasant to message with. Leaves “you’re plebs” aftertaste most of the times.