You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Reacted by AlCalzone, Chandra Sekhar Kode, Justin Hopper, George Leung, Vinicius Lourenço, Dimitri Mitropoulos, Kyungsu Kang, Elliot Huffman, Max Kamps, ryoppippi and 10 more
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.
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.
I'm using tsgolint's shims in https://typical.elliots.dev/ (then connecting that to ts-patch). I don't know if and when official apis will appear, but until then I'd be interested in collaborating on a shared package we could all use.
Reacted by felistachio and Jeongho Nam
Reacted by Rob Gries, Jeongho Nam and George Leung
I'm using tsgolint's shims in https://typical.elliots.dev/ (then connecting that to ts-patch). I don't know if and when official apis will appear, but until then I'd be interested in collaborating on a shared package we could all use.
This is really interesting to me. I gave up on tsc plugins after the Go announcement, but it seems like it's working for you with the shims. Have you hit any blockers using ts-patch with typescript 7?
Activity
samchon commentedon Mar 11, 2025
Let's meet again in the Go-lang TypeScript ecosystem.
nonara commentedon Mar 11, 2025
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 commentedon Mar 12, 2025
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 commentedon Mar 13, 2025
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.
elliots commentedon Jan 13, 2026
I'm using tsgolint's shims in https://typical.elliots.dev/ (then connecting that to ts-patch). I don't know if and when official apis will appear, but until then I'd be interested in collaborating on a shared package we could all use.
robert-w-gries commentedon Jan 22, 2026
This is really interesting to me. I gave up on tsc plugins after the Go announcement, but it seems like it's working for you with the shims. Have you hit any blockers using ts-patch with typescript 7?
GeorgeGkas commentedon Sep 20, 2026
I am also interesting in your solution @elliots , can you provide some examples on steps you took to make it work?
KristjanTammekivi commentedon Oct 21, 2026
TypeScript 7.1 beta released yesterday https://devblogs.microsoft.com/typescript/announcing-typescript-7-1-beta/#typescript-7.1-api