TypeScript type checker

[kdy1]

Closing as the stc is now abandoned. TypeScript was not something that I could follow up on in an alternative language.

[dsherret]

I'm just looking at this: https://github.com/kdy1/swc/tree/e88e5e4c824926e5f3a5240986c33bb30f7508b5/typescript/checker

Won't re-writing the TS type checker in rust be a lot of work? There's so many edge cases! Why not just do what babel does and tell people to run the typescript type checker over the code with emitting? Alternatively, you could build something into the swc JS package that uses the typescript compiler api to do this as well.

[dsherret]

What might be neat is something that converts swc AST nodes to TypeScript compiler api nodes. So you could parse the nodes with swc, send them over to JS, convert them to typescript compiler api nodes, then it could do the type checking using those nodes.

[kdy1]

@dsherret I'm porting tsc because it is wall-clock grade slow.

[dsherret]

True, it could be faster, but there's a whole team of developers working on TypeScript daily. It will be very hard to get all the edge cases, but perhaps you could repurpose the tests the typescript team uses in the typescript repo.

Anyway, you have a long and continually expanding road ahead of you :)

[kdy1]

I'm already using tests from typescript repository :)
I know that it's a very hard task, but it's fun for me.

[dsherret]

That’s awesome. Well, you’ve done an excellent job with the library and you’re very fast at programming so good luck! 😀

[IronSean]

The other approach you can use with babel is do just do compilation, and run the type checker without emitting in a separate thread so even if it's slower, your build still finishes fast. That might currently work with swc? But the idea of a much faster type checker is also very exciting!

[kyegupov]

@kdy1 what's the current status? What's the most up-to-date branch in your fork? I have a feeling you won't be able to pull this alone. Maybe we can create a plan to "move Mount Fuji" and get more people involved?

[nayeemrmn]

https://deno.land/v1#tsc-bottleneck

[trivikr]

FYI: TypeScript team doesn't have any plan to port TSC to Rust for reasons explained in tweet thread https://twitter.com/drosenwasser/status/1260722414012358657

[wongjiahau]

We need to recruit a few developers to achieve this.

[sciepsilon]

I'm interested! I don't know if I'm up to the task, but I'll at least spend the next couple days exploring the code and getting up to speed.

We need to recruit a few developers to achieve this.

[littledivy]

@sciepsilon I've formed a little team together with @wongjiahau to help @kdy1 work on this.

Fell free to email!

[cakekindel]

Hi! 👋 I'm also very interested in helping with a rust port of TSC 😄, is this project public?

[wongjiahau]

@cakekindel Hi if you're interested you can join us at https://discord.gg/s8meYPV

[wongjiahau]

Sorry the link above was temporary, I just update it with a permanent one.

[mdbetancourt]

The other approach you can use with babel is do just do compilation, and run the type checker without emitting in a separate thread so even if it's slower, your build still finishes fast. That might currently work with swc? But the idea of a much faster type checker is also very exciting!

i think this idea isn't really useful for check type errors (we can do it with the IDE, may be to speed up vscode) but is very cool for lib which depend on typechecks (metadata desing:type), for example in loopback there is 3 different results depending on what you use
ts-node with typecheck: it's okay (Function)

ts-node with transpile-only: error (Object)

swc: error (undefined)

Sample repo: https://github.com/mdbetancourt/ts-node-loopback you can try changing .mocharc ts-node/register to @swc-node/register

[goloveychuk]

@kdy1 are you sure you will have better performance by porting to go?
The theory here - because 90% of type checking is conditions checks, nodejs (after warming, classes compilations and optimisations) could be as much fast as go.
Maybe it make sense to explore multithreading instead.

[kdy1]

Yep. The main problem is the number of cpu cores it uses.

Problem is not optimization

[goloveychuk]

So by porting you mean making it multithreaded too (using coroutines, channels, etc)?

[kdy1]

Of course. What's the point of porting to go at the first place if we are going to use only 1 core?
If go is single-threaded or javascript was multi-threaded, I wouldn't start it. If then, contributing to tsc is the correct way.

[chentsulin]

This discussion about multi-threaded compilation might be relevant: microsoft/TypeScript#30235

[willstott101]

Just to join the dots for anyone unaware, there's a public repo where work on stc kdy1's typescript type checker written in rust is taking place:

https://github.com/dudykr/stc

[kdy1]

Closing as the stc is now abandoned. TypeScript was not something that I could follow up on in an alternative language.

[Kingwl]

Sorry to hear that, but respect you for your contributions and efforts here!

[swc-bot]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.