[HN Gopher] Run TypeScript code without worrying about configura...
___________________________________________________________________
Run TypeScript code without worrying about configuration
Author : nailer
Score : 33 points
Date : 2025-07-17 17:29 UTC (5 hours ago)
(HTM) web link (tsx.is)
(TXT) w3m dump (tsx.is)
| monarchwadia wrote:
| I do love tsx.
| postalrat wrote:
| The JavaScript version can be called jsx.
| cacozen wrote:
| The HTML version can be called HTMX
| SwiftyBug wrote:
| The Java SE version can be called Java SEX.
| spankalee wrote:
| Does this just pass the --experimental-strip-types flag to node?
| webstrand wrote:
| Last I knew, it did the transpilation itself so that it could
| handle module path resolution manually.
| basetensucks wrote:
| It does more, it also includes a compatibility layer allowing
| you to require ESM packages in CJS. It's quite handy!
| andrus wrote:
| Don't recent Node.js releases support this already?
| require(esm) was back ported to Node.js 20 in February
| joshuaturner wrote:
| 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.
| molszanski wrote:
| I love tsx. Lately I've been also using bun for the same purpose.
| chmod775 wrote:
| That's some terrible naming. Now there's two things "tsx" stands
| for in the TypeScript ecosystem.
| subarctic wrote:
| Yup. But it's useful so I use it
| VPenkov wrote:
| Been using tsx for years. This had never occurred to me, but
| you're right
| fjcero wrote:
| Use bun
| danscan wrote:
| Came here to say this :)
| jauco wrote:
| 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
| eyelidlessness wrote:
| 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
| alpinisme wrote:
| 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.
| eyelidlessness wrote:
| 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!
| hu3 wrote:
| 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."
| lacoolj wrote:
| lol the timing of these two posts (this and
| https://news.ycombinator.com/item?id=44597966) feel deliberate
| cellis wrote:
| It really is the worst name, unsearchable and so overloaded.
| _But_ it 's been an awesome tool. I hope they rename it.
| low_tech_punk wrote:
| 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
| nailer wrote:
| > 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.
| keysdev wrote:
| esno seems a better alternative. esbulit has already solve
| much of that for devs.
| low_tech_punk wrote:
| To make matters worse, there is actually a third thing named
| "TSX" gaining traction right now:
|
| https://esm.sh/#tsx
| gosukiwi wrote:
| TypeScript is great, the only bad thing is that it can be a pain
| to get the configuration right
| dimgl wrote:
| 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.
___________________________________________________________________
(page generated 2025-07-17 23:00 UTC)