Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node.js adds experimental support for TypeScript

github.com

Post reply on HN
Print view View original

241–250 of 570 posts

Re: Node.js adds experimental support for TypeScript

#241

Post by MrBazlow »

BiteCode_dev wrote: post #212

Eventually, node might allow JS to introspect those types. That would be a huge win. Right now in Python, great tools like pydantic exist because Python can introspect said types, and generate checks out of them. This mean you can define simple types, and get: - type checking - run time data check - api generation - api document generation Out of a single, standard notation. Right now in JS, things like zod have to d…

A lot of the focus by the TypeScript team is focused on alignment with the JavaScript language these days and novel new features such as run time types have all but been dismissed or at the very least pushed behind the TC39 JavaScript types proposal. Much like using decorators on variables outside of class structures was.

Having said that, TypeScript allows plugins, these are very rarely used as they augment the language by introducing other features that are transformed into the resulting JavaScript files. One plugin that relates to your suggestion of run time types is called Typia, it permits you to use your TypeScript type signatures at runtime with guards like `assert(myValue)` where it intercepts the function call to construct an exhaustive if statement in the transpiled JavaScript checking the nature of the passed variable.

So while I don't see it being a part of the language in the next four to six years, there are at least libraries out there already that allow you to do it today.

Re: Node.js adds experimental support for TypeScript

#242

Post by madeofpalk »

zarzavat wrote: post #120

One thing to note is that it is impossible to strip types from TypeScript without a grammar of TypeScript. Stripping types is not a token-level operation, and the TypeScript grammar is changing all the time. Consider for example: `foo ( x )`. In TypeScript 1.5 this parsed as (foo (x)) because bar&baz wasn’t a valid type expression yet. When the type intersection operator was added, the parse changed to foo (x) which…

It looks like the team has already considered this in one regard

> There is already a precedent for something that Node.js support, that can be upgraded seperately, its NPM. Node bundles a version of npm that can upgraded separately, we could do the same with our TypeScript transpiler.

> We could create a package that we bundle but that can also be downloaded from NPM, keep a stable version in core, but if TypeScript releases new features that we don't support or breaking changes, or users want to use the new shiny experimental feature, they can upgrade it separately. This ensures that users are not locked, but also provides support for a TypeScript version for the whole 3 years of the lifetime of Node.js release.

https://github.com/nodejs/loaders/issues/217

Re: Node.js adds experimental support for TypeScript

#243

Post by madeofpalk »

dgellow wrote: post #32
spankalee wrote: post #25

Earlier quoted context omitted.

That is "types as comments", not standardizing TypeScript.

It is explicitly not type as comments, it is type erasure

It explicitly is, from the link

> At runtime, a JavaScript engine ignores them, treating the types as comments.

The phrasing here is that the types are meaningless. They are just "comments" to the JS engine.

Re: Node.js adds experimental support for TypeScript

#244

Post by sureIy »

adhamsalama wrote: post #189
murmansk wrote: post #185

Earlier quoted context omitted.

[flagged]

You can write TypeScript types in JSDoc.

You can’t write complex TypeScript types in JSDoc, which is what GP said.

The moment you need to declare or extend a type you’re done, you have to do so in a separate .ts file. It would be possible to do so and import it in JSDoc, but as mentioned before it’s a huge PITA on top of the PITA that writing types can already be (e.g. function/callbacks/generics)

Re: Node.js adds experimental support for TypeScript

#245

Post by rty32 »

dobladov wrote: post #195
murmansk wrote: post #185

Earlier quoted context omitted.

[flagged]

You should write complex types in interfaces files where they belong, and there's full typescript support. I use this approach professionally in teams with many developers, and it works better for us than native TS. Honestly give it a try, I was skeptical at first.

In general JSDoc is just much more verbose and has more friction, even outside complex types. I recently finished a small (20 files/3000 lines), strictly typed JS project using full JSDoc, and I really miss the experience of using the real TypeScript syntax. Pain points: annotating function parameter types (especially anonymous function), intermediate variable type and automatic type-only import, these are the ones that I can remember. Yes you can get 99% there with JSDoc and .d.ts files, but that's painful.

Re: Node.js adds experimental support for TypeScript

#246

Post by rty32 »

mattnewton wrote: post #55
winter_blue wrote: post #35

Earlier quoted context omitted.

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.

Before that there was the closure compiler (Google) which had type annotations in comments. The annotation syntax in comments was a little clunky but overall that project was ahead of it's time. Now I believe even inside google that has been transpiled to typescript (or typescript is being transpiled to closure, I can't remember which - the point is that the typescript interface is what people are using for new code)…

Closure is almost a forgotten child of Google now. Does not even fully support ES2022 as of today. We are working hard to get rid of it completely. Surprise, lots of important projects still rely on it today.

Re: Node.js adds experimental support for TypeScript

#247

Post by WuxiFingerHold »

samtheprogram wrote: post #9

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 like Bun a lot, but Deno is (still) the more mature, stable, capable (e.g. stable workers, http2) and depending on the use-case more performant option (V8 > JSC). DX and tooling is top-notch. Deno can perform typchecking, btw. They bundle the TSC IIRC. Bun is the hype, but Deno is currently clearly the better option for serious endevours. Still, the vision and execution of Bun is impressive. Good for us devs.

Re: Node.js adds experimental support for TypeScript

#248

Post by pas »

IshKebab wrote: post #152
samtheprogram wrote: post #9

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,…

> unprecedented Well except for Deno...

Bun started with compatibility with NodeJS as a primary goal, whereas for Deno it took a while to be able to import npm stuff. (Of course there are fun WTF[0] errors with Bun, and I only tried Deno before the npm import feature landed.)

[0] https://github.com/oven-sh/bun/issues/11420

Re: Node.js adds experimental support for TypeScript

#249

Post by rty32 »

LoganDark wrote: post #57
mattnewton wrote: post #55

Earlier quoted context omitted.

Before that there was the closure compiler (Google) which had type annotations in comments. The annotation syntax in comments was a little clunky but overall that project was ahead of it's time. Now I believe even inside google that has been transpiled to typescript (or typescript is being transpiled to closure, I can't remember which - the point is that the typescript interface is what people are using for new code)…

Oh, Closure Compiler is such a throwback. I still remember staring at the project page on Google Code. Isn't it like two decades old or even older by this point? Is it still alive?

This can give you some hints of the current status of closure compiler:

https://github.com/google/closure-compiler/issues/2731

I happen to know this because we have some old projects that depend on this and are working hard to get rid of the dependency.

I wish Google either updates it or just mark the whole thing deprecated -- the world has already moved on anyway. Relating this to Google's recent cost cutting, and seeing some other Google's open source projects more or less getting abandoned, I have to say that today's Google is definitely not the same company from two decades ago.

Re: Node.js adds experimental support for TypeScript

#250

Post by getcrunk »

zarzavat wrote: post #120

One thing to note is that it is impossible to strip types from TypeScript without a grammar of TypeScript. Stripping types is not a token-level operation, and the TypeScript grammar is changing all the time. Consider for example: `foo ( x )`. In TypeScript 1.5 this parsed as (foo (x)) because bar&baz wasn’t a valid type expression yet. When the type intersection operator was added, the parse changed to foo (x) which…

Do you really need to update all the time? Are the new features always that immediately important?
Post reply on HN