Live data from Hacker News

Node.js adds experimental support for TypeScript

github.com

261–270 of 570 posts

Re: Node.js adds experimental support for TypeScript

#261
post #193

It's been a really eventful month for Node. First they added node:sqlite in v22.5.0, and now TypeScript support is landing. I love the direction Node is heading in.

It is Bun influence / competition I guess. Good for everyone.

I believe the competition started with Deno. But yes, Bun is part of the competition now, too.

Re: Node.js adds experimental support for TypeScript

#262

Earlier quoted context omitted.

You can have this now adding types with JSDoc and validating them with typescript without compiling, you get faster builds and code that works everywhere without magic or need to strip anything else than comments. The biggest pain point of using JSDoc at least for me was the import syntax, this has changed since Typescript 5.5, and it's now not an issue anymore.

[flagged]

I’ve had a lot of success combining JSDoc JS with .d.ts files. It’s kind of a Frankenstein philosophically (one half using TS and one half not) but the actual experience is great: still a very robust type system but no transpiling required.

In a world where ES modules are natively supported everywhere it’s a joy to have a project “just work” with zero build steps. It’s not worth it in a large project where you’re already using five other plugins in your build script anyway but for small projects it’s a breath of fresh air.

Re: Node.js adds experimental support for TypeScript

#263

Earlier quoted context omitted.

Closure was also interesting because it integrated type checking and minification, which made minification significantly more useful. With normal Javascript and typescript, you can't minify property names, so `foo.bar.doSomethingVeryComplicated()` can only be turned into `a.bar.doSomethingVeryComplicated()`, not `a.b.c()`, like with Closure. This is because objects can be indexed by strings. Something like `foo.bar[f…

> A minifier can't guarantee that such expressions won't be used, so it cannot optimize property accesses. Given TypeScript’s type system is unsound, neither could it even if it tried, right? I guess Flow could, but well, here we are.

Theoretically TS could… until it encounters an ‘any’ type in that code path, then it would have to give up.

But there are TSconfig options to ensure no use of any so with the right level of strictness it could happen.

Re: Node.js adds experimental support for TypeScript

#264

Earlier quoted context omitted.

btw if anyone is looking to run ts on node, there is tsx. there is also ts-node but i prefer tsx. https://github.com/privatenumber/tsx

tsx has very slow startup performance, I prefer https://github.com/swc-project/swc-node which is around twice as fast.

Does swc-node work with code coverage calculation libraries? For a long time tsx didn’t (and it’s still pretty finicky) so that kept me from using it.

Re: Node.js adds experimental support for TypeScript

#265
post #193

Earlier quoted context omitted.

It is Bun influence / competition I guess. Good for everyone.

I believe the competition started with Deno. But yes, Bun is part of the competition now, too.

Deno was doing its own thing though.

Bun came out swinging with strong Node.JS compatibility promises. I have simply replaced node with bun for most of my own work without much effort. The mental effort required is to use `bun` instead of `node` in command line for most of the trivial things.

Re: Node.js adds experimental support for TypeScript

#267

Bun’s DX is pretty unprecedented in this space, and most of my use cases are now covered / not causing Bun to crash (when actually using run-scripts with `bun run`). Meanwhile, I can’t configure node to not require extensions on import, nor have tsc configured to automatically add .js extensions to its compiled output, without adding on a bundler… although native TypeScript support would remedy this nit quite a bit,…

I tried Bun twice, months apart, it never worked for me on Windows, failing to run "bun install": https://github.com/search?q=repo%3Aoven-sh%2Fbun+bun+install...

Re: Node.js adds experimental support for TypeScript

#269
post #39
post #34

If Node.js can run TypeScript files directly, then the TypeScript compiler won't need to strip types and convert to JavaScript - it could be used solely as a type checker. This would be similar to the situation in Python, where type checkers check types and leave them intact, and the Python interpreter just ignores them. It's interesting, though, that this approach in Python has led to several (4?) different popular…

> In Python, I've even heard of people writing types in source code but never checking them This is my main approach. Type hints are wonderful for keeping code legible/sane without going into full static type enforcement which can become cumbersome for rapid development.

IME if you aren't checking them, they're eventually going to be out of date.

Re: Node.js adds experimental support for TypeScript

#270
post #34

If Node.js can run TypeScript files directly, then the TypeScript compiler won't need to strip types and convert to JavaScript - it could be used solely as a type checker. This would be similar to the situation in Python, where type checkers check types and leave them intact, and the Python interpreter just ignores them. It's interesting, though, that this approach in Python has led to several (4?) different popular…

Flow (by Facebook) used to be fairly significant in the JavaScript several years ago, but right now it's somewhat clear that TypeScript has won rather handily.

Facebook never gave Flow enough resources, whereas Microsoft has had 10+ devs on TypeScript for a long time.
Post reply on HN