Live data from Hacker News

Node.js is able to execute TypeScript files without additional configuration

nodejs.org

211–220 of 275 posts

Re: Node.js is able to execute TypeScript files without additional configuration

#211

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.

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.

The standard library could use some more work.

Re: Node.js is able to execute TypeScript files without additional configuration

#212

Earlier quoted context omitted.

does that require a config?

No, it has good defaults. See also: https://prettier.io/docs/option-philosophy

Good to someone, somewhere, telling everyone else what good is.

Arguably, code formatters should be configurable, to get a format for your code that you want. Unfortunately, prettier isn't one, and it is a form of regression in many communities at the cost of choice pruning.

It might be great for a CI pipeline for constraining how code should look (use prettier, dumbass!), but it isn't great for actually formatting code, as it just makes the code "prettier".

Re: Node.js is able to execute TypeScript files without additional configuration

#213

I’m not a heavy JS/TS dev so here’s an honest question: why not use Bun and forget about node? Sure I understand that not every project is evergreen but isn’t Bun a much runtime in general? It supports TS execution from day 1, has much faster dependency resolution, better ergonomics… and I could keep going. I know I’m just a single data point but I’ve had a lot of success migrating old node projects to bun (in fact I…

> why not use Bun I dislike being on the bleeding edge for things. NodeJS is the most supported in the JS ecosystem. I find it much better to just be on the "default" option for things. You know, choose boring technology.

> You know, choose boring technology.

Is it a boring technology? I remember trying Node.js when it just came out, and I don't think all that much improved. Whole node.js always felt one step forward, two steps back. A lot of early design decisions still hurt it.

I would call it stagnated before I call it boring.

Re: Node.js is able to execute TypeScript files without additional configuration

#214

I’m not a heavy JS/TS dev so here’s an honest question: why not use Bun and forget about node? Sure I understand that not every project is evergreen but isn’t Bun a much runtime in general? It supports TS execution from day 1, has much faster dependency resolution, better ergonomics… and I could keep going. I know I’m just a single data point but I’ve had a lot of success migrating old node projects to bun (in fact I…

Bun is still a toddler: it's not ready for primetime. Simple example: you know how at the command line you can type "npm run", and then type a character or two, hit tab, and the appropriate script from your `package.json` will autocomplete? And if you keep going (eg. "npm run knex") you can do the same thing to autocomplete arguments? Bun still hasn't figured out how to do that ( https://github.com/oven-sh/bun/issues…

Your indicator of technology maturity is "is there an autocomplete script for my shell" ? I have autocomplete working on any CLI app I make before it's even functional.

Re: Node.js is able to execute TypeScript files without additional configuration

#215

Earlier quoted context omitted.

It was the first thing I tried and of course it didn't work. It might finally be time to switch to Deno or Bun =(

I switched to deno for new projects ~1 year ago and it’s only been joy. There’s a shockingly small amount of friction to switch over, and there are so so many benefits

I have only one issue I've encountered with Deno that mattered (so to speak) and it's probably my fault. I actually created an issue for it (https://github.com/denoland/deno/issues/30433).

My project config is weird (slightly more sophisticated that my repro), so, it's probably on me. Otherwise I absolutely love Deno. It makes TypeScript simple and joyful. It's the simplicity this language/tooling ecosystems badly needs in my opinion. Sometimes I feel like it makes TypeScript feel a bit more like working with Go; you can just throw a main.ts in there and build an excellent CLI from it in minutes.

Re: Node.js is able to execute TypeScript files without additional configuration

#217

Earlier quoted context omitted.

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.

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.

Deno first and then Bun. Node should just pass the flag at this point, they just do things to catch up.
Post reply on HN