Transformer Plugin or Compiler API

[M-jerez]

Current ecosistem extensively relies in the compiler API, vue, vite, angular, even react is now optimising reactivity as well as many other tools for runtypes like typia, deepkit and my ion rpc based framework mion

There was a proposal for a transformers plugin but has been now removed now. #54276 (comment)

My understanding is that now the js interaction and API is way more complicated as we have to bind JS and Go, so assuming this will be implemented last if so.

So opening this Issue to track the progress or at least heard some feedback from the Typescript team about the future of this or should those tooling be looking into migrating to go as well ?

[jakebailey]

Go is a statically compiled language without good plugin support; porting your code to Go is unfortunately not going to be a solution that works when our package contains a precompiled binary. So, any solution will certainly not involve that.

[baileympearson]

I think closing this issue as "completed" is premature. I agree that the first priority of the tsgo project should be feature parity between tsc and other core development tools (i.e., VSCode editor support, etc). This will support the majority of the community in the transition between the JS tsc and Go tsc. But there is a portion of the community that makes use of the compiler API and has expressed interest in the hypothetical plugin API. Closing this issue as "completed" leaves this portion of the community hanging. How are these projects supposed to migrate to tsgo?

Language isn't the issue here. I personally would be happy to use a TS compiler API from Go (frankly I'd probably prefer that to JS because then I'd get standalone executables out-of-the-box). I'd also imagine that if that is the solution that is offered to developers going forward, the community would just adapt and tools would be ported to Go.

There two related asks in this issue, which I guess could be separated into two separate issues:

1. add a programmatic compiler API
2. add a plugin API.

I understand that the TS team might not be considering working on these projects now but could we leave this ticket open to track interest and maybe prioritize this in the future? If not, could we have more clarity on why the TS team isn't planning on supporting these features and maybe some guidance on how the portions of the community that rely on these features should plan their eventual migrations?

[jakebailey]

Sorry, I meant to link microsoft/typescript-go#455, which is where discussion of the API is actually happening.

[jakebailey]

I also fat fingered the wrong button on my phone typing that earlier message out; I actually only meant to address the latter part of your comment about having to write Go!

[lppedd]

Jake Bailey (@jakebailey) specifically related to transformers, we currently rely on https://github.com/LeDDGroup/typescript-transform-paths to improve DevEx during development. Do you think/know if this kind of transformations will be possible with the Go port?

[jakebailey]

Have you considered using package.json import maps, which are supported by TS and all bundlers?

(paths was never meant to be prescriptive, only descriptive.)

[lppedd]

Jake Bailey (@jakebailey) thanks for the suggestion! The project uses Nx and contains 100+ modules. It was started when path aliases were the cool thing (and when Nx explicitly recommended and used them as a solution to manage inter-dependencies in monorepos). Most utility modules in our monorepo don't even have a package.json file, for example. And they are also mixed in technologies: Angular libraries reference utility modules through path aliases.

The idea is good, but practically I'm not sure how feasible it is to do it unless one is committed to also fix all the problems that are surely going to pop up.

[jakebailey]

If you're using a plugin to do this already, then whatever build system you're using must either use our API, or patch tsc to add plugins. The latter just isn't going to work, and the former would be roughly the same as before with a working API (though we have not yet explored transformation in the API yet).

The idea is good, but practically I'm not sure how feasible it is to do it unless one is committed to also fix all the problems that are surely going to pop up.

For places where you have a package.json, I would think import maps would be a benefit all around. No need to use any special plugin, you could use any other emitter, even Node's strip types, etc.

path aliases were the cool thing (and when Nx explicitly recommended and used them as a solution to manage inter-dependencies in monorepos)

I'll note that the docs have advised against that for a good while now. It's a shame they became so pervasive for something they were simply not intended for.

[lppedd]

I'll note that the docs have advised against that for a good while now. It's a shame they became so pervasive for something they were simply not intended for.

Nx has been gradually shifting away from path aliases in favor of project references and real npm/pnpm/whatever workspaces. However they still support that setup, as the baggage that's been created in 10+ years of path aliases is non-indifferent and I believe I'm not the only one that will hit this issue with transformers. Plus, not all technologies work with the new Nx setup. Angular is still WIP (no ETA), so who knows when shifting away will happen.

I have to say I was pretty happy when the Go port was announced, then I remembered I'm the one keeping the infra going and I had a moment of panic. I already spent a lot of time to get the monorepo to not be a PITA to work with, but yeah I guess you understand where I'm coming from, nothing new.

though we have not yet explored transformation in the API yet

I decided to post here so that you're aware there is a need to keep some level of compatibility with the previous implementation. It's already difficult to justify the time we spend in keeping the dev environment working, I'm not sure what would be the reaction if I come up with "we need to restructure the workspace again, sorry".

[goloveychuk]

Jake Bailey (@jakebailey)

Go is a statically compiled language without good plugin support; porting your code to Go is unfortunately not going to be a solution that works when our package contains a precompiled binary.

What if ts team provide a typescript-builder npm package, which will internally download golang compiler and build typescript and provided plugins from sources? Golang has very fast package manager and compiler, no additional deps needed.
To avoid building each time, remote cache could be added with a cache key ts-version+os+arch+plugins-hashes.

[samchon]

https://github.com/samchon/ttsc

Ma Jerez (@M-jerez) typia developer here.

typia literally dies without transformer plugins, so I had no choice but to build ttsc to survive: wraps @typescript/native-preview, re-exposes a tsconfig-driven plugin host, plus a tsx-style runner since #1669 ruled out an official one. Held together with go:linkname shims into tsgo internals, so every upstream bump can break it. Not pretty - but it was this or watch typia die.

Edoardo Luppi (@lppedd) Hope this package @ttsc/paths to be helpful for you: https://github.com/samchon/ttsc/tree/master/packages/paths