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

461–470 of 570 posts

Re: Node.js adds experimental support for TypeScript

#461

Post by klodolph »

zarzavat wrote: post #298
klodolph wrote: post #292

Earlier quoted context omitted.

I’ll flip this around… reusing comparison as angle brackets is the mistake. C++ ran into some issues too. I think Rust made the really smart move of putting :: before any type parameters for functions. Go made the good move of using square brackets for type parameters.

The problem can be traced back to ASCII/typewriters only including three sets of paired characters, plus inequality signs, which is not enough for programming languages. We really need five sets: grouping, arrays/indexing, records, type parameters, and compound statements. Curly braces {} are also overloaded in JS for records and compound statements, leading to x => {} and x => ({}) meaning different things. Square b…

Five sets, but at any given place in the syntax, not all five are possible. (I would add function calls to the list—so, six.)

In most languages, (grouping and compound statements) cannot syntactically appear in the same place as (indexing, records, type parameters, function calls). So we are immediately down to four.

Rust takes the approach that you use :: before type parameters, so they are easily distinguished from comparison operators at a syntactic level.

Go takes the approach that [] is just fine for type parameters—which seems pretty reasonable to me. In Go, there’s nothing that can be both indexed *and* take a type parameter.

Re: Node.js adds experimental support for TypeScript

#462

Post by crabmusket »

thr0w wrote: post #431
WorldMaker wrote: post #392

Earlier quoted context omitted.

Why are you still transpiling to .cjs in 2024? ESM is supported in every LTS version of Node now. We can kill CJS, we have the power.

> ESM is supported in every LTS version of Node now. We can kill CJS, we have the power. I'd rather kill ESM. And it's not fully supported in Node. It doesn't work in the REPL.

You can have a chat to all major browser vendors about killing ESM :)

Re: Node.js adds experimental support for TypeScript

#463

Post by fabiospampinato »

recursive wrote: post #453
pansa2 wrote: post #369

Earlier quoted context omitted.

Here's an example of TypeScript failing to be sound - it should give a type error but it doesn't. I believe Flow does indeed give a type error in this situation: https://news.ycombinator.com/item?id=41069695

You don't have to go even that far to find unsoundness in flow. const arr = ["abcd"]; const str = arr[1]; const num = str.length; // this throws console.log(num); For me, typescript is a pretty good balance.

Wait, so Flow is not actually sound and their website is lying? Or do they have some "technically correct" definition of "sound" that takes stuff like that into account?

Re: Node.js adds experimental support for TypeScript

#464

Post by dimgl »

silverwind wrote: post #220
yamumsahoe wrote: post #15

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.

We have not seen this whatsoever. How big is your project? `tsx` is almost instantaneous in a server-side project of ours.

Re: Node.js adds experimental support for TypeScript

#465

Post by meowtimemania »

Omerd6 wrote: post #442
unilynx wrote: post #370

If this feature ever becomes the default (ie not behind a flag) - how will the NPM ecosystem respond? Will contributors still bother to build CJS end EJS versions when publishing a NPM module, or just slap an 'engine: nodejs >= 25' on the package.json and stop bothering with the build step before pushing to NPM ? I personally would very much prefer if NPM modules that have their original code in TS and are currently…

The legendary Ryan dahl is actually working on solving the exact problem you described by creating a new package registry called JSR. Essentially what it does is allow you to upload your typescript code without a build step so when other devs install it they can see the source code of the module in it's original typescript instead of transpiled JavaScript.

it must install compiled and uncompiled versions? Otherwise node (without the above flag) would throw errors when it encounters types in node_modules

Re: Node.js adds experimental support for TypeScript

#466

Post by recursive »

fabiospampinato wrote: post #463
recursive wrote: post #453

Earlier quoted context omitted.

You don't have to go even that far to find unsoundness in flow. const arr = ["abcd"]; const str = arr[1]; const num = str.length; // this throws console.log(num); For me, typescript is a pretty good balance.

Wait, so Flow is not actually sound and their website is lying? Or do they have some "technically correct" definition of "sound" that takes stuff like that into account?

I have no idea about the lawyerly technicalities, but you can try it yourself to verify what I'm saying.

https://flow.org/try/

Compare these two programs.

    const arr = ["abcd"];
    const str = arr[1];
    const num = str.length; // this throws at runtime

    const arr = [new Date];
    const dt = arr[1];
    const num = dt.length; // fails to type check

Re: Node.js adds experimental support for TypeScript

#467

Post by nikeee »

jimvdv wrote: post #94
iansinnott wrote: post #73

Earlier quoted context omitted.

Seconded again. While tsx usually just works ts-node almost never just works. tsx is perhaps unfortunately named though so it may confuse people at first since it has nothing to do with jsx syntax.

Thank you for bringing this up, I almost ignored this project since I assumed it had something to do with TypeScript + JSX. The JS ecosystem sure struggles with naming things.

I own the npm package node-ts, which has thousands of installs per week just because people confuse it with ts-node.

I didn't intend to typo-squat. Actually, my package is older than ts-node and was just a pun because it is an API for TeamSpeak written in TypeScript.

Re: Node.js adds experimental support for TypeScript

#468

Post by Timon3 »

WorldMaker wrote: post #449
Timon3 wrote: post #425

Earlier quoted context omitted.

I don't know a lot about parser theory, and would love to learn more about ways to make parsing resilient in cases like this one. Simple cases like "ignore rest of line" make sense to me, but I'm unsure about "adversarial" examples (in the sense that they are meant to beat simple heuristics). Would you mind explaining how e.g. your `as` stripping could work for one specific adversarial example? function foo () { retu…

Most parsers don't actually work with "lines" as a unit, those are for user-formatting. Generally the sort of building blocks you are looking for are more along the lines of "until end of expression" or "until end of statement". What defines an "expression" or a "statement" can be very complex depending on the parser and the language you are trying to parse. In JS, because it is a fun example, "end of statement" is d…

Thanks for the response, but I'm aware of the basics. My question is pointed towards making language parsers resilient towards separately-evolving standards. How would you build a JS parser so that it correctly parses any new TS syntax, without changing behavior of valid code?

The example snippet I added is designed to violate the rules I could come up with. I'd specifically like to know: what are better rules to solve this specific case?

Re: Node.js adds experimental support for TypeScript

#469

Post by Omerd6 »

meowtimemania wrote: post #465
Omerd6 wrote: post #442

Earlier quoted context omitted.

The legendary Ryan dahl is actually working on solving the exact problem you described by creating a new package registry called JSR. Essentially what it does is allow you to upload your typescript code without a build step so when other devs install it they can see the source code of the module in it's original typescript instead of transpiled JavaScript.

it must install compiled and uncompiled versions? Otherwise node (without the above flag) would throw errors when it encounters types in node_modules

I just checked and you are correct, in node it only installs the compiled version.

Apparently you can only view the uncompiled source code in deno since it natively supports typescript.

My bad

Re: Node.js adds experimental support for TypeScript

#470

Post by madeofpalk »

SomeCallMeTim wrote: post #384
madeofpalk wrote: post #242

Earlier quoted context omitted.

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…

As long as Node understands to use the project-specific version of TypeScript (i.e., the one in node_modules or the PNP equivalent), that should be fine. But it would be a step backward to need to globally upgrade TypeScript (as you do with npm), since some older projects will not be compatible with newer versions of TypeScript. Ask me how I know. ;)

I think Node’s strategy here is to not let perfect be the enemy of useful for some people.
Post reply on HN