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.

[ufukty]

Are you considering different repositories for each? Because Go tools will pick up vX.Y.Z tags from the repo, which are language agnostic.

I noticed my first sentence is a little bit misunderstood as I didn't make it obvious that I meant different repositories for the typescript-go and public-facing Go API. Sorry for inconvenience. I know typescript-go is supposed to merge to the main once the versions are synchronized.

[mitar]

Can somebody make use of git submodule to add https://github.com/microsoft/typescript-go as a git submodule and thus access its internal packages? Does that work?

[ufukty]

Well, if having separate git repositories (like in submodules) for typescript-go and the public API content (parser, printer, AST nodes etc.) is okay; is there really a necessity for them to be nested? With typescript-go and typescript-gotools being separate, typescript-go can be versioned independently from the typescript-gotools. That way, incrementing the major for breaking changes in public API would only concern the typescript-gotools, and typescript-go would preserve the liberty of following the main repository for its versioning scheme.

[jakebailey]

I already know of people who have either pulled us as a submodule and the hacked out an API with linkname, or are simply republishing the repo with the contents of the internal dir moved up.

But to be clear, if we want to support something, I'm sure we'll figure it out. But whatever we do will not involve multiple repos. I'd sooner solve the problem by putting the module in a subdir of the main repo and then publish go/v70.0.0 or something.

[mitar]

@jakebailey That would be awesome. I also think one repo should be enough.

[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.

[mitar]

I am in a similar boat. I am interested in having a tool to compile TypeScript into Go to allow then easier use of same code both on frontend and backend. I made years ago a simple implementation, but having it use TypeScript as input would allow some type-based optimizations during compiling.

[mitar]

From my side it would be completely fine if some small API would be exposed without any Go stability guarantees.