microsoft/TypeScript
The system is one Go module (tsc/, module github.com/microsoft/TypeScript/tsc) in a go.work workspace with a tools/ module, orchestrated by a Node hereby build (Herebyfile.mjs). The single binary at tsc/cmd/tsc multiplexes three runtimes: batch compile via internal/execute, an LSP server via internal/lsp over stdin/stdout, and a programmatic API server via internal/api over stdio or a named pipe. The compiler core is layered scanner/parser/ast -> binder -> checker (parallel checker pool) -> transformers -> emitter/printer/sourcemap, all reading through a vfs.FS abstraction with lib .d.ts files embedded via internal/bundled. Shipping surfaces are the `tsc`/`tsgo` binary, per-platform npm packages wrapped by packages/typescript, and the packages/vscode-typescript VS Code extension.
- The only product entrypoint is tsc/cmd/tsc/main.go: runMain() applies a debug stack limit, routes `tsc --lsp` to runLSP and `tsc --api` to runAPI, and otherwise calls execute.CommandLine with the real OS system.
- The compiler core lives in tsc/internal packages layered as scanner -> parser -> ast -> binder -> checker, with module resolution in internal/module and emit in internal/transformers, internal/printer and internal/sourcemap.
- compiler.NewProgram drives program construction: it calls processAllProgramFiles (the file loader/parse-task machinery in filesparser.go/fileloader.go), then initCheckerPool and verifyCompilerOptions.
- All file IO goes through the vfs.FS interface (FileExists, ReadFile, WriteFile, GetAccessibleEntries, Realpath, ...); the CLI wraps the real OS FS with bundled.WrapFS so embedded lib.d.ts files are served from the binary.
- Build/test/lint/format/generate tasks are defined in Herebyfile.mjs; `npx hereby build` runs `go build ./cmd/tsc` into built/local/tsc and copies tsc/internal/bundled/libs into built/local.
- The repo is a Go workspace (go.work) containing modules tsc/ and tools/, requiring Go 1.27; the tsc module pins a small dependency set (go-winio, klauspost/compress, mackerelio/go-osstat, zeebo/xxh3, golang.org/x/*, gotest.tools).
- The LSP server is internal/lsp.Server; its request dispatch is a lazily-built handlerMap (handlers()) mapping lsproto.Method values to registered handlers, with lsproto/lsp_generated.go generated from the upstream LSP meta-model.
- The programmatic API server (internal/api.StdioServer) accepts a connection over an ipc.Transport (stdio or named pipe/unix socket) and speaks either MessagePack (sync) or JSON-RPC (async) against a project.Session.
- The npm package @typescript/typescript exposes a `tsc` bin that is a Node shim (bin/tsc -> lib/tsc.js) which resolves the platform-specific Go binary via lib/getExePath.js and execve/execFileSync's it.
- The VS Code extension 'native-preview' (display name 'TypeScript 7') activates on JS/TS languages and starts the Go server by spawning the resolved exe with args ['--lsp', ...pprofArgs] through vscode-languageclient.
- internal/fswatch is a vendored, pure-Go (no cgo) filesystem watcher ported from @parcel/watcher, with per-OS backends including fanotify/inotify on Linux, FSEvents via hand-written arm64/amd64 assembly FFI on Darwin, and kqueue.
- Release packaging is driven by hereby tasks (typescript:release, vscode-typescript:release) invoked from CI's release-build job and by Azure pipelines under tools/pipelines (typescript-build.yml, typescript-publish.yml, vscode-typescript-publish.yml).
- tools/ holds a golangci-lint module plugin (customlint) registering repo-specific analyzers (bitclear, checkchildren, cleanup, emptycase, forbidparentaccess, shadow, unexportedapi), plus utilities like checkmodpaths and gen-proto.