[lunarcave]

I think this + node:test makes Node.js a pretty compelling sensible default for most things now. Running things with `tsx` was such a QoL improvement when it happened, but it didn't solve everything.

Runtime type assertion at the edges is mostly solved through `zod` and tools like `ts-rest` and `trpc` makes it so much easier to do full-stack Typescript these days.

[madeofpalk]

This. It's 2025 and the node ecosystem is finally usable by default!

ESM modules just work with both Node and Typescript, Node can run .ts files, and there's the a good enough test runner built in. --watch. The better built in packages - `node:fs/promises` - are nice with top-level await for easier async loops.

It took a while to convince everyone involved to just be pragmatic, but it's nice now.

[hliyan]

This is great to hear, but perhaps comes too late for people like myself. Node.js has been by go-to platform from around 2014 until last year. But around September last year, I found myself thrust into the .NET ecosystem (due to a client project). Within a few months, I realized that it too, had finally become usable by default (unlike the last time I tried it, when it was too tightly coupled to Windows). In fact, it felt like what Node.js would be, if it had strong typing built-in, and had a good standard library that eliminated a lot of the module management and churn. I'm now finding it hard to return to Node.js.

[d357r0y3r]

What's the story with supporting CommonJS libraries? I've tried to update many projects to ESM multiple times over the years, and every time, I ended up backing out because it turned out that there was some important upstream library that was still CommonJS - or even if we fixed those issues, our downstream NPM consumers wouldn't be able to consume EJS. So then you have to go down this rabbit hole of dual compilation, which actually means using something other than tsc.

[pseudosavant]

I can’t help but think that none of these would have happened without Deno doing it first. It was basically the pragmatic Node before Node started to get reasonable.

[benoau]

Watching NodeJS fill in these gaps the last 5 years or so has been great, I strongly prefer using built-in stuff as much as possible now to avoid bloating the modules and becoming dependent on a thousand random people being good-stewards of their packages.

[balamatom]

You mean TypeScript. TypeScript is finally usable by default.

[ZYbCRq22HbJ2y7]

The standard library could use some more work.

[edem]

nah. it is still eons behind literally everything else

[firloop]

It's still probably better to use Bun.

[thrown-0825]

does it have a go fmt / lint command yet?

[throwmeaway222]

You did the "this" thing AND the "it's $CUR_YEAR"

[_heimdall]

I'm very much in favor of TS support directly in node. vitest has made it easier these days, but I've lost too much time over the years getting the balance just right when configuring test environments for .ts files.

trpc and ts-rest are a different animal in my opinion. I'm happy to use either one but won't deal with them in production. For trpc that's mainly due to the lack of owning API URLs and being able to more clearly manage deprecating old URLs gracefully.

For ts-rest I just tend to prefer owning that setup myself, usually with zod and shared typings for API request/response pairs. It also does irk me every time I import what is clearly an RPC tool named "-rest"

[port11]

vitest is incredible; it makes one wonder how/why jest, with its larger user base and community, couldn't get its TS support sorted.

[edem]

i switched to python a while ago. it has batteries included. i feel so much better now that i dont have to debug all the quirks of a half-baked system.

[wredcoll]

Just wait, you'll find the python pain points at some point.

Two types of languages...

[rs186]

Let's see if Sveltr converts their codebase back to TypeScript

[socalgal2]

Does this run tsx? Even with the types stripped you still need the JSX transformed to JavaScript

[wartijn_]

It doesn’t. The comment you’re replying to is referring to tsx, the package that lets you execute ts files, not to running files with the tsx extension.

https://github.com/privatenumber/tsx