Skip to content
tslua
Docs Playground

Background

tslua exists because TypeScript is being rewritten in Go. This page collects the key discussions and decisions shaping that transition, particularly for tools that depend on TypeScript’s compiler API.

Approaches to TS7 integration

Section titled “Approaches to TS7 integration”

Tools that depend on TypeScript’s compiler API have a few options for the TS7 transition:

IPC API consumer. Wait for typescript-go’s planned msgpack-based IPC API, then call it from any language (JS, Go, Rust, etc.) as a subprocess. This is the officially supported path. The API surface is still being designed (discussion #455 ↗), and it’s unclear how much of the type checker and AST will be exposed; editor tooling is the priority, not compiler plugins. A transpiler like TSTL needs deep access to types, symbols, and the full AST, which may or may not be available over IPC.

Fork typescript-go. Fork the Go codebase and add transpilation directly. Full control, but a large maintenance surface to keep in sync with upstream.

Direct linking via shims. Link against typescript-go’s internals without forking, using go:linkname to access unexported APIs. This is what tslua does.

How tslua uses typescript-go

Section titled “How tslua uses typescript-go”

tslua takes the third approach. A gen_shims ↗ tool (originally from tsgolint ↗, now maintained in-tree) generates go:linkname shims that expose typescript-go’s type checker, AST, and program APIs as importable Go packages. tslua gets full access to the same data structures that typescript-go uses internally, at the cost of tracking upstream changes as typescript-go evolves. There is no IPC overhead or subprocess; tslua is a single binary with the type checker compiled in.

Reading list

Section titled “Reading list”