Newer versions of node can run typescript directly[1]. The one where types are simply stripped is considered stable[2] (but you can’t use syntax that node doesn’t understand, such as enums).
They’re working on making features work that require some transpilation as well
Completely picking nits: Node doesn’t understand types at all, the distinction is between what TypeScript now calls “erasable syntax”[1] versus syntax excluded by that. The exclusion of enum isn’t likely to affect many projects (because enum has long been panned by most users). Same with namespace. By far the most likely incompatibility is “parameter properties”, ie class fields assigned in the constructor signature.
I agree completely. But I also know I’m in the extreme minority. Now I just use erasable syntax even on my personal projects because it’s less friction. Maybe someday the enum proposal in TC39 will mix this up a bit!
I don't think it's accurate to say "without worrying about configuration". The next line is more accurate:
> tsx runs your TypeScript code with modern and sensible defaults, making it user-friendly and especially great for beginners.
You'd still have to worry about config if you want to make adjustment and when that happens, the implicit smart defaults become a friction point.
It might also surprise you with errors when you attempt to bundle the code. It'd be nice to have tsx available at runtime so I can run TypeScript code without worrying about the transpiler
> You'd still have to worry about config if you want to make adjustment and when that happens, the implicit smart defaults become a friction point.
In practice (when using tsx and when using a similar prececessor tech, esrun) ES moves forwards, not backwards.
Is your target "supported node.js and current browsers"? Today's tsx defaults work with that. They'll also work with tomorrows node.js and current browsers.
tsx is such an amazing tool. A couple of years ago I discovered it and abandoned ts-node and all of the alternatives. I still use it today and I was a sponsor for many months.
Thanks again to the author. It has saved me (and my team) dozens of hours. And I was able to replace all of my ESBuild workarounds that I had made to easily run TypeScript. Cheers.
With node24, no flag needed. These tools are really great and I'm happy to see improvement in the space, but I'm even happier to be able to start getting rid of them with native node improvements.
Newer versions of node can run typescript directly[1]. The one where types are simply stripped is considered stable[2] (but you can’t use syntax that node doesn’t understand, such as enums).
They’re working on making features work that require some transpilation as well
[1]: https://nodejs.org/en/learn/typescript/run-natively [2]: https://github.com/nodejs/node/pull/58643
Completely picking nits: Node doesn’t understand types at all, the distinction is between what TypeScript now calls “erasable syntax”[1] versus syntax excluded by that. The exclusion of enum isn’t likely to affect many projects (because enum has long been panned by most users). Same with namespace. By far the most likely incompatibility is “parameter properties”, ie class fields assigned in the constructor signature.
1: https://www.typescriptlang.org/tsconfig/#erasableSyntaxOnly
Some people hate enums but they’re the only easy form of nominal typing in typescript, and for that alone you can pry them from my cold dead hands.
I agree completely. But I also know I’m in the extreme minority. Now I just use erasable syntax even on my personal projects because it’s less friction. Maybe someday the enum proposal in TC39 will mix this up a bit!
That's some terrible naming. Now there's two things "tsx" stands for in the TypeScript ecosystem.
Been using tsx for years. This had never occurred to me, but you're right
Yup. But it's useful so I use it
I don't think it's accurate to say "without worrying about configuration". The next line is more accurate:
> tsx runs your TypeScript code with modern and sensible defaults, making it user-friendly and especially great for beginners.
You'd still have to worry about config if you want to make adjustment and when that happens, the implicit smart defaults become a friction point.
It might also surprise you with errors when you attempt to bundle the code. It'd be nice to have tsx available at runtime so I can run TypeScript code without worrying about the transpiler
> You'd still have to worry about config if you want to make adjustment and when that happens, the implicit smart defaults become a friction point.
In practice (when using tsx and when using a similar prececessor tech, esrun) ES moves forwards, not backwards.
Is your target "supported node.js and current browsers"? Today's tsx defaults work with that. They'll also work with tomorrows node.js and current browsers.
esno seems a better alternative. esbulit has already solve much of that for devs.
To make matters worse, there is actually a third thing named "TSX" gaining traction right now:
https://esm.sh/#tsx
I was curious about how it works.
It seems to be a wrapper for esbuild that transpiles typescript then calls your local node (it doesn't bundle nodejs).
From https://tsx.is/faq :
"tsx: Uses esbuild for fast compilation and does not perform type checking."
From https://tsx.is/node-enhancement :
"Under the hood, tsx calls node. This means the Node.js features supported in tsx depend on the Node.js version you have installed."
tsx is such an amazing tool. A couple of years ago I discovered it and abandoned ts-node and all of the alternatives. I still use it today and I was a sponsor for many months.
Thanks again to the author. It has saved me (and my team) dozens of hours. And I was able to replace all of my ESBuild workarounds that I had made to easily run TypeScript. Cheers.
TypeScript is great, the only bad thing is that it can be a pain to get the configuration right
It really is the worst name, unsearchable and so overloaded. But it's been an awesome tool. I hope they rename it.
Does this just pass the --experimental-strip-types flag to node?
With node24, no flag needed. These tools are really great and I'm happy to see improvement in the space, but I'm even happier to be able to start getting rid of them with native node improvements.
Last I knew, it did the transpilation itself so that it could handle module path resolution manually.
It does more, it also includes a compatibility layer allowing you to require ESM packages in CJS. It's quite handy!
Don’t recent Node.js releases support this already? require(esm) was back ported to Node.js 20 in February
Use bun
Bun is still unstable for me. I’ve had to switch back to Node for several projects and I end up falling back to tsx.
Came here to say this :)
lol the timing of these two posts (this and https://news.ycombinator.com/item?id=44597966) feel deliberate
The JavaScript version can be called jsx.
The HTML version can be called HTMX
The Java SE version can be called Java SEX.
I love tsx. Lately I’ve been also using bun for the same purpose.
I do love tsx.
[dead]