Live data from Hacker News

TypeScript 6.0 RC

devblogs.microsoft.com

31–40 of 52 posts

Re: TypeScript 6.0 RC

#31

What has always bothered me about TypeScript are union types. If you have a function that receives a parameter such as ‘Dog | Cat’, you cannot separate it. For example: type Dog = { bark: () => void } type Cat = { meow: () => void } function speak(animal: Dog | Cat) { if (‘bark’ in animal) { animal.bark(); } else { animal.meow(); } } Okay, okay, I know you can filter using ‘in’ to see if it has methods, but in real l…

You're looking for a discriminated union [1], which idiomatically:

  type Dog = { bark(): void; type: 'dog' }

  type Cat = { meow(): void; type: 'cat' }

  function speak(animal: Dog | Cat) {
    if (animal.type === 'dog') {
      animal.bark()
    } else {
      animal.meow()
    }
  }
Generally speaking, TypeScript does not add runtime features.

TypeScript checks your use of JavaScript runtime features.

[1] https://www.convex.dev/typescript/advanced/type-operators-ma...

Re: TypeScript 6.0 RC

#32
post #27

Earlier quoted context omitted.

You don't even need that. The code exactly as presented acts as a discriminator. TypeScript is smart enough to handle that logic in the if block and know whether animal has been validated as Dog vs Cat. GP is complaining about a feature that already exists in TypeScript

It depends how you construct Dog and Cat. With Javascripts dynamic prototype chain, you could never know for sure.

Try it

https://www.typescriptlang.org/play/?#code/C4TwDgpgBAIg9gcyg...

Re: TypeScript 6.0 RC

#34

I am hoping that eventually there will be some agnosticism with the language server. Currently they all seem to rely on Node which in my opinion is rapidly being outclassed by Bun in terms of resource usage. It would be great to eventually be able to pick what runtime they use in VS Code/Cursor to reduce energy drain on my laptop when working on the go.

The typescript language server (along with the rest of the compiler) is being rewritten in go for Typescript 7. This work has been going on in parallel with the work on 6.0. The go port has most features of 6.0 already and you can follow its progress and read more about it here: https://github.com/microsoft/typescript-go

Sure, but instead of waiting another year for this to be launched - with a beta version precaution and inevitable bugs - why not remove the limited hard-coded Node paths and references now and ship something 80:20?

Re: TypeScript 6.0 RC

#35

Earlier quoted context omitted.

The typescript language server (along with the rest of the compiler) is being rewritten in go for Typescript 7. This work has been going on in parallel with the work on 6.0. The go port has most features of 6.0 already and you can follow its progress and read more about it here: https://github.com/microsoft/typescript-go

Sure, but instead of waiting another year for this to be launched - with a beta version precaution and inevitable bugs - why not remove the limited hard-coded Node paths and references now and ship something 80:20?

If it’s a simple change, they might accept a PR. If it isn’t, well that’s your answer. Not worth allocating engineers for it.

Re: TypeScript 6.0 RC

#36
post #32

Earlier quoted context omitted.

It depends how you construct Dog and Cat. With Javascripts dynamic prototype chain, you could never know for sure.

Try it https://www.typescriptlang.org/play/?#code/C4TwDgpgBAIg9gcyg...

type Mutt = Dog & Cat

const imposter: Mutt = { bark: () => console.log("woof"), meow: () => console.log("meow"), }

You're both misunderstanding parent's point as well as the original point. Nobody ever claimed your link wouldn't compile.

Re: TypeScript 6.0 RC

#37

Earlier quoted context omitted.

Semantic versioning seems slightly weird to even apply to something like TypeScript. You could have patch releases that fix actual compiler crashes, sure, but what is a minor release? Surely any new feature that causes code to fail to type check when it previously would pass (or vice versa) would have to be considered a breaking change. A similar thing applies to code formatting tools like Prettier, or any linter.

Semantic versions would at least be playing nice with how npm manages version ranges. If every release of TypeScript is breaking, then you should use major versions so that `npm update` doesn't break your project. Yes, typescript would be at version 60 now. No, that's not a problem at all. Numbers are free.

> Numbers are free.

Someone please tell the LLM naming committee.

Re: TypeScript 6.0 RC

#38

My deepest thanks to one @AlCalzone for stepping up to Opus port Decorators to tsgo. https://github.com/microsoft/typescript-go/pull/2926 It would have been an affront to have a 6.0 that shipped without the means to work for so so many javascript frameworks/libraries. AlCalzone utterly saving the day. I also am so so so thankful that maybe perhaps after what felt like a never ending dolldrums, we may finally be getti…

> Disclaimer: This is an entire day worth of Claude Opus tokens. I don't claim I understand how it works, but I did my best to direct Claude to minimize the baseline diffs, of which it removed quite a few.

TypeScript allows entirely LLM-coded PRs?

Re: TypeScript 6.0 RC

#40
post #26

What has always bothered me about TypeScript are union types. If you have a function that receives a parameter such as ‘Dog | Cat’, you cannot separate it. For example: type Dog = { bark: () => void } type Cat = { meow: () => void } function speak(animal: Dog | Cat) { if (‘bark’ in animal) { animal.bark(); } else { animal.meow(); } } Okay, okay, I know you can filter using ‘in’ to see if it has methods, but in real l…

Your first code block works exactly as you would expect and has been working like that for many years https://www.typescriptlang.org/play/?#code/C4TwDgpgBAIg9gcyg...

The op did say they didn't want to do these type of checks.

I thought the answer was 'instanceof'?

https://www.typescriptlang.org/docs/handbook/2/narrowing.htm...

Post reply on HN