Potential Public-Facing Go API for Embedding?

[donatj]

Are there any current plans to eventually expose a stable, documented Go API that other Go applications can use to embed and invoke the TypeScript compiler directly? Right now, most functionality appears to live as internal packages and thus not usable externally.

If a public API is on the roadmap, do you anticipate supporting features like AST manipulation, incremental builds, or custom diagnostics?

I’d love to see such an API because I have services using Otto to run JavaScript, but Otto isn’t robust enough to run the JS-based TypeScript compiler as-is—so a Go-native approach would really help me transparently compile TypeScript.

[jakebailey]

I can't say for sure, but I think it's on the unlikely side that we offer up a public Go API; doing so would be a pretty heavy burden on the design of our codebase and prevent us from making a lot of breaking internal changes (other than I guess bumping the go.mod major version all the time).

Our main API users are not at all Go projects, of course; all of our API users are either in JS or out-of-proc, and that's where our current focus lies. That same API is likely to be consumable from Go out-of-proc as well. The fact that we can't really do Go plugins or anything also makes it unlikely that it'll be useful for things like editor plugins, either.

[tonywu6]

I can absolutely understand API stability being a major concern, but it’s still slightly disappointing 😅 (but that’s okay! everything is still so early)

That being said, will you be more inclined to eventually make the API public but explicitly disclaim any stability guarantees? On the Rust (sorry!) side of things, a huge appeal for me personally about tools like swc_core and oxc is that their internal APIs (parser, AST, codegen, …) are fully accessible from Rust libs, which opens up rooms for experimentation and learning, beyond ”language service-y” use cases — even though the APIs are pretty much permanently unstable and “use at your own peril.” The current tsc has a Compiler API that one can just import and poke around, so I feel like it’d be a missed opportunity for that to go away.

[jakebailey]

Not having every internal detail exposed is one of the reasons why we're leaning towards an IPC based system, honestly; "every function is our API" is/was a real nightmare. There's a lot of cruft in the old codebase that could simply never be cleaned up.

Regardless, since Go is statically linked, there's no benefit to us exporting internals per se since you can only ever access it in a totally different binary. You may as well fork and expose what you want for your own builds anyway at that point.

But, maybe there is a subset that would be a reasonable API. Some example usage would be interesting, but there's not a lot I can think of actively out there right now...

[ufukty]

Go has two different AST tools: one for the compiler (cmd/compile/internal) and another for external use (go/ast, go/parser, etc.) for mainly to ease developing static analysis tools. Public-facing version is stable and modular. Also, I assume, it offers less feature than the internal one. I guess that separating external and internal concerns in tool design makes the development easier for Go developers.

While I don't think it is fair to expect TS devs to pay more attention to Go users; I think there might be a growing reason for that. Just like the reason Go is chosen for its being the lowest level language with the infrastructure to develop modern application (without reinventing the wheel, like memory management); developers from other languages are starting to pick up Go. I expect this includes TS users who use a language other than the TS for their backend. So, Go-being the one of the fastest-growing backend language even amongst TS users-might already deserve some attention, or may in near future.

That said, I can already imagine use cases for a TypeScript parser/printer package in Go. It would be so useful, it was very difficult for me to pass this QA without writing this. One example, it would make it possible for me to create TypeScript client code from summarized Go server code within a single code generator. This can already be done in parts, but doing so is not very elegant. Writing such tools in a single language (Go, in this instance) allows us to detect breaking changes caused by updated dependencies almost instantly, thanks to the single LSP.

I expect this project will make it easier for OSS developers to publish their own versions and keep them up-to-date.

[rwalle]

This seems unfortunate. I can think of a number of cases where public Go APIs would be immensely useful, starting from the parser. Some of our existing tools written in JS (using acorn/babel parser) could be rewritten in Go and get performance improvement from multi-threading. It is very painful to deal with Node.js subprocess/worker_threads and use workers just so that you can process several files at the same time. On the other hand, that is no more than a few lines of code in Go.

I have actually tried using some of the Rust based tools for this purpose, but did not have great experience. typescript-go could pose as another option in addition to JS and Rust tools. (Sadly, esbuild does not provide public API for the parser.) And one could imagine an ecosystem of tools (e.g. linter) based on typescript-go that would be more performant than existing JS based tools and easier to author/maintain than Rust.

I really hope TS team could at least consider the following:

• Provide the smallest API surface to begin with
• Mark them as unstable

I would be very willing to take something over nothing.

You may as well fork and expose what you want for your own builds anyway at that point.

Well, I think even something as unusable as github.com/microsoft/typescript-go v0.0.0-20250313193015-e4431b42c51e in go.mod is still much easier to maintain than creating a fork and then using it. Again, I am just looking for the minimal of amount effort that the TS team can commit to.

[lunny]

We are exploring a plugin system for Gitea, an open-source project that uses Go for the backend and TypeScript for the frontend. Since Go’s native plugin system is complex, we’re looking for a solution that allows us to compile TypeScript from Go and seamlessly run both backend and frontend components. If we can achieve this, it would greatly simplify plugin development and integration.

[jakebailey]

This project isn't about an automated way to convert TypeScript to Go; you will probably have more luck embedding V8, quickjs, or goja, or potentially using Porffor to compile JS to WASM to run in wazero.