Bun 1.4.3 vine cu un verificator de tipuri mai rapid decât tsc. Iată unde câștigă și unde nu.

Bun 1.4.3 a apărut pe 10 octombrie, iar funcționalitatea principală este bun check, un verificator de tipuri TypeScript integrat direct în binarul Bun. Citește tsconfig.json-ul existent, raportează aceleași erori ca tsc și folosește toate nucleele procesorului. Nu ai nevoie de pachetul typescript instalat. Pe propriile benchmark-uri ale Bun, rulate pe un Mac Apple silicon cu 16 nuclee, verificarea tipurilor se finalizează de 3-6,4 ori mai rapid decât tsc 7.0.2, folosind de 2,2-4,9 ori mai puțină memorie. Directorul src al VS Code, cu aproape 10.000 de fișiere, a scăzut de la 5,98 secunde la 1,24 secunde.

Povestea despre acuratețe este cea care ne-a atras atenția. bun check este un port al typescript-go, rescrierea compilatorului în Go de la Microsoft, și trece toate cele 51.210 teste din suita de conformanță TypeScript 7.0.2. Bun l-a rulat și împotriva a 72 de proiecte open-source și a comparat ieșirile cu tsc pe 1.103 configurații. S-a potrivit pe 1.102 dintre ele. Singura nepotrivire a fost o eroare în vuejs/core. O reimplementare a unui sistem de tipuri notoriu de pretențios care corespunde originalului aproape peste tot este rară și acesta este motivul pentru care merită să fie luată în serios, nu clasată drept „un alt instrument rapid, dar incorect.“

Deci ar trebui să faci tranziția? Iată varianta sinceră, deoarece cifrele din benchmark-uri ascund o capcană importantă.

Fără mod incremental — și de ce asta decide totul

bun check nu păstrează nicio stare între rulări. Nu scrie niciun fișier .tsbuildinfo, deci fiecare rulare este una rece. Exact de aceea câștigă pe runner-ele CI și checkout-urile proaspete, care pornesc mereu de la zero oricum, și tot de aceea tsc îl poate bate în continuare pe laptop.

Testatori independenți au confirmat ambele aspecte. Scrydon și-a mutat gate-ul de verificare a tipurilor din monorepo pe el, iar o verificare completă rece a 104 proiecte a scăzut de la 124,9 secunde la aproximativ 51-68 de secunde, cu vârful de memorie redus cu aproximativ o treime. Dar la o re-verificare cu cache cald după o modificare de un rând, modul incremental al tsc a răspuns în 0,81 secunde față de 1,57 ale bun check. Pe un proiect mic, configurația de build Hono cu 188 de fișiere, tsc a fost de fapt mai rapid, deoarece bun check plătește un cost fix de pornire pentru încărcarea fișierelor lib înainte de a verifica ceva.

Din experiența noastră, acest lucru se mapează clar pe unde îi este locul. Când construim servicii PHP și Node cloud-native pentru clienți enterprise, pasul de verificare a tipurilor în CI este adesea cel mai lent gate din pipeline și este aproape întotdeauna o rulare rece pe un container proaspăt. Acesta este punctul forte. Reducerea acelui pas la jumătate, cu erori identice și memorie mai mică, este un câștig real și înseamnă că echipele pot renunța la limitarea concurenței la verificarea tipurilor doar pentru a evita consumarea RAM-ului unui runner. Pe mașina unui dezvoltator, unde cineva reverifikă același pachet în buclă, tsc-ul cald rămâne instrumentul mai bun. Acestea nu sunt afirmații contradictorii. Ele descriu două sarcini de lucru diferite.

Nu înlocuiește TypeScript în editorul tău

Un lucru de clarificat: bun check nu face nicio lucrare de language server, deci autocompletarea și go-to-definition rulează în continuare pachetul typescript pe care editorul tău îl folosește deja. De asemenea, el doar verifică. Nu emite JavaScript și nici fișiere .d.ts, deci dacă publici o bibliotecă ai în continuare nevoie de tsc pentru a genera declarații. Tratează-l ca pe un gate CI mai rapid, nu ca pe un înlocuitor complet.

Există și un unghi de securitate care merită menționat. În activitățile noastre de pentesting, vedem în continuare riscul supply-chain strecurându-se prin tooling-ul de build pe care nimeni nu îl auditează. bun check nu necesită nicio instalare typescript în pasul de verificare — o dependență mai puțin rezolvată la momentul CI — și, deoarece raportează erori identice byte cu byte, îl poți adopta fără a slăbi gate-ul care prinde bug-urile reale. Acesta este tipul de schimbare care ne place: mai puține componente mobile, aceleași garanții.

Testul de cinci minute înainte de a te angaja

Partea acțională este mică și cu risc redus. Înainte de a rescrie un singur config CI, rulează propriul test diff al Bun pe repo-ul tău:

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

Dacă diff-ul este gol, erorile tale se potrivesc și poți înlocui tsc --noEmit cu bun check în CI cu încredere. Dacă nu este gol, ai găsit unul dintre cazurile marginale rare și acum știi înainte să te muște într-un release. Un raport de teren a semnalat un conflict de denumire care merită verificat mai întâi: dacă package.json-ul tău definește deja un script numit check, rularea bun check în acel director poate rula scriptul tău în loc de verificatorul de tipuri, deci indică-i explicit config-ul sau rulează-l din alt director.

Am petrecut ani întreagi ajustând pipeline-uri de build și testare pentru echipe web și mobile, de la backend-uri PHP și Docker la aplicații native iOS și Android, și modelul este întotdeauna același. Cel mai rapid pipeline este cel care face mai puțin, păstrează aceleași verificări de siguranță și eșuează zgomotos când ceva derivă. bun check se potrivește acestui scop pentru multe configurații CI, cu asteriscul sincer că nu este potrivit pentru orice sarcină de lucru.

Dacă un gate lent de verificare a tipurilor în CI sună familiar, hai să vorbim. Ajutăm echipele să accelereze pipeline-urile de dezvoltare fără a elimina verificările care prind cu adevărat bug-uri.