TypeScript 7.0 e de 10 ori mai rapid și scris în Go. Cum îl adopți fără să strici CI-ul.

Microsoft a publicat Release Candidate-ul TypeScript 7.0 pe 18 iunie 2026, iar noutatea nu este o sintaxă nouă. Este compilatorul însuși. În ultimul an, echipa a portat TypeScript din propriul codebase JavaScript bootstrapped în Go, iar rezultatul verifică tipurile de aproximativ 10 ori mai rapid decât TypeScript 6.0. Cifrele publicate sunt clare: codebase-ul VS Code, de aproximativ 1,5 milioane de linii, coboară de la o verificare de tip de 77,8 secunde la 7,5 secunde. Sentry trece de la 133 de secunde la 16. Pornirea editorului scade de la aproximativ 9,6 secunde la 1,2, iar utilizarea memoriei este redusă la aproximativ jumătate.

Două detalii contează mai mult decât viteza brută. În primul rând, aceasta este o portare, nu o rescrie completă. Echipa a mutat logica existentă de verificare a tipurilor în Go și a păstrat semantica, deci 7.0 ar trebui să aplice aceleași reguli pe care codul tău le trece deja sub 6.0. În al doilea rând, îl instalezi ca orice altă versiune, direct din pachetul typescript de pe npm. O versiune stabilă este planificată pentru aproximativ o lună, iar regresiile merg la repository-ul microsoft/typescript-go în locul celui principal TypeScript.

Deci ce câștigă concret o echipă cu un compilator de 10 ori mai rapid? Mai mult decât pare la prima vedere.

Câștigul nu e laptopul tău, ci CI-ul

Un editor mai rapid este plăcut. Un CI mai rapid schimbă modul în care oamenii lucrează. Când construim aplicații cloud-native pentru clienți enterprise pe PHP și Docker, verificarea tipurilor este de obicei una dintre cele mai lente gate-uri din pipeline și se află pe calea critică pentru fiecare merge. A reduce un check de două minute la cincisprezece secunde nu economisește doar două minute. Schimbă comportamentul. Developerii încetează să grupeze modificările pentru a evita pipeline-ul lent, reviewerii primesc un check verde cât contextul este încă proaspăt, iar obiceiul de „merge și urmăresc CI-ul” care strică în liniște branch-ul main începe să dispară.

Am văzut echipe care și-au construit fluxul de lucru în jurul instrumentelor lente fără să realizeze că o fac: pull request-uri gigantice, checks locale omise, un reflex --no-verify la fiecare commit. Cea mai mare parte este un răspuns la feedback care durează prea mult. Elimină așteptarea și multe dintre aceste obiceiuri își pierd motivul de a exista.

Un compilator mai rapid rămâne tot o schimbare de dependență

Iată ce se pierde în entuziasmul general. A schimba compilatorul cu un binar scris într-un alt limbaj este o decizie de supply-chain, nu un câștig gratuit. În cadrul muncii noastre de pentesting și security review, toolchain-ul de build este unul dintre primele locuri la care ne uităm, deoarece rulează cu acces deplin la sursă și adesea la secretele tale, pe fiecare mașină de developer și fiecare runner CI. Un nou tsc este exact acest tip de componentă.

Nimic din toate acestea nu înseamnă că RC-ul este riscant de încercat. Microsoft îl rulează pe codebase-uri de mai multe milioane de linii, în interiorul și în afara companiei, de peste un an. Înseamnă că ar trebui să îl adopți intenționat: pinuiește versiunea exactă, citește changelog-ul înainte să îl actualizezi și nu lăsa un singur inginer să schimbe compilatorul pentru toată echipa vineri după-amiaza.

Ce să faci săptămâna aceasta

Nu face din 7.0 gate-ul tău CI blocant deocamdată. Adaugă-l lângă cel pe care îl ai deja. Majoritatea sistemelor CI îți permit să rulezi un al doilea job care compilează cu typescript@rc și raportează rezultatul fără să blocheze merge-ul. Rulează ambele câteva săptămâni, compară erorile și vei ști exact unde 7.0 nu este de acord cu build-ul tău actual înainte ca asta să conteze. Deoarece este o portare și nu o rescrie, majoritatea echipelor descoperă că diferența este nulă, dar puținii care lovesc un edge case vor vrea să îl găsească în propriul ritm, nu în timpul unui upgrade grăbit după ce versiunea stabilă apare.

Acest pattern nu este specific TypeScript. Folosim aceeași abordare shadow pentru tot ce facem pe web și mobile ori de câte ori un instrument de bază lansează o versiune majoră. Efectuăm un bump de Xcode sau Android Gradle Plugin în proiectele noastre native iOS și Android în același mod, într-un job paralel, cu mult înainte ca acesta să ajungă pe mașinile tuturor. Echipele care au de suferit sunt de obicei cele care citesc „testele trec în continuare” ca dovadă că nimic nu s-a schimbat. Dacă vrei să înțelegi cum gestionăm asta în practică, munca noastră de development este construită exact în jurul acestui tip de upgrade staged, fără dramă.

Dacă un pipeline lent pe care echipa ta a învățat în tăcere să îl ocolească îți sună familiar, hai să vorbim.