Port of the TypeScript compiler, checker and LSP to Rust!

The Engineering Implications of Porting the TypeScript Compiler to Rust

The TypeScript compiler (tsc) is a monolithic, single-threaded JavaScript application that has served as the backbone of the ecosystem since its inception. While it provides excellent correctness and type-checking capabilities, its performance is bound by the constraints of the V8 garbage collector and the single-threaded nature of the Node.js event loop. The project ts-rust represents a significant architectural exploration: a port of the TypeScript compiler core, including the checker and Language Server Protocol (LSP) functionality, into Rust.

The Architectural Bottlenecks of TSC

To understand the motivation behind a Rust-based port, one must first analyze the bottlenecks inherent in the current implementation. tsc is written in TypeScript, which necessitates running on a JavaScript engine. This introduces several critical limitations:

1. Memory Pressure and GC Pauses: Large-scale monorepos often contain thousands of files. When tsc performs a full type check, it builds an immense Abstract Syntax Tree (AST) and a complex symbol graph. This results in heavy memory usage, triggering frequent garbage collection cycles that block the main thread.
2. Single-Threaded Execution: TypeScript’s type-checking algorithm is inherently serial. While there are efforts to parallelize via fork() or worker threads, the shared-memory nature of a type-checked program graph makes safe parallelization in JavaScript prohibitively difficult without significant overhead.
3. Interpreter Overhead: JavaScript is a Just-In-Time (JIT) compiled language. While V8 is exceptionally fast, the deep nesting of type-checking functions and recursive descent parsing results in significant deoptimization costs and hidden class transitions.

Memory Layout and Data Structures in Rust

The porting effort necessitates a fundamental redesign of how the compiler stores state. In the original tsc, the symbol graph relies on object graphs with circular references, which are handled naturally by the JavaScript GC. In Rust, these circular references are restricted by the ownership model.

Representation of the Syntax Tree

A Rust implementation typically utilizes a "Green Tree" or "Red-Green Tree" approach (similar to rust-analyzer). In this model, the "Green Tree" represents the immutable, non-contextual syntax tree, while the "Red Tree" provides a contextual, mutable view for the LSP.

// Simplified structure for an AST node
pub enum Node {
    SourceFile(SourceFileNode),
    ImportDeclaration(ImportDeclNode),
    FunctionDeclaration(FuncDeclNode),
    // ...
}

pub struct SyntaxTree {
    // The backing storage for all nodes, usually an arena
    nodes: Arena<Node>,
    // Span-based indexing to keep node objects small
    spans: Vec<TextRange>,
}

By using arenas (e.g., typed-arena or bumpalo), developers can allocate all nodes in a contiguous block of memory. This drastically improves cache locality. In the original TSC, each node is an object scattered across the heap, leading to frequent cache misses during traversal.

Type Checking: Parallelism and Immutability

The core of the TypeScript compiler is the checker. It resolves identifiers, determines types, and verifies assignability. Porting this requires implementing a parallel query system. In rust-analyzer, this is achieved through a dependency graph where each "query" (e.g., "what is the type of variable X?") is computed on demand and cached.

The challenge in TypeScript is that the type system is Turing-complete; recursive types and conditional types can lead to infinite loops if not strictly bounded. A Rust port must enforce strict recursion limits within the check routine:

pub fn check_type(
    db: &dyn TypeDatabase, 
    type_id: TypeId, 
    depth: usize
) -> Result<CheckedType, TypeError> {
    if depth > MAX_RECURSION_DEPTH {
        return Err(TypeError::InfiniteRecursion);
    }
    // Memoization lookup
    if let Some(cached) = db.lookup_cache(type_id) {
        return Ok(cached);
    }
    // Computation logic
    // ...
}

By leveraging Rust's Arc and RwLock primitives, we can compute type information for different modules in parallel. Since the AST is immutable after the initial parse, we avoid data races entirely.

LSP Performance and Incremental Recompilation

The Language Server Protocol requires near-instantaneous responses to textDocument/didChange events. The original tsc uses watch mode, but it is often sluggish because it re-analyzes large portions of the project graph when a single file changes.

A Rust-based LSP leverages the persistent data structures described above to perform fine-grained invalidation. If a user modifies a file, the system only clears the entries in the query cache that depend on the changed file's symbols.

pub struct LanguageServer {
    pub vfs: VirtualFileSystem,
    pub query_cache: QueryCache,
    pub diagnostics: Vec<Diagnostic>,
}

impl LanguageServer {
    pub fn handle_change(&mut self, uri: Url, content: String) {
        self.vfs.update(uri, content);
        self.invalidate_affected_queries(uri);
        self.recompute_diagnostics();
    }
}

This model is fundamentally faster than the tsc incremental builder, which often relies on file-system mtimes and coarse-grained program recompilation.

Trade-offs: The Compatibility Challenge

While the performance gains are compelling, the porting effort faces a significant risk: divergence from the official TypeScript compiler. The TypeScript language is defined by the behavior of tsc.js. Any discrepancy—such as a slightly different resolution order for module exports or a deviation in how any propagates through complex generics—results in a "broken" compiler.

To mitigate this, a port must implement a massive regression test suite that runs against the actual TypeScript codebase. The project must effectively pass the TypeScript Conformance Suite. However, because TypeScript adds new features (like decorators, private class fields, or new JSX transforms) every few months, the Rust port must maintain a high velocity of development to stay synchronized with the upstream spec.

The Future of Rust in Compiler Tooling

The transition of infrastructure tools from garbage-collected languages to systems languages like Rust is a growing trend. We have seen this with swc (Speedy Web Compiler) and oxc (Oxc Compiler). By moving the type-checking layer to Rust, we enable:

1. Native Binaries: Eliminating the requirement for a Node.js runtime, simplifying deployment in CI/CD pipelines.
2. Predictable Latency: The absence of GC pauses ensures that IDE responsiveness is consistent, even in projects with millions of lines of code.
3. Hardware Utilization: Efficient use of multi-core processors allows for full type-checking passes in seconds rather than minutes.

The technical viability of a full Rust port of the TypeScript checker is no longer in question; projects like ts-rust demonstrate that it is possible. The remaining challenge is the maintenance burden—ensuring that the Rust implementation remains a drop-in replacement for the official compiler as the language specification evolves.

For enterprises and organizations requiring specialized performance engineering, low-level compiler optimization, or bespoke toolchain development to solve massive-scale software delivery challenges, professional consultancy can be a vital asset. Visit https://www.mgatc.com for consulting services.

---

Originally published in Spanish at www.mgatc.com/blog/typescript-compiler-port-rust/