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

401–410 of 570 posts

Re: Node.js adds experimental support for TypeScript

#401

Post by parasense »

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…

Paired characters...

That's an interesting topic. Do you happen to know if UTF-8 contains more "pair" characters? In Latex we call these delimiteres, but that's just my limited experience coming in from math side. I tend to agree that it would be helpful to have more kind of nesting/pairing/grouping/delimiting characters. The problem is my imagination is limited to what I know from the ASCII world, and so it goes... no idea what new sets would look like.

Re: Node.js adds experimental support for TypeScript

#402

Post by felixfbecker »

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.

This is true, but in other cases they added keywords in ways that could work with type stripping. For example, the `as` keyword for casts has existed for a long time, and type stripping could strip everything after the `as` keyword with a minimal grammar.

When TypeScript added const declarations, they added it as `as const` so a type stripping could have still worked depending on how loosely it is implemented.

I think there is a world where type stripping exists (which the TS team has been in favor of) and the TS team might consider how it affects type stripping in future language design. For example, the `satisfies` keyword could have also been added by piggy-backing on the `as` keyword, like:

    const foo = { bar: 1 } as subtype of Foo
(I think not using `as` is a better fit semantically but this could be a trade-off to make for better type stripping backwards compatibility)

Re: Node.js adds experimental support for TypeScript

#403

Post by felixfbecker »

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…

I think the kind of teams that always stay on top of the latest TypeScript version and use the latest language features are also more likely to always stay on top of the latest Node versions. In my experience TypeScript upgrades actually more often need migrations/fixes for new errors than Node upgrades. Teams that don't care about latest V8 and Node features and always stay on LTS probably also care less about the latest and greatest TypeScript features.

Re: Node.js adds experimental support for TypeScript

#404

Post by nyssos »

lolinder wrote: post #306
nyssos wrote: post #301

Earlier quoted context omitted.

There's not much connection. Typescript's record types aren't sound, but that's far from its only source of unsoundness, and sound structural typing is perfectly possible.

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…

> Do you have an anecdote (just one!) of a case where TypeScript's lack of type system soundness bit you on a real application?

Sure. The usual Java-style variance nonsense is probably the most common source, but I see you're not bothered by that, so the next worst thing is likely object spreading. Here's an anonymized version of something that cropped up in code review earlier this week:

    const incomingValue: { name: string, updatedAt: number } = { name: "foo", updatedAt: 0 }

    const intermediateValueWithPoorlyChosenSignature: { name: string } = incomingValue

    const outgoingValue: { name: string, updatedAt: string } = { updatedAt: new Date().toISOString() , ...intermediateValueWithPoorlyChosenSignature }

Re: Node.js adds experimental support for TypeScript

#405

Post by silverwind »

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. ;)

> As long as Node understands to use the project-specific version of TypeScript

It won't, but in such a scenario, typescript would only be a type checker, wich is a entirely different endeavor than running typescript.

Re: Node.js adds experimental support for TypeScript

#407

Post by nfriedly »

WorldMaker wrote: post #392
nfriedly wrote: post #380

Earlier quoted context omitted.

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.

Because I don't like breaking things unnecessarily. Some of my libraries are 10 years old and depended upon by similarly old projects that are not using ESM and probably never will.

Besides, it's already going through one transpilation step to go from TS to ESM, so adding a second one for CJS really isn't that much hassle.

I think if node.js had made require() work with ESM, I could probably drop CJS. But since that's probably never going to happen, I'm just going to continue shipping both versions for old projects and not worry about it.

Re: Node.js adds experimental support for TypeScript

#408

Post by simlevesque »

leipert wrote: post #72
spankalee wrote: post #30

Earlier quoted context omitted.

Extensions should be required. It's not possible to do path searches over the network like you can on local disk, and network-attached VMs, like browsers, are a very, very important runtime for JavaScript.

Also performance. foo could mean foo/index.js, foo.js at the minimum. So you have 2x the lookups. Oh no, wait we also potentially have mjs, cjs, jsx, ts and tsx. So 12 times the stat checking for each import.

> foo could mean foo/index.js, foo.js at the minimum. So you have 2x the lookups.

Only in the worst case. If it's foo.js there's only one lookup.

> Oh no, wait we also potentially have mjs, cjs, jsx, ts and tsx. So 12 times the stat checking for each import.

Again, you're only taking into account the worst case.

Re: Node.js adds experimental support for TypeScript

#409

Post by silverwind »

pansa2 wrote: post #366
65n56nm5665m56 wrote: post #335

I beg of thee, do not do this. I get that people love typescript but I am already running into a problem where javascript resources are written in typescript by default with nothing for regular javascript. This is the same problem that happened when JQuery hit its peak popularity and an overwhelming amount of resources and guides amounted to "Oh just do this in JQuery"

> javascript resources are written in typescript by default with nothing for regular javascript. This is the same problem that happened when JQuery hit its peak popularity That's definitely a potential issue - JavaScript is the fundamental standard, not JQuery and not TypeScript. Certainly there are situations where maximum forward-compatibility is important (learning resources are a good example) and for those, vani…

> the contemporary ones that used plain JavaScript are as valid now as when they were written.

True, but on the other hand, almost any JS code snippet written 20 years ago has better and more elegant alternatives today. APIs evolve all the time.

Re: Node.js adds experimental support for TypeScript

#410

Post by nequo »

afiori wrote: post #130
tpm wrote: post #119

Earlier quoted context omitted.

That's just an copy-paste of some features, not a comparison with Java which does most of that too.

Union types, structural typing, and conditional types are like a big chunck of what makes typescript typescript. It is how TS is able to "type" a completely untyped language. Just the support for union types is something that not even Haskell or Ocaml have.

I am not familiar with TypeScript. Is there something that you can achieve with union types that you can’t with sum types or type classes in Haskell?
Post reply on HN