Bun 1.4.3 ajoute bun check, un vérificateur de types TypeScript plus rapide

Bun 1.4.3 est sorti le 10 octobre 2026, et il ajoute bun check, un vérificateur de types TypeScript intégré au runtime. Selon Bun, il est 3 à 6,4 fois plus rapide que tsc 7.0.2, le vérificateur de Microsoft lui-même, tout en utilisant 2,2 à 4,9 fois moins de mémoire. Un vérificateur de types lit votre code et signale les erreurs de type sans l'exécuter. Sur les gros projets, cette vérification est souvent l'une des étapes les plus lentes d'un pipeline de CI, le build automatisé qui s'exécute à chaque pull request.

Bun est un runtime JavaScript qui intègre aussi un gestionnaire de paquets, un bundler et un exécuteur de tests. La branche 1.4 est la version qui a fait passer le code de Bun de Zig à Rust en août.

Ce que fait bun check

D'après l'annonce de la version 1.4.3 de Bun, bun check est un portage de typescript-go. Il s'agit du compilateur TypeScript 7 écrit en Go, distribué sous le nom tsc 7. Selon la documentation de Bun, la commande lit tsconfig.json, signale les mêmes erreurs que tsc de TypeScript 7 et utilise tous les cœurs du processeur.

Elle ne fait que vérifier. Elle n'écrit jamais de JavaScript, de fichiers de types .d.ts, de source maps ni de fichiers .tsbuildinfo. Elle n'a pas non plus de serveur de langage, donc votre éditeur continue d'exécuter sa propre copie de TypeScript. La commande se termine avec le code 1 quand elle trouve une erreur et avec 0 quand elle n'en trouve aucune.

Bun fait état de deux tests de précision :

• La commande réussit 51 210 tests sur 51 210 de la suite de conformité de TypeScript 7.0.2.
• Sur 72 projets open source, 1 102 configurations sur 1 103 ont donné des résultats identiques. Bun a comparé 286 267 erreurs et a trouvé une divergence, dans vuejs/core.

La même vérification fonctionne aussi dans d'autres commandes. bun --check, bun test --check, bun build --check et bun run --check vérifient d'abord les types, puis font leur travail habituel.

Les chiffres du benchmark de Bun

Bun a effectué sa comparaison sur un Mac Apple silicon à 16 cœurs, face à tsc 7.0.2 :

Projet	Fichiers	bun check	tsc 7.0.2	Accélération
VS Code src	9,795	1.24 s	5.98 s	4.8x
mikro-orm	2,883	1.20 s	5.97 s	5.0x
Next.js packages/next	2,881	0.28 s	1.82 s	6.4x
Next.js root	3,547	0.42 s	1.28 s	3.1x
Storybook scripts	1,039	0.27 s	0.96 s	3.5x
Nuxt	839	0.27 s	0.80 s	3.0x
Playwright	706	0.15 s	0.64 s	4.2x

La consommation de mémoire a aussi baissé. Sur le code source de VS Code, Bun a mesuré 2,14 Go pour bun check contre 7,97 Go pour tsc 7.0.2. L'annonce n'est pas tout à fait cohérente sur le haut de la fourchette. Son texte indique « 3 à 6,4 fois plus rapide », tandis que le texte alternatif de son graphique parle de 3 à 7 fois.

Un benchmark externe

Un projet indépendant fournit une deuxième série de chiffres. tsrs est un portage en Rust du vérificateur de TypeScript 7, réalisé par le développeur Max Schwenk. Son README indique qu'il a été « écrit en grande partie par des agents de codage IA, sous la direction et la relecture de Max Schwenk ». Il concurrence bun check, donc ses affirmations méritent la même prudence que celles de Bun.

Sur la base de code de VS Code, exécutée sur une machine Linux à 64 cœurs, tsrs rapporte ces temps :

Vérificateur	Temps	Pic de mémoire
tsc 7 (tsgo 7.0.2)	9.79 s	7.52 GiB
bun check (Bun 1.4.3 canary)	0.87 s	2.86 GiB
tsrs	0.53 s	2.64 GiB

Le README de tsrs ajoute une réserve importante. Par défaut, tsgo utilise 4 threads de vérification, tandis que bun check utilise tous les cœurs. Quand tsrs a donné 16 threads aux trois outils sur VS Code, tsgo a mis 4,54 s et bun check 1,49 s. L'écart est réel, mais il est plus faible que ne le laissent penser les réglages par défaut.

Le reste de la version

Bun 1.4.3 modifie aussi le runtime lui-même :

• CPU au repos. Les serveurs utilisent 67 % à 89 % de CPU en moins lorsqu'ils sont inactifs. Bun a attribué ce gaspillage à un minuteur de ramasse-miettes d'une seconde qui restait actif. Sur deux minutes d'inactivité, un serveur Express est passé de 282 à 57 millisecondes de CPU.
• Bun.FetchSession. Une nouvelle API donne à un groupe de requêtes ses propres réglages TLS, proxy et keep-alive, ainsi que son propre pool de connexions.
• Bun.ModuleGraph. Une API expérimentale exécute de nombreuses copies d'une même application dans un seul processus. L'annonce prévient que graph.dispose() « n'est pas un bac à sable de sécurité ».
• node:http. Les réponses volumineuses sont jusqu'à 2,7 fois plus rapides.
• bun install. Il ignore désormais les tarballs qu'il n'installera pas. L'installation de npm@10.9.2 est passée de 196 tarballs à 1.
• Sécurité. La version corrige CVE-2026-48618 dans la correspondance des noms d'hôte TLS. Elle limite aussi le débit des réinitialisations de flux HTTP/2 pour CVE-2023-44487 et CVE-2025-8671.

Ce que cela signifie pour les développeurs

Pour la plupart des projets, le changement tient en une ligne. La documentation de Bun fait correspondre tsc --noEmit à bun check et tsc -b à bun check -b. Lancez d'abord bun upgrade, puis chronométrez les deux commandes sur votre propre dépôt. Le matériel, le nombre de threads et la structure du projet influencent tous le résultat.

Vérifiez cinq points avant de modifier votre CI :

• Gardez tsc si vous publiez des types. bun check n'écrit jamais de fichiers .d.ts, donc les auteurs de bibliothèques ont encore besoin de tsc pour cette étape.
• Repérez les options bloquées. La vérification s'arrête sur des réglages anciens, dont moduleResolution: node10, baseUrl, target: es5 et outFile.
• Yarn PnP n'est pas pris en charge. Définissez nodeLinker: node-modules si vous utilisez Yarn.
• Méfiez-vous d'un script nommé check. Si package.json définit un script check, bun check exécute ce script à la place. Utilisez alors bun --check.
• Fixez le nombre de threads sur les runners partagés. La documentation suggère --threads 4 sur les machines de CI partagées.

Votre éditeur peut encore donner un résultat différent de bun check, car il exécute son propre TypeScript. La documentation suggère d'installer la version correspondante avec bun add -d typescript@$(bun -p process.versions.typescript).

L'outillage TypeScript continue de passer au code natif. Microsoft a porté le vérificateur en Go, Bun a porté ce portage, et tsrs le porte à nouveau en Rust. Le mois dernier, tsgolint a lui aussi apporté en Go des règles de lint qui tiennent compte des types. Les équipes qui vérifient les types à chaque commit disposent désormais de plusieurs vérificateurs rapides à comparer entre eux sur leur propre code.