Các dữ kiện kỹ thuật và ghi chú đo lường được duy trì bằng tiếng Anh để tránh sai lệch giữa các bản dịch.

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.

Cách hoạt động

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

TypeScriptTệp .ts
SWC
Bộ phân tíchPhân tích nhanh
HIR
Chuyển đổiMonomorphization
LLVM
Sinh mãMã máy
Tệp thực thiFrom ~330 KB; varies by features

Muốn biết trình biên dịch hoạt động bên trong như thế nào? Cấu trúc bên trong trình biên dịch

Tìm hiểu chuyên sâu: TypeScript trên LLVM — monomorphization, NaN-boxing, và lý do Perry rời bỏ 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