Apps

The microsoft/TypeScript package ships several executables that share the compiler core. Each is a thin entry point that wires the ts namespace to a host (ts.sys, a tsserver host, etc.) and starts the appropriate event loop.

Executable	Source	Bin	Purpose
tsc	src/tsc/	bin/tsc	One-shot or watch-mode compilation.
tsserver	src/tsserver/	bin/tsserver	Editor-driven language server speaking JSON-over-stdio.
typingsInstaller	src/typingsInstaller/	(spawned by tsserver)	npm-driven @types/* fetcher for ATA.
watchGuard	src/watchGuard/	(spawned by tsserver on Windows)	Tests if a directory is safe to recursively watch.
typescript API	src/typescript/	lib/typescript.js	Programmatic API surface used by tools, bundlers, build systems.

All five entry points share the same _namespaces/ts.js barrel via src/typescript/typescript.ts, which re-exports everything from src/compiler/_namespaces/ts.js (and the language service / server namespaces). At build time, each entry point becomes its own bundled .js file under built/local/ (and ultimately under lib/ in the published package).

graph TD
    Compiler["src/compiler/_namespaces/ts"] --> Public["src/typescript/typescript.ts"]
    Services["src/services/_namespaces/ts"] --> Public
    Server["src/server/_namespaces/ts"] --> Public
    Public --> tsc["src/tsc → bin/tsc"]
    Public --> tsserver["src/tsserver → bin/tsserver"]
    Public --> ti["src/typingsInstaller"]
    Public --> wg["src/watchGuard"]
    Public --> Lib["lib/typescript.js (programmatic API)"]

The user-facing bin/tsc and bin/tsserver scripts are tiny shims:

// bin/tsc
#!/usr/bin/env node
require('../lib/tsc.js')

That makes it cheap to test the compiler against any locally built version: node ./built/local/tsc.js … runs the just-built compiler with no install step.

For a deeper look at how a single tsc invocation walks the pipeline end-to-end, see systems/program. For how tsserver manages multiple projects per editor, see systems/project-system.