TypeScript Compiler

Home ships a full TypeScript front end inside the same binary that compiles .home files. home tsc parses, binds, type-checks and emits TypeScript, measured against the upstream TypeScript conformance corpus rather than against a test suite we wrote ourselves.

This page covers what the TypeScript path does today, how it is measured, and where it is still catching up.

Why it exists

A project that adopts a new systems language usually ends up with two toolchains: one for the new code, one for everything that was already there. Home avoids that split. The compiler you install to build Home programs is also the compiler that checks your existing TypeScript, so a mixed repository has one binary, one cache and one set of diagnostics.

Using it

home tsc reads the tsconfig.json you already have:

cd my-typescript-app
home tsc --noEmit

Diagnostics carry the same codes as the reference compiler, so existing tooling, editor integrations and CI matchers keep working:

error TS2345: Argument of type 'string' is not assignable to parameter of type 'number'.

Any code can be explained from the terminal:

home explain TS2345

How parity is measured

Two modes run against the upstream conformance corpus.

Coarse mode asserts that Home emits the same families of diagnostics as the reference compiler for each case. It is saturated and runs as a merge gate on every change:

HOME_TS_CONFORMANCE_FULL=1 ./pantry/.bin/zig build test -Dfilter=ts_conformance

Exact mode compares output byte for byte against baselines generated by tsgo. It is the stricter number and the one still moving:

HOME_TS_CONFORMANCE_FULL=1 \
HOME_TS_CONFORMANCE_EXACT=1 \
./pantry/.bin/zig build test -Dfilter=ts_conformance

The diagnostic-code row deserves a footnote. The remaining 459 codes are not a backlog: roughly 455 are dead in the reference compiler, meaning wording it never actually produces, and 4 are gated behind subsystems that are not wired yet. Counted against the codes tsgo really emits, the reachable set is complete. See TypeScript diagnostic reachability for the per-code breakdown.

Editor support

The same front end backs home lsp, which speaks the language server protocol over stdio:

home lsp --stdio

76 of roughly 80 protocol methods are routed, including hover, completion, signature help, semantic tokens, inlay hints, code actions, rename, call and type hierarchies, and pull-based diagnostics. See Editor and CLI tooling for the full list and the gaps.

Emit

home tsc also emits JavaScript. The printer is checked against Bun's official Zig implementation, which Home maintains, so downlevelling and syntax lowering match what the runtime expects rather than being reinvented.

Native builds go further. home build app.ts -o app produces a self-contained executable through LLVM, embedding the entry source and Home's own JavaScriptCore runtime so JavaScript semantics stay faithful:

home build app.ts -o app
./app

This first slice is single-entrypoint. Bundling the imported module graph and cross-target builds are still in progress, and native JavaScript builds need a JavaScriptCore-enabled Home compiler plus LLVM on PATH.

Status

Related

• TypeScript parity, feature by feature
• TypeScript migration, the adoption path
• Capability matrix, every row with status