Rewriting TypeScript in TypeScript: The tsc-ts Project Sparks Discussion

When a Compiler Rewrites Itself in Its Own Language

A project called tsc-ts has sparked discussion in the developer community, with a simple and direct goal: rewrite the TypeScript compiler in TypeScript. This approach is not unfamiliar in the programming language field—using the language's own syntax and type system to implement its toolchain is both a technical exploration and a self-examination of the language's expressive power.

The Significance of Self-Hosting: From Trust to Verification

Compiler self-hosting is a landmark milestone in language engineering. GCC, Rust, and Go have all gone through the stage of rewriting their compilers in their own languages. The benefits are not just "showing off": it exposes design flaws in the language in real engineering, and makes toolchain maintainers more familiar with the language's boundaries.

tsc-ts applies the same logic to TypeScript. The TypeScript compiler was originally written in TypeScript and then compiled to JavaScript to run, while tsc-ts explores the feasibility of fully replicating the compilation process at the type level, which requires developers to deeply understand type inference, AST traversal, and code generation.

Compiler self-hosting refers to writing a language's compiler in that language itself. The first stage usually involves implementing a "bootstrap compiler" in another language (such as C), then writing a new version in the target language and compiling it with the bootstrap compiler to produce a runnable self-hosted version. The core challenge is trust transfer: ensuring that the compiler semantics before and after self-hosting are consistent, otherwise hidden bugs are easily introduced. Self-hosting tests the language's expressiveness, performance, and toolchain maturity, and is an important marker of a language entering industrial-grade application.

AST (Abstract Syntax Tree) traversal is a core part of the compiler. The compiler first parses the source code into a tree structure, where nodes represent syntactic constructs (such as expressions and declarations). Then, through the visitor pattern, it recursively traverses the AST and performs type checking, scope analysis, or code generation at specific nodes. The TypeScript compiler's type inference and error reporting rely on precise AST traversal logic, and must handle complex scenarios such as type narrowing and conditional types. Understanding AST traversal is a key step to understanding the TypeScript compilation process.

Focus of Community Discussion

Judging from the direction of Hacker News comments, the discussion focuses on several levels. First, performance and engineering cost: rewriting the compiler means a huge maintenance burden, and whether the TS team has the motivation to adopt it is questionable. Second, the expressiveness boundary of the type system: some compiler internal logic relies on dynamic features of the JavaScript runtime, and how to express them under pure type constraints becomes a difficulty. Third, educational value: for developers who want to understand the TypeScript compilation process, a more readable implementation is itself excellent learning material.

These discussions have not reached a unified conclusion, but there is general agreement that the project's exploratory significance outweighs its short-term practicality.

The expressiveness boundary of the type system refers to the extent to which a language's type mechanism can describe and constrain program behavior. TypeScript's type system supports advanced features such as generics, conditional types, and mapped types, but is still limited by Turing completeness and runtime dynamism. Some compiler internal logic relies on dynamic behavior of the JavaScript runtime (such as object property enumeration and eval-style evaluation), which cannot be precisely modeled at the pure type level. Therefore, when rewriting the compiler in TypeScript, one must determine which logic can be encoded as types and which must remain at runtime, which directly determines the project's feasibility and complexity.

Practical Impact on Ordinary Developers

In the short term, tsc-ts will not replace the official tsc. The TypeScript team's main line remains focused on performance optimization and JavaScript ecosystem compatibility; type checking speed and incremental compilation are the metrics that matter in production environments. tsc-ts is more like an experimental playground: it may produce more aggressive type feature prototypes, and may also contribute reusable parsers or type checking modules.

For teams using TypeScript, the most pragmatic action is to follow its subsequent evolution rather than migrate immediately. Understanding how the compiler works can help developers locate problems faster when encountering complex type errors.

A Direction Worth Watching

Writing a TypeScript compiler in TypeScript is essentially asking: how complex engineering logic can this language's type system carry? The answer will not come overnight, but every self-hosting attempt will make the language itself clearer.

One-line Summary

tsc-ts explores rewriting the TypeScript compiler in TypeScript, sparking community discussion on the value and boundaries of self-hosting.

Paragraph Summary

The tsc-ts project attempts to rewrite the TypeScript compiler in TypeScript, a self-hosting approach that is landmark in language engineering. Community discussion focuses on performance and maintenance costs, the expressiveness boundary of the type system, and educational value, with general agreement that its exploratory significance outweighs short-term practicality. In the short term it will not replace the official tsc, but it may become an experimental playground for type feature prototypes and reusable modules, helping developers understand the compiler's internal mechanisms.