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

391–400 of 570 posts

Re: Node.js adds experimental support for TypeScript

#391

Post by svieira »

tpm wrote: post #283
yen223 wrote: post #160

Earlier quoted context omitted.

Java and Typescript have fundamentally different type systems, that lead to drastically different ways to approach types. Utility types, like Partial , are basically impossible to represent in Java except with almost-duplicated classes.

> drastically different ways to approach types Exactly. > Partial Looking at that it's just what a default POJO (with nullable properties) already is, so I'd see no need to represent that in Java. Looks cool though and I like Typescript; my issue with it is that it needs transpiling to run. If it was a first-class citizen in an environment I would use it for my pet projects.

Yep - all non-primitive types in Java are `TheType | null` - TypeScript actually allows you to strip out the `| null`, which then means that sometimes you want to add it back in. So Java doesn't have a need for `Partial`, it has a need for `NonNull` and it can't express that at the type system level very easily right now (you can do it with type tagging and runtime checks inserted explicitly, but it's not very ergonomic right now)

https://gist.github.com/svieira/9f8beeafb7bf4aa55d40c638532f...

Re: Node.js adds experimental support for TypeScript

#392

Post by WorldMaker »

nfriedly wrote: post #380
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…

For the old libraries I maintain that are typescript and transpiled into .cjs and .mjs for npm, I'll probably just start shipping all three versions. For a new thing I was writing from scratch, yeah, I might just ship typescript and not bother transpiling. [edit: Apparently not. TS is only for top-level things, not libraries in node_modules according to the sibling comment from satanacchio who I believe is the author…

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.

Re: Node.js adds experimental support for TypeScript

#393

Post by lolinder »

kcrwfrd_ wrote: post #379
lolinder wrote: post #306

Earlier quoted context omitted.

Soundness is also a highly theoretical issue that I've never once heard a professional TypeScript developer express concern about and have never once heard a single anecdote of it being an issue in real-world code that wasn't specifically designed to show the unsoundness. It usually only comes up among PL people (who I count myself among) who are extremely into the theory but not regularly coding in the language. Do…

Ah someone else posted a link and I understand the unsoundness now. The only time an issue ever came up for me was in dealing with arrays let foo: number[] = [0, 1, 2] // typed as number but it’s really undefined let bar = foo[3] But once you’re aware of the caveat it’s something you can deal with, and it certainly doesn’t negate the many massive benefits that TS confers over vanilla JS.

Yeah, that example is unsound in the same way that Java's type system is unsound, it's a compromise nearly all languages make to avoid forcing you to add checks when you know what you're doing. That's not the kind of problem that people usually are referring to when they single out TypeScript.

Re: Node.js adds experimental support for TypeScript

#394

Post by umvi »

andrewmcwatters wrote: post #374
umvi wrote: post #320

Side note, but IMO Typescript is too complicated. They should have stuck to a reasonably simple type system but now I see projects with incomprehensible and frankly unmaintainable typescript consisting of extremely complex generics, type conditionals, and type constraints. Basically if you aren't careful you'll find your project metaprogramming in typescript's turing complete meta language...

TypeScript in its current usage reminds me of Hello, World! or FizzBuzz Enterprise Edition. There's almost more code dedicated to typing than the actual running software itself in some codebases I've seen. The authors trick you with reasonable examples on https://www.typescriptlang.org , but in the wild, you have these ridiculous codebases that couldn't control themselves and they have this insane ratio of multiple d…

To be clear, I do like the type-checking benefits of TypeScript, but it requires some discipline to keep it simple. Get one unchecked TS astronaut on the team and the TypeScript can get complex and esoteric very quickly.

Re: Node.js adds experimental support for TypeScript

#395

Post by tills13 »

iansinnott wrote: post #73
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

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.

It's named as such to mirror `npx`

Re: Node.js adds experimental support for TypeScript

#396

Post by zzo38computer »

sholladay wrote: post #349
johnny22 wrote: post #91

Earlier quoted context omitted.

the url imports is one the things I don't want.

You want to be forced to use a centralized registry? I don’t know. URL imports also enable fully isomorphic modules. I think you would enjoy the freedom of URL imports if the ergonomics were better. For example, it should just default to https:// so you don’t have to type that. Import maps also help a lot with this, definitely use them. But they could be even better by having first-class support for templating the mo…

I disagree. It should not default to "https://" (I think defaulting to local files would be better).

Furthermore, I think that it should be made so that the "hashed:" scheme that I had invented (in the Scorpion protocol/file-format specification document, although this scheme can be used independently of that) can also be usable.

And, popular hosts with well-known URL structures automatically templating also I would disagree, although it might do to allow any expressions in place of the string literals and then add functions for abbreviations of some of those URLs, if that would help (although I still think it is unnecessary).

Re: Node.js adds experimental support for TypeScript

#397

Post by vips7L »

SomeCallMeTim wrote: post #388
nialv7 wrote: post #287

Earlier quoted context omitted.

Using inequality signs as angled brackets really is a mistake isn't it...

It's not a TypeScript mistake. You could argue that it was a C++ mistake. It makes parsing harder, but otherwise seems to work as expected, so I don't consider it a mistake, but you could at least argue that way. But regardless if it was a mistake in C++, it's now a complete standard, used in C++, Java, C#, and other languages to denote type parameters. I would argue that it would have been a mistake to break that st…

It's definitely the right choice for Typescript. You could have gone the Scala route and used [] for generics, but that is so heavily used in ts/js as arrays it would not have made any sense.

Re: Node.js adds experimental support for TypeScript

#398

Post by DexesTTP »

ahuth wrote: post #338
hajile wrote: post #322

Earlier quoted context omitted.

If JS ever adds type checking, I hope it doesn't choose Typescript. We need a type system that is actually sound and TS is intentionally unsound. We need a type system that doesn't allow bad coding practices like TS does. We need a type system that enforces program design that allows programs to be fast. We need a Hindley Milner type system. If you want a module to be typed, add a `"use type"`. This should disallow b…

What bad coding practices does TS allow, and why are they bad?

TS allows you to pass a read-only object to a method taking a read-write value:

    type A = { value: number; }
    function test(a: A) { a.value = 3; }
    function main() {
      const a: Readonly = { value: 1 };
      // a.value = 2;

Re: Node.js adds experimental support for TypeScript

#399

Post by tln »

hajile wrote: post #363
ahuth wrote: post #338

Earlier quoted context omitted.

What bad coding practices does TS allow, and why are they bad?

If there's a bad way to write JS, TS has something available to make sure it's typed. Does TS help you keep your functions monomorphic so they'll get optimized by the JIT? nope Does TS keep your object shape from changing so it will get optimized by the JIT? it actively does the opposite giving TONS of tools that allow you to add, remove, modify, and otherwise mess up your objects and guarantee your code will never o…

> Does TS keep your object shape from changing so it will get optimized by the JIT? it actively does the opposite giving TONS of tools that allow you to add, remove, modify, and otherwise mess up your objects and guarantee your code will never optimize beyond the basic bytecode (making it one or two orders of magnitude more slow than it could otherwise be).

Can you elaborate or point to some of the tools? So I know what tools I may need to avoid

Re: Node.js adds experimental support for TypeScript

#400

Post by panzi »

teaearlgraycold wrote: post #377
WorldMaker wrote: post #342

Earlier quoted context omitted.

The syntax from the perspective of type stripping has been relatively stable for more versions of Typescript than it was unstable. You had to reach all the way back to 1.5 in part because it's been very stable since about 2.x. The last major shift in syntax was probably Conditional Types in 2.8 adding the ternary if operator in type positions. (The type model if you were to try to typecheck rather than just type-stri…

They did just add a new keyword, satisfies, in 5.4. That would be a breaking change if you can’t upgrade the type stripper separately.

But at least its a loud failure and not a silent different interpretation of the source as the example was. Still.
Post reply on HN