Fakta teknis dan catatan pengukuran dipelihara dalam bahasa Inggris untuk mencegah perbedaan antar-terjemahan.

A TypeScript Native Compiler, Built in Rust

Perry compiles supported TypeScript and JavaScript ahead of time to machine code. Native builds do not require an external JavaScript engine by default, while the Perry runtime and GC remain part of the executable.

A hybrid compiler, not “types make JavaScript static”

TypeScript annotations are mostly erased and do not prove a concrete runtime representation for every expression. Perry combines declared types, inference, known call shapes, and representation selection to optimize proved cases. Dynamic values, unknown receivers, prototypes, and other JavaScript behavior retain runtime paths.

That distinction matters: known numeric operations or object shapes may become direct machine operations, while other code uses the statically linked runtime and garbage collector. Some unsupported engine semantics require the optional V8 fallback or do not compile.

Cara Kerjanya

From TypeScript source through SWC, Perry HIR, LLVM, and the linked runtime

TypeScriptFile .ts
SWC
ParserParsing cepat
HIR
TransformasiMonomorphization
LLVM
CodegenKode mesin
ExecutableFrom ~330 KB; varies by features

Ingin tahu bagaimana kompiler bekerja di balik layar? Struktur internal kompiler

Pendalaman: TypeScript di atas LLVM — monomorphization, NaN-boxing, dan mengapa Perry meninggalkan Cranelift.

The current pipeline

  1. Parse with SWC. Perry builds an AST and resolves modules before its own lowering passes.
  2. Lower to Perry HIR. The compiler records operations and the type or representation evidence it can actually prove.
  3. Specialize bounded known cases. Known calls and values can use direct paths; polymorphic cases keep checked, boxed, or dynamic fallbacks.
  4. Generate LLVM IR. LLVM optimizes and emits target-specific object code.
  5. Link and package. Perry links the required runtime, GC, libraries, and target-specific platform pieces.

Support is broad, not universal

The current project reports ~97% parity across 53 tracked Node modules and roughly ~50 native package/API implementations. Known gaps include dynamic code paths and parts of JavaScript, TypeScript, Node.js, and package compatibility.

Perry documents 11 targets, with narrower core support on some devices and HarmonyOS kept as a separate preview. “One codebase” is a portability goal, not a promise that every API and layout behaves identically on every platform.

Try it against real code

Run Perry’s checker and compile the exact package graph and target you intend to ship.

Get started