Running TypeScript Natively in Node.js | Hacker News Reader

Running TypeScript Natively in Node.js

nodejs.org

59 pointsjauco34 comments

Whilst I use an esbuild based build pipeline to produce production artifacts, I've found that the combination of native type transformation and node:test improvements is now sufficient to do away with most test frameworks.

My nodejs projects have tests that run faster and have fewer breaking dependencies.

The two things I have to do are to always annotate type imports with type (I have a script for that), and to use file extensions on imports.

There's an ESLint rule with autofixes for that (annotating type imports) One for extension should exist somewhere too

This is great to finally see get added. I wonder why they decided to build their own type stripper instead of just bundling tsc/swc. It feels like Node.js is going to be plagued with bugs whenever TypeScript adds new type constructs, which may take months to get patched.

Would it be possible for the maintainers of Typescript to provide an official stripper that could be deployed alongside new versions of Typescript, and then snapped in?

I'm not certain but I would be surprised if the TS and Node devs didn't discuss the functionality that's in Node now, since TS must have some definition of what an erasable type is (or rather, what few features aren't erasable, like enums), since the corresponding --erasableSyntaxOnly flag in TS was probably made specifically because of Node.

Its just stripping types, so new constructs should not matter - there is no parsing.

It uses swc under the hood.

I don't mean this rhetorically, but what are the benefits of using node over something like deno now? It has been so long since I lived in the node ecosystem. I imagine it has gotten quite a bit better. Is the main benefit just ecosystem/compatibility stuff? Deno sometimes has some odd compatibility issues, but not often. The low-overhead, sane defaults, just-build kind of nature of it has become very appealing to me. Being able to build CLIs in portable binaries using a language my coworkers understand is really nice (despite that they're like 60mb, haha). I prefer Go personally, but ultimately prefer being able to collaborate.

It’s purely ecosystem at this point. Deno, Bun, any runtime is more modern. It’s nice they are catching up but by the time typescript is a native citizen in node, others may take the crown. The codebase is ooof.

That said, there’s something to be said about being the first mover and having the ecosystem so node isn’t going away anytime soon, nor is the npm/npx ecosystem.

Go has the ability to, with a goja fork [1], to execute ESM but you would still need to transpile using another go tool to run it. I have such a runtime but it’s nowhere near as fast as bun or deno. I use it mainly so I can have agents do my local bidding.

[1] https://github.com/grafana/sobek

>It’s purely ecosystem at this point.

Definitely not just about ecosystem.

When AWS Lambda supports Deno, then maybe someday further down the line, I might think about trying it once for something unimportant. If that goes well, then we'll see.

AWS Lambda supports custom runtimes so you can roll your own. All you need is a container.

https://gist.github.com/begoon/993e29f5cf9a384b9e0e96e70a71b...

But for ts/js land, lambda is node unless you want to build your own containers.

> All you need is a container.

That isn't the same as AWS Lambda supporting Deno, and you should know it. No, I don't want the extra hassle of containers.

Lambda’s being pulled from storage or containers being pulled from ECR is negligible. The difference here is in the container layers. If you build a small container with alpine it’s not that bad.

Not to try to convince otherwise. Just that it isn’t as bad as it used to be. Our Golang lambdas have 2ms more startup time than our JavaScript lambdas.

Lambda is just a fancy CGI-BIN

Maybe you didn't understand when I said "I do not want the extra hassle of containers". I don't care about start-up time, I don't care that it "isn't as bad as it used to be". I just do not want to have to create or maintain a "container" myself. That's why I chose Lambda to begin with. It's a FaaS, and that's where it ends for me.

Use Deno compile to create a standalone executable and launch on provided.al2023 like you would a rust binary

Except nodejs is working perfectly for me, and I do not want all those extra hoops to jump through.

It's funny, I would actually argue the opposite point. When Deno and Bun first came out, they promised a hard break from the Node ecosystem, like how Deno leaned heavily into browser compatibility, and Bun into framework features like Bun.App.

At some point they both decided that Node compatibility was more important than their unique features, but in the time since their release Node got type stripping, require(esm), sqlite, single executable apps, a permission system, a test runner, and basically ever other Deno/Bun feature they could port over.

So at this point why use runtimes that imitate Node when you could just use Node? You'll get most of the modern niceties, but also get 100% compatibility with the existing ecosystem.

It sounds like Bun and Deno might have been a huge success! Could have had the effect of lighting a fire under node to innovate

> When Deno and Bun first came out, they promised a hard break from the Node ecosystem

I don't think that's true for Bun. In fact Bun was planned to NOT break from Node ecosystem as much as possible:

"Bun is designed as a drop-in replacement for your current JavaScript & TypeScript apps or scripts — on your local computer, server or on the edge. Bun natively implements hundreds of Node.js and Web APIs, including ~90% of Node-API functions (native modules), fs, path, Buffer and more." - 2022

https://archive.is/lWjNn#selection-399.0-403.55

So if you use this, what do you use to enforce the types? Are you still running tsc --noEmit?

I'm embarking on a project where the various tsconfig files are getting quite unwieldy. I'd have already jumped to Deno but it just won't work right when the actual deployment is to Cloudflare Workers.

See also from 6 months ago https://news.ycombinator.com/item?id=42630790

Does this mean we can finally drop `typescript` dependency from build chain?

Wake me up when it gets as good as running tsx aka support for path aliases in dev and test environments and support for watch mode

News from January https://nodejs.org/en/blog/release/v23.6.0

I honestly wish Microsoft and TypeScript enthusiasts would transform it into an official standalone language and stop polluting the JavaScript ecosystem.

Like C++, it could be a true superset of JS, importing JS code freely into TypeScript projects. It would also allow TypeScript to do whatever it wanted and not have to worry about transpilation. If it needs to work in the browser, it can be bundled into web assembly.

This is a mischaracterization of TypeScript. Unlike the relationship of C++ to C, TS is explicitly not a separate language from JS, and introduces no new capabilities. There’s no engine that executes TypeScript. It doesn’t do anything (*) that JavaScript doesn’t do. It just layers a type system onto JavaScript so you can tell when your JS code doesn’t make sense.

(*) with small exceptions like enums, which some think were a mistake for that reason

Yeah but it could be, as the runtime could take advantage of the type defs.

So much of the TS type system is just there to capture all the weird things you can do in JS. If you just wanted a new strongly typed dynamic language, I don't think TS is what you'd come up with. It is designed for a very large, but unique, niche domain, and that domain already has some incredibly optimized runtimes.

I wouldn't come up with a new language. I would use TS and use the types to optimize runtime decisions like using numbers to index arrays, without having to carry extra info about the number, and so on. I would change nothing except the runtime. Are you somehow arguing that's bad?

TS complains if it sees you trying to index a T[] with a non-integer. But there's nothing in the JS language that represents that T[] type annotation. So there's no way for the runtime to do that check. If you want to make that work, you'll have to invent a bunch of runtime type machinery and define it. The resulting combination of a subset of JS, TS, and whatever you had to invent to glue it together at runtime will be neither JS nor TS, it will be a new language (with, certainly, a family history).

Also, every high-performance JS runtime already knows that you're only indexing that object with integers and already optimizes it without you telling it to.

C++ isn't a superset of JS, nor is it a superset of C

How does it pollute? Hasn't the presence of TypeScript pushed a lot of awesome features back into the later versions of JavaScript?

As far as I know, this still amounts to zero. It got many features from coffeescript

There is no pollution. Typescript is a strict super set. I always joke that Typescript is JavaScript code mixed with compiler instructions. The type annotations are not code.

Reply on news.ycombinator.com