Bun 1.4.3 embarque un vérificateur de types qui surpasse tsc. Voici où il gagne, et où il ne gagne pas.

Bun 1.4.3 est arrivé le 10 octobre, et la nouveauté phare est bun check, un vérificateur de types TypeScript intégré directement dans le binaire Bun. Il lit votre tsconfig.json existant, signale les mêmes erreurs que tsc, et exploite tous les cœurs du processeur. Vous n'avez même pas besoin d'avoir le package typescript installé. Selon les benchmarks de Bun, réalisés sur un Mac Apple silicon 16 cœurs, il termine la vérification de types entre 3 et 6,4 fois plus vite que tsc 7.0.2, tout en utilisant 2,2 à 4,9 fois moins de mémoire. Le répertoire src de VS Code, avec près de 10 000 fichiers, est passé de 5,98 secondes à 1,24 seconde.

C'est la précision qui a retenu notre attention. bun check est un portage de typescript-go, la réécriture en Go du compilateur par Microsoft, et il passe les 51 210 tests de la suite de conformité de TypeScript 7.0.2. Bun l'a également exécuté sur 72 projets open-source et comparé ses résultats à tsc sur 1 103 configurations. Il correspondait sur 1 102 d'entre elles. Le seul désaccord était une erreur dans vuejs/core. Qu'une réimplémentation d'un système de types notoirement capricieux s'accorde avec l'original dans presque tous les cas est rare, et c'est la raison pour laquelle cela mérite d'être pris au sérieux plutôt que classé dans la catégorie « un autre outil rapide mais inexact ».

Alors, devriez-vous faire le changement ? Voici la version honnête, car les chiffres des benchmarks cachent un piège important.

Pas de mode incrémental, et pourquoi cela change tout

bun check ne conserve aucun état entre les exécutions. Il n'écrit pas de fichier .tsbuildinfo, donc chaque exécution est une exécution à froid. C'est précisément pourquoi il gagne sur les runners de CI et les checkouts récents, qui démarrent toujours à froid, et c'est aussi pourquoi tsc peut encore le surpasser sur votre machine.

Des testeurs indépendants ont confirmé les deux aspects. Scrydon a migré la porte de vérification de types de son monorepo dessus, et une vérification à froid complète de 104 projets est passée de 124,9 secondes à environ 51 à 68 secondes, avec une mémoire de pointe réduite d'environ un tiers. Mais lors d'une nouvelle vérification à chaud après un changement d'une ligne, le mode incrémental de tsc répondait en 0,81 seconde contre 1,57 pour bun check. Sur un petit projet, la configuration de build Hono avec 188 fichiers, tsc était en réalité plus rapide, car bun check supporte un coût de démarrage fixe pour charger ses fichiers lib avant de vérifier quoi que ce soit.

Dans notre propre expérience, cela correspond clairement à l'endroit où il a sa place. Lorsque nous développons des services PHP et Node cloud-natifs pour des clients entreprises, l'étape de vérification de types en CI est souvent la porte la plus lente du pipeline, et il s'agit presque toujours d'une exécution à froid sur un conteneur neuf. C'est là son terrain de prédilection. Réduire cette étape de moitié, avec des erreurs identiques et une mémoire moindre, est un vrai gain, et cela signifie que les équipes peuvent arrêter de plafonner la concurrence de vérification de types juste pour éviter de saturer la RAM d'un runner. Sur la machine d'un développeur, où quelqu'un revérifie le même package en boucle serrée, tsc préchauffé reste le meilleur outil. Ce ne sont pas des affirmations contradictoires. Elles décrivent deux charges de travail différentes.

Il ne remplace pas TypeScript dans votre éditeur

Une chose à préciser : bun check n'effectue aucun travail de serveur de langage, donc l'autocomplétion et le « aller à la définition » utilisent toujours le package typescript déjà utilisé par votre éditeur. Il ne fait que vérifier. Il n'émet ni JavaScript ni fichiers .d.ts, donc si vous publiez une bibliothèque, vous aurez toujours besoin de tsc pour générer les déclarations. Considérez-le comme une porte de CI plus rapide, pas comme un remplacement complet.

Il y a aussi un aspect sécurité qui mérite d'être mentionné. Dans nos missions de pentesting, nous constatons régulièrement que le risque de chaîne d'approvisionnement s'infiltre par les outils de build que personne n'audite. Le fait que bun check n'ait pas besoin d'installer typescript à l'étape de vérification représente une dépendance de moins à résoudre au moment de la CI, et comme il signale des erreurs identiques à l'octet près, vous pouvez l'adopter sans affaiblir la porte qui détecte les vrais bugs. C'est le type de changement que nous apprécions : moins de pièces mobiles, mêmes garanties.

Le test de cinq minutes avant de vous engager

La partie concrète est petite et peu risquée. Avant de réécrire une seule configuration CI, exécutez le propre test de diff de Bun sur votre dépôt :

bunx -p typescript@7.0.2 tsc --noEmit --pretty false > tsc.txt
bun check --no-pretty > bun.txt
diff tsc.txt bun.txt

Si le diff est vide, vos erreurs correspondent et vous pouvez remplacer tsc --noEmit par bun check en CI en toute confiance. S'il n'est pas vide, vous avez trouvé l'un des rares cas limites, et vous le savez maintenant avant qu'il ne vous cause des problèmes lors d'une release. Un retour de terrain a signalé un conflit de noms à vérifier en premier : si votre package.json définit déjà un script nommé check, exécuter bun check dans ce dossier pourrait lancer votre script plutôt que le vérificateur de types, donc pointez-le explicitement sur votre config ou exécutez-le depuis un autre répertoire.

Nous avons passé des années à affiner les pipelines de build et de tests pour des équipes web et mobiles, des backends PHP et Docker aux applications iOS et Android natives, et le schéma est toujours le même. Le pipeline le plus rapide est celui qui fait moins de travail, conserve les mêmes vérifications de sécurité, et échoue bruyamment quand quelque chose dérive. bun check répond à ce cahier des charges pour de nombreuses configurations CI, avec l'astérisque honnête qu'il ne convient pas à toutes les charges de travail.

Si une porte de vérification de types lente en CI vous parle, parlons-en. Nous aidons les équipes à accélérer leurs pipelines de développement sans supprimer les vérifications qui détectent vraiment les bugs.