7 ms·
Run TypeScript code without worrying about configuration
- gosukiwi 1y agoTypeScript is great, the only bad thing is that it can be a pain to get the configuration right
- monarchwadia 1y agoI do love tsx.
- postalrat 1y agoThe JavaScript version can be called jsx.
- spankalee 1y agoDoes this just pass the --experimental-strip-types flag to node?
- webstrand 1y agoLast I knew, it did the transpilation itself so that it could handle module path resolution manually.
- basetensucks 1y agoIt does more, it also includes a compatibility layer allowing you to require ESM packages in CJS. It's quite handy!
- andrus 1y agoDon’t recent Node.js releases support this already? require(esm) was back ported to Node.js 20 in February
- joshuaturner 1y agoWith 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 1y agoI love tsx. Lately I’ve been also using bun for the same purpose.
- chmod775 1y agoThat's some terrible naming. Now there's two things "tsx" stands for in the TypeScript ecosystem.
- neeelrusia 1y ago[dead]
- fjcero 1y agoUse bun
- danscan 1y agoCame here to say this :)
- dimgl 1y agoBun is still unstable for me. I’ve had to switch back to Node for several projects and I end up falling back to tsx.
- nsonha 1y agoor swc
- daveidol 1y agoOr deno
- steve_adams_86 1y agoBun has some niceties that I appreciate in some contexts, but I prefer Deno quite a bit for projects today, as well as for the future of the project. Web standards are a great foundation to lean on (in my opinion).
- jauco 1y agoNewer 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 https://nodejs.org/en/learn/typescript/run-natively [2]: https://github.com/nodejs/node/pull/58643 https://github.com/nodejs/node/pull/58643
- eyelidlessness 1y agoCompletely 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 https://www.typescriptlang.org/tsconfig/#erasableSyntaxOnly
- alpinisme 1y agoSome 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 1y agoI 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!
- matt_kantor 1y agoI find that for most of my use cases, branded types[1] are close enough to nominal (especially if you use a private `unique symbol` as the brand). [1]: https://www.learningtypescript.com/articles/branded-types https://www.learningtypescript.com/articles/branded-types
- hu3 1y agoI 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 https://tsx.is/faq : "tsx: Uses esbuild for fast compilation and does not perform type checking." From https://tsx.is/node-enhancement 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 1y agolol the timing of these two posts (this and https://news.ycombinator.com/item?id=44597966 https://news.ycombinator.com/item?id=44597966) feel deliberate
- cellis 1y agoIt really is the worst name, unsearchable and so overloaded. But it's been an awesome tool. I hope they rename it.
- low_tech_punk 1y agoI 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 1y ago> 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.
- low_tech_punk 1y agoTo make matters worse, there is actually a third thing named "TSX" gaining traction right now: https://esm.sh/#tsx https://esm.sh/#tsx
- jasonjmcghee 1y agoThat's the same tsx as the tsx people use with react. Typescript XML
- dimgl 1y agotsx 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.
- 90s_dev 1y agoNote that you can also get TSX in native Node.js with minimal configuration[0]. This is accomplished via module hooks and TypeScript's own compiler (or bring your own compiler like swc). [0]: https://github.com/sdegutis/immaculata https://github.com/sdegutis/immaculata
- bravesoul2 1y agotsx vs. ts-node?
- IceDane 1y agoRead the website?
- bravesoul2 1y agoOh yes. Tsx is better based on the tsx's unbiased comparison.
- __alexs 1y agoWe've been using ts-node with swc for ages and seems to work great. Never really understood why tsx exists.
- jahewson 1y agoYou’re in luck, around half the page linked to above is devoted to explaining that: > The idea for tsx came about during a time when the Node.js ecosystem was getting fragmented due to the release of ES Modules (ESM). As packages migrated to ESM, projects struggled to reconcile their CommonJS apps with ESM dependencies. >Back then, ts-node was the go-to tool for running TypeScript in Node.js, but it lacked ESM support and was quite complicated to use. We noticed several open-source tools using esbuild to run TypeScript in Node.js and decided to bring these efforts together into one simple, cohesive project.
- dzonga 1y agotill present day, I haven't found a justified reason of why people use typescript on the backend. C# - gives you similar syntax with a better ecosystem + tools. if it's just types you love Java, Kotlin, Golang the same. Better languages better tools, better ecosystems. typescript on the backend shows people have more money than sense. maybe after all i'm lost on the incentives.
- IceDane 1y agoIt boils down to that there are not many good reasons not to. The vast majority of backends people write are really just relatively thin proxies to your database or something like that. They mostly wait on IO, which is perfect for node. It's just a no-brainer when it's a good fit and you already have competent devs. Then there are advantages like being able to share types across your entire system without having to resort to code generation. On top of all that, we have Effect which is easily the best and most robust way to write production grade typescript. It's nearly a language into its own and sort of should be, but we are fortunate that we can instead have and use such a useful tool in the most popular ecosystem in the world.
- pjmlp 1y agoThe usual write code on the server that can be copy pasted on the client, like form validations. Plus many SaaS vendors now have node only SDKs, so if I want to use C# or Java, I have to advocate for the team to write their own REST bindings, instead of using the existing SDK, naturally a quixotic battle that I won't bother with. In favour of Typescript, it has been designed by the same key architect as C#, so I don't feel that bad using yet another language from one of my language designer heros. And if I need some additional perf on the server beyond V8, there are always native node modules.
- nailer 1y ago> C# - gives you similar syntax with a better ecosystem + tools. if it's just types you love Java, Kotlin, Golang the same. Code written in those languages tend to embrace nineties-style OOP with classes and inheritance. node.js is generally functional.
- v5v3 1y ago
- stevage 1y agoI generally use Bun for this purpose. I don't really know how Bun does what it does, but it seems to manage to do Node-ish things like NPM and running Typescript without getting caught up in all the myriad variations of TS and ESM configuration options. Just works.
- touristtam 1y agoSame with Deno (mostly). Been using it for pet/personal project for the past 6-8 months and it is been a bliss not to have to deal with all the ~~shit~~ config hell.
- kylecordes 1y agoA challenge with TSX, and as I understand other similar tools, is that it doesn't support TypeScript decorator metadata. A few years ago, libraries using that started to get popular, so many older projects have a significant obstacle to moving away from running the TypeScript compiler JS output. Starting a new project today, I think the right move is to use TSX or Bun or whatever. You want a roadblock at the very first moment you start trying one of these limited compatibility libraries, Because it won't work and then you'll pick a different library that doesn't rely on non-erasable TypeScript syntax.
- pas 1y agois support not even planned (realistically possible?) in these fast transpilers (like esbuild, used by tsx, right?)
- WorldMaker 1y agoAs far as I know the current bottleneck is Decorators are still only Stage 3, so the transpilers can transpile it as is (which I believe esbuild already does), but Node won't support running it until Stage 4.
- WorldMaker 1y agoThe libraries that started to get popular using decorators years ago were using an --experimental compiler flag and should have known better than push that into production usages. There's a Stage 3 decorators that now compiles in Typescript (>5.0) out of the box without an --experimental compiler flag, but it is subtly incompatible with that old experimental dialect and it will take some time before all those libraries catch up, if they catch up. It won't run in Node (or this TSX) just yet because I believe Node waits for Stage 4 before enabling language features. (Deno has an experimental flag for it, as Deno supports Stage 3 features behind experimental flags.)
- michaelsalim 1y agoDoes anyone use this in production? I tried it and it was great. But I stopped using it since I assume there'll be quite a performance hit compared to a traditional build, then running with node.
- sharlos201068 1y agoI don't think there's much good reason not to compile to JavaScript for production. For local Dev and tests it simplifies things though