Bun 1.4.3, veröffentlicht am 10. Oktober 2026, bringt bun check, einen in die Laufzeitumgebung integrierten TypeScript-Checker. Als Port des typescript-go-Compilers meldet er dieselben Fehler wie tsc, ohne JavaScript zu erzeugen, und nutzt dabei alle verfügbaren CPU-Kerne. Die Version behebt zudem eine Regression, die auf untätigen Servern einen Timer dauerhaft laufen liess — die CPU-Last im Leerlauf sinkt dadurch um 67 bis 89 Prozent.
Ein Checker ohne Abhängigkeit vom TypeScript-Paket
bun check liest die tsconfig.json des Projekts direkt ein und benötigt das Paket typescript nicht. Er ersetzt nicht den Language Server des Editors, der weiterhin auf TypeScript für Echtzeit-Rückmeldungen setzt, läuft aber auf der Kommandozeile oder eingebettet in andere Bun-Befehle.
bun check
bun check --no-pretty # unformatierte Ausgabe, nützlich für Diffs
bun run --check dev # prueft Typen vor dem Start des Skripts
bun test --check # prueft Testdateien und deren Imports
bun build --check ./src/index.ts --outdir outDer Befehl verlässt sich auf den Editor für die Echtzeiterfahrung und auf die eigene Engine für die Kommandozeilenprüfung, sodass er sich ohne Installation des offiziellen Compilers in ein Build-Skript oder einen CI-Schritt einbinden lässt.
Leistungsunterschiede an realen Projekten gemessen
Auf einem 16-Kern-Apple-Silicon-Mac hat das Bun-Team bun check mit tsc 7.0.2 an mehreren Open-Source-Codebasen verglichen.
| Projekt | Dateien | bun check | tsc 7.0.2 | Beschleunigung |
|---|---|---|---|---|
| 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 |
| Playwright | 706 | 0,15 s | 0,64 s | 4,2x |
Beim VS-Code-Projekt sinkt der Speicherverbrauch auf 2,14 GB gegenüber 7,97 GB bei tsc, also auf ein 3,7-faches Weniger. Ein zweiter Benchmark unter Linux x64, mit 64 Threads und über 20 Durchläufe gemittelt, bestätigt den Abstand bei den 10.947 Dateien von VS Code: 1,75 s für bun check gegenüber 5,88 s für tsc 7 mit 16 Prüfprozessen.
Die Frage der Korrektheit
Ein schnellerer Checker nützt nur, wenn er zum selben Urteil kommt wie das Original. Das Bun-Team gibt an, die Konformitätssuite von TypeScript 7.0.2 zu 100 Prozent zu bestehen, 51.210 Tests, und die eigene Ausgabe mit der von tsc an 72 absichtlich falsch konfigurierten Open-Source-Projekten verglichen zu haben.
Bun gibt an, die eigene Ausgabe mit der von tsc anhand von 286.267 gemeldeten Fehlern in 72 Projekten verglichen zu haben, mit nur einer gefundenen Abweichung.
Diese Zahlen stammen vom Bun-Team selbst, nicht von einer unabhängigen Prüfung. Das Team hat ein Verfahren veröffentlicht, um den Vergleich an einem beliebigen Projekt nachzuvollziehen: tsc und bun check parallel ausführen, die Ausgaben per diff vergleichen und bei Abweichungen ein Ticket eröffnen.
bunx -p [email protected] tsc --noEmit --pretty false > tsc.txt
bun check --no-pretty > bun.txt
diff tsc.txt bun.txtEin Server, der im Leerlauf wirklich ruht
Die zweite nennenswerte Korrektur betrifft langlebige HTTP-Anwendungen. Seit Version 1.4.2 hielt eine gelegentliche Anfrage einen Garbage-Collection-Timer jede Sekunde am Laufen, selbst ohne Traffic. Version 1.4.3 weckt den Prozess nur noch für echte Arbeit, etwa einen Health-Check alle zehn Sekunden.
| Framework | v1.4.0 | v1.4.2 | v1.4.3 |
|---|---|---|---|
| Express | 308 ms | 282 ms | 57 ms |
| Elysia | 280 ms | 197 ms | 21 ms |
| Hono | 263 ms | 195 ms | 21 ms |
| Next.js SSR | 628 ms | 815 ms | 268 ms |
Diese kumulierten CPU-Werte, gemessen über zwei Minuten Leerlauf mit einem Health-Check alle zehn Sekunden, betreffen vor allem nutzungsabhängig abgerechnete Deployments, bei denen ein grundlos laufender Prozess direkte Kosten verursacht. Auch der Speicherverbrauch im Leerlauf sinkt um 6 bis 11 Prozent gegenüber der Vorgängerversion.
Der Rest der Veröffentlichung
Die Version bringt zudem Bun.FetchSession, das TLS-, Proxy- und Keep-Alive-Einstellungen pro Gruppe von Anfragen isoliert, sowie eine experimentelle Klasse Bun.ModuleGraph, die mehrere Instanzen einer Anwendung in einem einzigen Prozess laufen lässt. Mehrere Sicherheitskorrekturen runden die Version ab, darunter eine TLS-Härtung unter CVE-2026-48618.
Einen breiteren Vergleich von JavaScript-Paketmanagern und Laufzeitumgebungen bietet der Vergleich von npm, pnpm, Bun und Deno. Beim TypeScript-Compiler selbst wurde der Wechsel zu einem in Go geschriebenen Compiler bereits im Artikel zu TypeScript 7 und seinem Go-Compiler behandelt, dessen tsc 7.0.2 hier als Vergleichsreferenz dient.
Was man sich merken sollte
Bun 1.4.3 macht aus der Typprüfung ein Geschwindigkeitsargument statt eines allein dem TypeScript-Ökosystem überlassenen Dienstes. Die angegebenen Gewinne, je nach Projekt 3x bis 6,4x, betreffen die Prüfung auf der Kommandozeile und in CI, nicht die Erfahrung im Editor, die weiterhin auf dem gewohnten TypeScript-Language-Server basiert. Für Teams, die Bun-Dienste in nutzungsabhängig abgerechneter Produktion betreiben, dürfte die Behebung des Leerlauf-Timers mindestens ebenso ins Gewicht fallen wie der neue Checker.
Die Zahl, die im Gedächtnis bleibt, ist nicht das 6,4-fache bei Next.js, sondern der 89-prozentige Rückgang der CPU-Last im Leerlauf bei Elysia. Mehr als eine Hosting-Rechnung wurde schon durch einen grundlos laufenden Node-Prozess zwischen zwei Anfragen aufgebläht als durch einen von einem langsamen Typchecker gebremsten Build. Ob bun check auch bei weniger aufgeräumten Codebasen hält als den für die Demo gewählten, mit veralteten tsconfig-Setups und rekursiven generischen Typen, die so manches Drittanbieter-Tool aus der Bahn werfen, bleibt abzuwarten. Bis dahin ist das vom Team veröffentlichte Diff-Skript der richtige Weg, es im eigenen Projekt zu prüfen, bevor tsc aus einer CI-Kette entfernt wird. — Simon Janvier
Zum Weiterlesen: der offizielle Beitrag des Bun-Teams zu Version 1.4.3.
