Bun 1.4.3 include un type checker che supera tsc. Ecco dove vince, e dove no.

Bun 1.4.3 è uscito il 10 ottobre e la funzionalità principale è bun check, un type checker TypeScript integrato direttamente nel binario di Bun. Legge il tuo tsconfig.json esistente, segnala gli stessi errori di tsc e utilizza tutti i core della CPU. Non hai nemmeno bisogno del pacchetto typescript installato. Nei benchmark ufficiali di Bun, eseguiti su un Mac Apple silicon a 16 core, completa il type checking da 3x a 6,4x più velocemente di tsc 7.0.2 utilizzando da 2,2x a 4,9x meno memoria. La directory src di VS Code, quasi 10.000 file, è passata da 5,98 secondi a 1,24 secondi.

La parte sull'accuratezza è quella che ha catturato la nostra attenzione. bun check è un port di typescript-go, la riscrittura in Go del compilatore effettuata da Microsoft, e supera tutti i 51.210 test nella conformance suite di TypeScript 7.0.2. Bun lo ha anche eseguito su 72 progetti open source e ha confrontato l'output con tsc su 1.103 configurazioni. Ha corrisposto in 1.102 di esse. Il singolo disallineamento era un errore in vuejs/core. Una reimplementazione di un sistema di tipi notoriamente complicato che concorda con l'originale quasi ovunque è rara, ed è il motivo per cui vale la pena prenderlo sul serio anziché archiviarlo sotto «un altro strumento veloce ma sbagliato».

Quindi dovresti passare a bun check? Ecco la versione onesta, perché i numeri dei benchmark nascondono un'avvertenza importante.

Nessuna modalità incrementale, e perché questo decide tutto

bun check non mantiene nessuno stato tra le esecuzioni. Non scrive nessun file .tsbuildinfo, quindi ogni esecuzione è un'esecuzione a freddo. È esattamente per questo che vince sui runner CI e sui checkout freschi, che partono sempre a freddo comunque, ed è anche per questo che tsc può ancora batterlo sul tuo laptop.

I tester indipendenti hanno confermato entrambi i lati. Scrydon ha spostato il gate di type-check del loro monorepo su di esso, e un controllo completo a freddo di 104 progetti è sceso da 124,9 secondi a circa 51-68 secondi, con la memoria di picco ridotta di circa un terzo. Ma su un ricontrollo caldo dopo una modifica di una riga, la modalità incrementale di tsc ha risposto in 0,81 secondi contro gli 1,57 di bun check. Su un progetto piccolo, la configurazione di build di Hono con 188 file, tsc era effettivamente più veloce, perché bun check paga un costo di avvio fisso per caricare i suoi file lib prima di controllare qualsiasi cosa.

Dal nostro lavoro, questo si mappa chiaramente su dove appartiene. Quando costruiamo servizi PHP e Node cloud-native per clienti enterprise, il passaggio di type-check nella CI è spesso il gate più lento della pipeline, ed è quasi sempre un'esecuzione a freddo su un container fresco. Questo è il punto di forza. Ridurre quel passaggio della metà, con errori identici e meno memoria, è un vero vantaggio, e significa che i team possono smettere di limitare la concorrenza del type-check solo per evitare di esaurire la RAM di un runner. Sulla macchina di uno sviluppatore, dove qualcuno ricontrolla lo stesso pacchetto in un ciclo stretto, tsc caldo è ancora lo strumento migliore. Queste non sono affermazioni in conflitto. Descrivono due carichi di lavoro diversi.

Non sostituisce TypeScript nel tuo editor

Una cosa da chiarire: bun check non fa lavoro da language server, quindi il completamento automatico e la navigazione alla definizione eseguono ancora il pacchetto typescript che il tuo editor già utilizza. Inoltre controlla soltanto. Non emette JavaScript né file .d.ts, quindi se pubblichi una libreria hai ancora bisogno di tsc per generare le dichiarazioni. Trattalo come un gate CI più veloce, non come una sostituzione completa.

C'è anche un aspetto di sicurezza che vale la pena menzionare. Nei nostri incarichi di pentesting continuiamo a vedere il rischio supply-chain infiltrarsi attraverso strumenti di build che nessuno audita. Il fatto che bun check non richieda l'installazione di typescript nella fase di controllo significa una dipendenza in meno risolta al momento CI, e poiché riporta errori byte-identici, puoi adottarlo senza indebolire il gate che intercetta i bug reali. È il tipo di cambiamento che ci piace: meno parti mobili, stesse garanzie.

Il test di cinque minuti prima di impegnarti

La parte operativa è piccola e a basso rischio. Prima di riscrivere una singola configurazione CI, esegui il test diff di Bun sul tuo repository:

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

Se il diff è vuoto, i tuoi errori corrispondono e puoi sostituire tsc --noEmit con bun check nella CI con fiducia. Se non è vuoto, hai trovato uno dei rari casi limite, e ora lo sai prima che ti colpisca in un rilascio. Un report di campo ha segnalato un conflitto di nomi da controllare prima: se il tuo package.json definisce già uno script chiamato check, l'esecuzione di bun check all'interno di quella cartella potrebbe eseguire il tuo script invece del type checker, quindi puntalo esplicitamente alla tua configurazione o eseguilo da un'altra directory.

Abbiamo trascorso anni a ottimizzare pipeline di build e test per team web e mobile, da backend PHP e Docker ad app iOS e Android native, e lo schema è sempre lo stesso. La pipeline più veloce è quella che fa meno lavoro, mantiene gli stessi controlli di sicurezza e fallisce in modo rumoroso quando qualcosa si discosta. bun check si adatta a quel profilo per molte configurazioni CI, con la nota onesta che non è adatto a ogni carico di lavoro.

Se un gate di type-check lento nella CI ti suona familiare, parliamone. Aiutiamo i team a velocizzare le loro pipeline di sviluppo senza eliminare i controlli che intercettano davvero i bug.