Bun 1.4.3 liefert einen Type-Checker, der tsc schlägt – wo er gewinnt und wo nicht

Bun 1.4.3 erschien am 10. Oktober, und das Hauptmerkmal ist bun check, ein direkt in die Bun-Binary integrierter TypeScript-Type-Checker. Er liest Ihre vorhandene tsconfig.json, meldet dieselben Fehler wie tsc und nutzt alle CPU-Kerne. Sie benötigen nicht einmal das typescript-Paket installiert. In Buns eigenen Benchmarks, die auf einem 16-Kern-Mac mit Apple Silicon ausgeführt wurden, schließt er die Typprüfung 3x bis 6,4x schneller ab als tsc 7.0.2 und verbraucht dabei 2,2x bis 4,9x weniger Arbeitsspeicher. Das src-Verzeichnis von VS Code mit fast 10.000 Dateien wurde von 5,98 Sekunden auf 1,24 Sekunden reduziert.

Die Genauigkeit ist der Aspekt, der unsere Aufmerksamkeit erregt hat. bun check ist ein Port von typescript-go, Microsofts Go-Neufassung des Compilers, und er besteht alle 51.210 Tests in der Konformitätssuite von TypeScript 7.0.2. Bun hat ihn auch gegen 72 Open-Source-Projekte getestet und seine Ausgabe mit tsc über 1.103 Konfigurationen verglichen. Bei 1.102 davon stimmte er überein. Die einzige Abweichung war ein Fehler in vuejs/core. Eine Neuimplementierung eines bekanntermaßen heiklen Typsystems, das fast überall mit dem Original übereinstimmt, ist selten, und das ist der Grund, warum dies ernst zu nehmen ist, anstatt es als »noch ein weiteres schnelles, aber falsches Tool« abzuhaken.

Sollten Sie also wechseln? Hier ist die ehrliche Einschätzung, denn die Benchmark-Zahlen verbergen einen wichtigen Haken.

Kein inkrementeller Modus, und warum das alles entscheidet

bun check speichert keinen Zustand zwischen Durchläufen. Es schreibt keine .tsbuildinfo-Datei, daher ist jeder Durchlauf ein Kaltstart. Genau deshalb gewinnt es auf CI-Runnern und frischen Checkouts, die sowieso immer kalt starten, und deshalb kann tsc es auf Ihrem Laptop immer noch schlagen.

Unabhängige Tester bestätigten beide Seiten. Scrydon verlagerte das Typprüfungs-Gate ihres Monorepos darauf, und eine vollständige Kaltprüfung von 104 Projekten sank von 124,9 Sekunden auf etwa 51 bis 68 Sekunden, wobei der Spitzenspeicherverbrauch um etwa ein Drittel zurückging. Bei einer warmen Neuprüfung nach einer einzeiligen Änderung antwortete der inkrementelle Modus von tsc jedoch in 0,81 Sekunden gegenüber 1,57 Sekunden von bun check. Bei einem kleinen Projekt, Honos 188-Datei-Build-Konfiguration, war tsc sogar schneller, weil bun check feste Startkosten für das Laden seiner Lib-Dateien hat, bevor es überhaupt etwas prüft.

Aus unserer eigenen Arbeit lässt sich das klar einordnen. Wenn wir Cloud-native PHP- und Node-Dienste für Unternehmenskunden entwickeln, ist der Typprüfungsschritt in CI oft das langsamste Gate in der Pipeline, und es ist fast immer ein Kaltstart auf einem frischen Container. Das ist der Hauptanwendungsfall. Diesen Schritt um die Hälfte zu reduzieren, mit identischen Fehlern und weniger Arbeitsspeicher, ist ein echter Gewinn, und das bedeutet, dass Teams die gleichzeitige Typprüfung nicht mehr einschränken müssen, nur um den RAM eines Runners nicht zu sprengen. Auf der Maschine eines Entwicklers, wo jemand dasselbe Paket in einer engen Schleife neu prüft, ist ein warmes tsc immer noch das bessere Werkzeug. Das sind keine konkurrierenden Aussagen. Sie beschreiben zwei unterschiedliche Workloads.

Es ersetzt TypeScript nicht in Ihrem Editor

Eines sollte klar sein: bun check erledigt keine Sprachserver-Aufgaben, daher laufen Autovervollständigung und »Zur Definition springen« weiterhin über das typescript-Paket, das Ihr Editor bereits verwendet. Es überprüft auch nur. Es gibt kein JavaScript und keine .d.ts-Dateien aus, daher benötigen Sie tsc immer noch zum Generieren von Deklarationen, wenn Sie eine Bibliothek veröffentlichen. Betrachten Sie es als schnelleres CI-Gate, nicht als vollständigen Ersatz.

Es gibt auch einen Sicherheitsaspekt, der einen Satz wert ist. Bei unseren Pentesting-Einsätzen sehen wir immer wieder, wie Lieferkettenrisiken durch Build-Werkzeuge einschleichen, die niemand überprüft. Dass bun check im Prüfschritt keine typescript-Installation benötigt, ist eine Abhängigkeit weniger, die zur CI-Zeit aufgelöst wird, und da es byte-identische Fehler meldet, können Sie es übernehmen, ohne das Gate zu schwächen, das echte Fehler abfängt. Das ist die Art von Änderung, die wir mögen: weniger bewegliche Teile, dieselben Garantien.

Der Fünf-Minuten-Test, bevor Sie sich festlegen

Der umsetzbare Teil ist klein und risikoarm. Bevor Sie eine einzige CI-Konfiguration umschreiben, führen Sie Buns eigenen Diff-Test in Ihrem Repository aus:

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

Wenn der Diff leer ist, stimmen Ihre Fehler überein und Sie können tsc --noEmit in CI zuversichtlich durch bun check ersetzen. Wenn er nicht leer ist, haben Sie einen der seltenen Randfälle gefunden, und jetzt wissen Sie das, bevor es Sie in einem Release trifft. Ein Feldbericht hat einen Namenskonflikt erwähnt, den es sich lohnt, zuerst zu überprüfen: Wenn Ihre package.json bereits ein Skript namens check definiert, kann die Ausführung von bun check in diesem Ordner Ihr Skript anstelle des Type-Checkers ausführen. Richten Sie es daher explizit auf Ihre Konfiguration aus oder führen Sie es aus einem anderen Verzeichnis aus.

Wir haben jahrelang Build- und Testpipelines für Web- und Mobile-Teams optimiert, von PHP- und Docker-Backends bis hin zu nativen iOS- und Android-Apps, und das Muster ist immer dasselbe. Die schnellste Pipeline ist diejenige, die weniger Arbeit erledigt, dieselben Sicherheitsprüfungen beibehält und laut scheitert, wenn etwas abweicht. bun check erfüllt diese Anforderungen für viele CI-Setups, mit dem ehrlichen Vorbehalt, dass es nicht für jeden Workload geeignet ist.

Wenn Ihnen ein langsames Typprüfungs-Gate in CI bekannt vorkommt, sprechen Sie mit uns. Wir helfen Teams dabei, ihre Entwicklungspipelines zu beschleunigen, ohne die Prüfungen zu entfernen, die tatsächlich Fehler abfangen.