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

TypeScript 6.0 RC

devblogs.microsoft.com

Post reply on HN
Print view View original

21–30 of 52 posts

Re: TypeScript 6.0 RC

#21

Post by spankalee »

pscanf wrote: post #3

As a user, I'm of course very excited about v7. As a developer of an app that _integrates_ TypeScript, however, I feel a bit uneasy seeing the API feature still marked as "not ready" on the roadmap. On the other hand, I can understand leaving it as the last thing to do, after the foundation has set. Also, the TypeScript team has really done an amazing job all these years with backward compatibility, so that is extrem…

As a developer that integrates typescript into client-side web pages and writes lots of custom plugins, I'm extremely nervous about the port to Go.

I think the last estimate I saw was the the Go port compiled to WASM was going to be about triple the size of the minified JS bundle.

Re: TypeScript 6.0 RC

#22

Post by littlecranky67 »

mdtrooper wrote: post #12

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…

Typeguard is what you are looking for: function isDog(animal: Dog | Cat): animal is Dog { return "bark" in Dog }

Then: isDog(animal) ? animal.bark() : animal.meow() You get full type narrowing inside conditionals using typeguards.

Re: TypeScript 6.0 RC

#23

Post by spankalee »

tshaddox wrote: post #15
culi wrote: post #2

For anyone who isn't aware, TypeScript does not use semantic versioning. Though TypeScript 7.0 will be significant in that it will use the new Go compiler

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.

Re: TypeScript 6.0 RC

#24

Post by CuriousRose »

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.

Re: TypeScript 6.0 RC

#25

Post by castral »

mdtrooper wrote: post #12

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 can literally do what your generated example does using a type guard. You can also use method overloaded signatures if you dont want to expose your API consumers to union types.

Re: TypeScript 6.0 RC

#26

Post by culi »

mdtrooper wrote: post #12

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

Re: TypeScript 6.0 RC

#27

Post by culi »

littlecranky67 wrote: post #22
mdtrooper wrote: post #12

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…

Typeguard is what you are looking for: function isDog(animal: Dog | Cat): animal is Dog { return "bark" in Dog } Then: isDog(animal) ? animal.bark() : animal.meow() You get full type narrowing inside conditionals using typeguards.

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

Re: TypeScript 6.0 RC

#28

Post by culi »

tshaddox wrote: post #14
mdtrooper wrote: post #12

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…

The idiomatic way to do this in TypeScript is with discriminated unions. You’re basically just giving the type system an extra property that makes it trivial to infer a type guard (while also making the runtime check in the compiled JavaScript foolproof).

This does act exactly as a discriminated union. The code works exactly as written.

Re: TypeScript 6.0 RC

#29

Post by djrenren »

CuriousRose wrote: post #24

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

Re: TypeScript 6.0 RC

#30

Post by littlecranky67 »

culi wrote: post #27
littlecranky67 wrote: post #22

Earlier quoted context omitted.

Typeguard is what you are looking for: function isDog(animal: Dog | Cat): animal is Dog { return "bark" in Dog } Then: isDog(animal) ? animal.bark() : animal.meow() You get full type narrowing inside conditionals using typeguards.

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.
Post reply on HN