Ce qui se passe
La version 1.4.3 de Bun (76 correctifs) apporte surtout une commande :
bun check, un vérificateur de types TypeScript intégré. C'est un portage de
typescript-go, le compilateur natif de TypeScript 7. Bun affirme qu'il passe
l'intégralité de la suite de conformité de TypeScript 7.0.2 : 51 210 tests sur
51 210, répartis entre erreurs, types, symboles, déclarations et résolution des
modules.
Il lit votre tsconfig.json, signale les mêmes erreurs que tsc et utilise tous
les cœurs. Le paquet typescript n'a pas besoin d'être installé.
Les chiffres, et d'où ils viennent
Mesures de Bun, sur un Mac à 16 cœurs, contre tsc 7.0.2 :
| Projet | Fichiers | bun check |
tsc 7.0.2 |
|---|---|---|---|
VS Code src |
9 795 | 1,24 s | 5,98 s |
Next.js packages/next |
2 881 | 0,28 s | 1,82 s |
| mikro-orm | 2 883 | 1,20 s | 5,97 s |
Soit de 3 à 6,4 fois plus rapide, avec 2,2 à 4,9 fois moins de mémoire. Pour la
fidélité, Bun a aussi comparé ses erreurs à celles de tsc sur 72 dépôts open
source volontairement mal configurés (node_modules absent, versions
différentes, pas d'étape de build) : même fichier, même ligne, même code d'erreur,
aucun écart.
Comment s'y prendre
bun check # vérifie le projet
bun run --check dev # vérifie, puis lance le script « dev »
bun test --check # vérifie les tests et leurs imports, puis les exécute
bun build ./src/index.ts --outdir dist --check # une erreur de type fait échouer le buildCôté API : Bun.build({ entrypoints: ['./src/index.ts'], check: true }). Une
erreur de type empêche l'exécution, les tests ou l'écriture du bundle.
La limite
bun check vérifie seulement : il n'émet ni JavaScript ni fichiers .d.ts,
et il n'a pas de serveur de langage. Votre éditeur continue d'utiliser
TypeScript. Les mesures sont celles de l'éditeur, pas d'une tierce partie : à
refaire sur votre projet, tsc et bun check côte à côte, en comparant erreurs
et temps avant d'en faire une étape de CI.
Source : Bun v1.4.3, Bun, 10 octobre 2026.