151–160 of 275 posts
I’m curious what the benefit of stuff like this is vs tsc --watch and running the JS? I’ve always just run tsc to a .gitignored’d directory and execute my JS from there. Edit: Thanks for the responses. There’s some great examples in there!
As a note, Node has a built in --watch now, too
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…
I agree. I've tried the Node TS and test runner features, and they are still (not yet) as good as Bun's. So for now sticking with Bun for those. Really, in the Node ecosystem you eventually learn not to put all your eggs in one basket. Different things excel in different aspects. Here is my preferred setup for now: Bun.js: As a Node runtime, and for TS execution and test running. I tried lots: TSX, TS-Node, Node itse…
But really, any test runner is beter than Node's: that thing is awful. It's like they looked at all the test runners in existence, and instead of copying what they all did, decided "let's make things harder for no apparent reason."
Earlier quoted context omitted.
But... that's like half the reason why I wanted this feature... Writing a library in TypeScript (with typechecks in CI/CD as devDependencies) and just importing it directly from Node.js...
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 =(
This is great up until you get to the fact that typescript will not be accepted under node_modules [0]. That leads me to ask, what about project dependencies? I wrote a lib for my data models in typescript and I want to import that into my app in node, in typescript? Does the rule only apply to npm packages? There’s opportunity here… I wrote a runtime in golang that runs typescript (well, JavaScript in general). The…
I made the same comment here https://news.ycombinator.com/item?id=44931575 "To discourage package authors from publishing packages written in TypeScript" I tried to use it with private packages but that doesn't work either, apparently node doesn't even read the "private" field.
What backend framework is the go to these days? Still Express?
And do mean everything: I run an entire Postrgraphile server through Next (and you can easily do the sme with Supabase or a similar tool)!
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
Is there any movement in the node world for the runtime to be able to ascertain types? Obviously nodejs doesn't do this, but does Bun or Deno or are there plans for any of this in the future?
This has nothing to do with the "node world". Such an enormous feature would have to go into ECMAScript. Which is very, very unlikely to ever happen, they may as well design a new language. All those runtimes implement that spec. Expecting them to write an extremely complex new feature that is easily more complicated than everything already implemented (especially with backwards compatibility, and given that the lang…
Now of course, this would only add type syntax to the language, not true processing: there's nothing in the spec about actually handling them. Still, it's a step in that direction, so I wouldn't say "very unlikely to ever happen" ... "still a long ways off (if ever)" would be more accurate.
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.
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…
Earlier quoted context omitted.
I made the same comment here https://news.ycombinator.com/item?id=44931575 "To discourage package authors from publishing packages written in TypeScript" I tried to use it with private packages but that doesn't work either, apparently node doesn't even read the "private" field.
"Written only in TypeScript" might put it better. If your module ships TypeScript source and a JS build as it should, then this will never affect it. Otherwise, to support stripping arbitrary modules would immediately compromise the design goal of light weight, due to the torrent of ill-founded and -formed bug reports incorrectly raised on Node that would follow. ("Don't make the maintainers' lives too miserable to c…
Earlier quoted context omitted.
Sure, who is going to budget project upgrade effort of ensuring all dependencies work equally as well? There is a reason why so many Java, Python, .NET/C#, C, C++,.. projects are stuck several versions behind.
No one said developing software wasn't going to be work.