TypeScriptCompiler: an LLVM/MLIR native compiler for TypeScript

Compiling .ts to a binary without a JavaScript runtime

TypeScriptCompiler is a native ahead-of-time and JIT compiler for TypeScript, built on LLVM and MLIR, and the tool it ships is called tslang. The claim in the project description is the whole pitch: it compiles .ts files directly to native executables, to WebAssembly, or runs them on the fly through a built-in JIT, with no Node.js and no JavaScript runtime in the picture.

That is a different thing from what the standard TypeScript toolchain does. The official compiler emits JavaScript and leaves execution to a host runtime such as V8, so a program that needs a native library, a graphics API or a predictable startup cost still pays for the runtime. A compiler that lowers TypeScript through MLIR and hands the result to LLVM produces an ordinary machine code binary, which means the output is deployable as a file, callable from C, and measurable with the same tooling as any other native program.

The primary language is C++, the licence is MIT and the default branch is main. This is a compiler project in the full sense, with the scale that implies: the repository carries a 3rdParty/ directory of vendored dependencies, several prepare_3rdParty scripts for different targets, docs/, scripts/ and a tslang/ directory holding the compiler itself, plus an issue tracking file named TSLANG_ISSUES.md.

The memory model is a compile-time decision, not a runtime option

The most interesting design decision in the project is that memory management is selected at build time and enforced by the compiler. The companion sample project native_ts_graphics is built with a memory model chosen at configure time, using the flag -DTSLANG_MEMORY_MODEL with the values gc, rc or none, so a garbage collector, reference counting, or no automatic management at all.

The newer option is -mm=own, described as single ownership inferred at compile time in the style of Rust's borrow checker. There is no collector and no reference counting in that mode, and a program whose ownership cannot be proven is a compile error rather than a runtime surprise. Shared ownership is opt-in through a Shared<T> wrapper.

This is the part of the design that makes the compiler interesting and also the part that makes adoption a research decision rather than a drop-in replacement. A borrow-checker style mode can reject programs that a reference-counted or collecting runtime would accept, and Shared<T> is the escape hatch for the cases that need shared access. Choosing none means writing the memory management yourself. The available modes are not interchangeable, and the same source may need real changes when you move between them.

The compiler also reaches for type-driven compile-time evaluation rather than a separate const-folding pass, and the recent release notes call out improved Template Literal Types and compile-time ifs as landed features.

tslang --new and tslang --cmake scaffold two kinds of project

The tool generates projects rather than expecting you to assemble one by hand, and the two paths differ in what they produce. The Visual Studio Code project command creates a plain project scaffold:

tslang --new Test1

The CMake variant registers TSLANG as a first-class CMake language, which is what makes the mixed C++ and TypeScript setup in native_ts_graphics work:

tslang --cmake Test1

That command generates a ready-to-build project with a CMakeLists.txt, a CMakePresets.json, a main.cpp, sample .ts sources and the cmake/ directory holding the TSLANG language modules. The generated tree is then built with standard CMake presets:

cd Test1
cmake --preset default && cmake --build --preset default

The mixed-language arrangement is the point of the design. .ts files become object files through tslang --emit=obj and are linked with the C++ code, and the README notes that incremental rebuilds work in that setup. TypeScript then calls a native framework through a C interop layer described in a donut_interop.d.ts declaration file, wrapped in TypeScript classes. The 25 samples in that project are TypeScript ports of the NVIDIA Donut rendering framework, running on Direct3D 12 and Vulkan, and they cover ray tracing, meshlets, compute n-body work, terrain tessellation, variable-rate shading and work graphs.

JIT, native binary, WebAssembly and Android are four output paths

The compiler exposes the same source through four different destinations, and the flags differ for each. The JIT path runs a program on the fly with no separate build step, and the release notes record that try/catch exception handling was implemented in the JIT on Windows, using x64 SEH unwinding through a custom LLJIT runtime. Debugging JIT output is also documented, with a GDB path for Linux.

The ahead-of-time path emits a native executable, and the flag combination for debug-friendly output is given explicitly:

tslang --di --opt_level=0 --emit=exe example.ts

The --di switch turns on generated debug information and the optimization level is pinned to zero, which is what you want when the point is to step through the program in a debugger. The documentation links a wiki page on compiling and debugging with Visual Studio Code.

Android is a supported target with NDK-linked executables and shared libraries for arm64-v8a, armeabi-v7a and x86_64 at API 29 and above, and the release zip carries the collector, the async runtime and the default library for all three ABIs. WebAssembly is the fourth path, and the tree contains dedicated prepare_3rdParty_wasm_debug.sh preparation script. In the graphics samples, the Vulkan variants are packaged as APKs, with a script that builds the samples, starts an emulator and tests them.

Type system coverage is still visibly a work in progress

The recent-feature list reads like a test suite, and that is a fair way to read it. Strict null checks are supported, with the nullability distinction enforced on assignment:

let sn: string | null = null; // Ok
let s: string = null; // error

Visibility modifiers including public, private and protected are in place, together with ECMAScript private fields:

class Point {
    private x: number;
    #y: number;
}

Class inheritance from a tuple type is supported as well, through a constructor taking a typed parameter. Compile-time ifs use a type guard function so that the return type of a generic call is resolved from the argument type:

function isArray<T extends unknown[]>(value: T): value is T {
    return true;
}

What this list signals is that the type system is a moving target. Every one of these features reads like a recent addition, the releases are named v0.0-pre-alpha, and the project publishes a JavaScript built-in objects library in a separate default library repository. A JavaScript Built-in classes library is on the roadmap as completed, which suggests the built-in surface is being filled in as the compiler matures rather than being complete today. For a team that depends on a specific library behaviour, the safe move is to check the default library repository for the exact runtime surface your code expects.

Pre-alpha tags and an MIT licence on a fast release cadence

The release record is busy and the version numbers are honest about the state of the project. Tags v0.0-pre-alpha102, v0.0-pre-alpha103 and v0.0-pre-alpha104 were published on 2026-10-14, 2026-10-17 and 2026-10-18 respectively, and the last push was on 2026-10-22. Releases in the last week of October, three of them, is a pace that suggests a project being built in public rather than one shipping a stable contract.

The technical dependencies are also heavy and current. The notes record a migration to LLVM 22.1.8 and a move to Visual Studio 2026 for the Windows build chain, with a CI badge for both Windows and Linux test builds. The 3rdParty/ directory plus the prepare_3rdParty scripts for release, debug, lldb and wasm targets show that the LLVM stack is vendored and prepared per target rather than pulled from a package manager at build time.

On licensing, the project is MIT, which is permissive and carries no copyleft obligation on code that links against it. The more relevant licence question is not the compiler's own terms but the third-party code it vendors and links, which sits in 3rdParty/ and is governed by its own licences. C bindings are generated by a separate tool called tsbindgen, and the C API surface it produces is worth reviewing on its own terms if you intend to call the runtime from C.

Editorial conclusion

Adopt tslang if you want TypeScript to produce native binaries and want the type system to carry real memory safety decisions, and stay away if you need a stable release contract, since every published tag is a pre-alpha and the project is still settling its memory model options. Before you plan a build, check the tslang/ directory and the 3rdParty/ submodules for the LLVM 22.1.8 dependency, and decide which memory model you will pass to -DTSLANG_MEMORY_MODEL, because that choice changes what your programs are allowed to do at compile time.

Frequently asked questions

Official sources

1. ASDAlexander77/TypeScriptCompiler on GitHub
2. Issues
3. License: MIT
4. README
5. Releases