Un compilateur TypeScript natif, bâti en Rust

Ni un transpileur. Ni un runtime.

La plupart de l'outillage TypeScript se divise en deux familles. Les transpileurs — tsc, SWC, esbuild — vérifient et suppriment les types, puis émettent du JavaScript qu'un moteur exécutera plus tard. Les runtimes — Node.js, Bun, Deno — sont ces moteurs : ils analysent, interprètent et compilent le JavaScript en JIT à chaque démarrage de votre programme.

Un compilateur natif est la troisième famille, et pour TypeScript elle est restée largement vide. Perry traite les annotations de type non pas comme une documentation à supprimer, mais comme l'entrée qui pilote la génération de code. Le résultat de perry compile main.ts est un exécutable autonome contenant du code machine — typiquement 2 à 5 Mo, démarrant en environ une milliseconde.

Le pipeline, étape par étape

1. Analyse (SWC). Les fichiers source sont analysés avec SWC, le parseur TypeScript natif en Rust, si bien que même les gros projets s'analysent en quelques millisecondes. La génération de code par module, les passes de transformation et le scan de symboles s'exécutent en parallèle sur plusieurs cœurs.
2. Résolution des types. Le compilateur résout les types déclarés et infère le reste, donnant à chaque expression un type concret avant que la génération de code ne commence.
3. HIR typé et monomorphisation. L'AST est abaissé vers une IR typée de haut niveau. Les fonctions et classes génériques sont monomorphisées — chaque instanciation comme Stack<number> est compilée séparément avec ses types concrets, si bien que les génériques ne coûtent rien à l'exécution. Là où les types sont connus, les appels de méthode deviennent du dispatch statique et les champs d'objet deviennent des chargements directs à décalage fixe.
4. Génération de code (LLVM). Le HIR est abaissé vers de l'IR LLVM et passé à travers le pipeline d'optimisation de LLVM — inlining, optimisations de boucles, vectorisation — puis émis en code machine pour la cible.
5. Édition de liens. La sortie est un exécutable de plateforme normal : Mach-O sur macOS, ELF sur Linux, PE sur Windows — plus les cibles mobile, montre, TV et WebAssembly.

Le volet LLVM de tout cela — pourquoi LLVM a été choisi plutôt que Cranelift, comment le NaN-boxing représente les valeurs dynamiques, ce que l'optimiseur fait avec l'IR typée — a sa propre plongée en profondeur : TypeScript sur LLVM. Les détails d'implémentation comme le NaN-boxing, le dispatch statique et les abstractions à coût nul sont couverts dans le fonctionnement interne du compilateur.

Qu'en est-il du code dynamique et de npm ?

TypeScript reste du JavaScript en dessous, et un compilateur TypeScript natif doit l'assumer honnêtement. La conformité de Perry face à la suite officielle test262 est mesurée et publiée — à la date de v0.5.1146, la sémantique String est à 79 % et Array à 72 %, toutes deux en progression de release en release. Les paquets npm purement TypeScript/JavaScript compilent nativement via perry.compilePackages : axios, zod v4, express, fastify et hono compilent et s'exécutent dès aujourd'hui. Le code qui nécessite la sémantique complète d'un moteur peut opter pour un V8 embarqué en repli avec --enable-js-runtime.

Le récit complet se trouve dans Les vrais packages npm compilent désormais : axios, zod, express — et une passe de conformité.

Comment Perry se situe par rapport aux autres efforts de « TypeScript natif »

Perry n'est pas le seul projet à avoir regardé les annotations de type de TypeScript et y avoir vu une opportunité de compilation — mais les approches diffèrent nettement. AssemblyScript compile un langage strict de type TypeScript uniquement vers WebAssembly : il est délibérément incompatible avec JavaScript, et ne produit ni exécutables OS ni UI native. Static Hermes, de Meta, compile ahead-of-time un sous-ensemble JavaScript typé à l'intérieur du moteur Hermes, principalement pour React Native — à la mi-2026, il reste un projet de recherche qui doit être compilé depuis les sources, et le moteur Hermes V1 qui a réellement été livré dans React Native n'inclut pas les fonctionnalités statiques (comparaison complète).

Le pari de Perry est différent sur les deux axes : TypeScript standard comme langage d'entrée, et des exécutables de plateforme ordinaires — CLI, serveur et GUI — comme sortie, installable dès aujourd'hui via Homebrew, APT, winget ou npm.

Un compilateur, dix cibles

Comme la génération de code passe par LLVM, un seul codebase compile vers macOS, iOS, iPadOS, Android, Linux, Windows, watchOS, tvOS, WebAssembly et le Web/JS pur — y compris la compilation croisée de binaires Windows, macOS et iOS depuis une machine Linux. Les applications GUI utilisent perry/ui, une API déclarative au-dessus de vrais widgets de plateforme (AppKit, UIKit, GTK4, Win32, Android via JNI) — sans aucune webview impliquée.

Comment cela se positionne face aux autres approches : Perry vs Bun, Deno, Electron, Tauri, React Native et Static Hermes.