TypeScript is migrating to Go

[AlCalzone]

https://devblogs.microsoft.com/typescript/typescript-native-port/

Still a long way out but I have to wonder what that will mean for ts-patch.

[samchon]

Let's meet again in the Go-lang TypeScript ecosystem.

[nonara]

Just kidding!

I had a chance to watch the interview with Anders Hejlsberg about the endeavour and the current progress — thanks @dimitropoulos for hosting and asking great questions!

First off, I'd like to say that I'm excited about the new port, and I think that overall (as usual) the reasoning behind the decision is sound and they obviously deeply considered all of the angles.

There are two sides to this I'll touch on quickly. The first is the future of ts-patch, with planned new features, and the second will cover the existing features.

Future Features

For some time, I've had a revision to ts-patch planned out with some very exciting new expansions, which would effectively allow you to add features to the language and extend the LS via pluggable modules.

This upcoming shift will definitely change the approaches taken to achieve that significantly. However, I think it also simplifies the complexity a bit, which is a good thing.

If we move forward, what I'd probably do here is find specific injection points to allow for middleware and add bindings for adding things like new keywords, etc.

We'll need to wait to see how the dust settles, but I think this is both doable and would be fun to build!

Current Features

We'll also need to address this in two separate parts. Currently, we have what we call "Source Transformers" and "Program Transformers".

To be honest, I've never liked the name of the latter, but we chose it to be more easily understandable for our users, who most often didn't come from a background of working with compilers.

Source Transformers

Source Transformers are what most users are working with, so we'll start there.

For Source Transformers, it's too early to tell you how, but I have a high degree of confidence that this will still be doable. We need to see what final decisions are made with the TS compiler; however, they mentioned that they're working with major tooling creators.

Transformers are a big part of the Compiler API, so I would imagine they'll continue JS support.

With all of that said, my current aim is to continue enabling support for source transformers.

Program Transformers

This is generally used as something of a "hack", but it's also a critical feature that I and many others use often.

In the new version of tsp, we'll hopefully have a middleware injection API that will provide something better.

TLDR

I do not plan to sunset ts-patch. The plan is to adapt and hopefully even continue with planned new features using the new Go TS.

[M-jerez]

From this discussion microsoft/typescript-go#455
I would say the interaction with typescript will be mostly VIA Inter process communication.

But think is gonna take a long time.

If someone wants to explore the via of simply creating a new golang package and using typescript-go as dependency I would be interested in participating.
So basically a custom compiler on top of ts-go. Not sure how flexible would this be, more suited for generatin type metadata I think.
@samchon pls let me know what do you think?
An initial idea would be to emit extra files with all the metadata but we could discuss further details.

I'm the autor of https://github.com/MionKit/mion so very interested on this.

[nonara]

In the interview, Anders said their goal was to have a language agnostic Compiler API.

Transformers are a pretty big part of the Compiler API, and a lot of tooling relies on them. With that in mind, if the AST and type data are provided in a language-neutral sense, I don't see there being any need to write anything in go.

At this point, we just need to wait and see what decisions are made regarding the Compiler API, especially those regarding transformers.

There are a lot of ways to "skin the cat" here. Regardless of what route they go, it shouldn't be difficult to ensure we're restoring basic JS transformer functionality.