TypeScript 7.0 è 10 volte più veloce e scritto in Go. Ecco come adottarlo senza rompere la CI.
Microsoft ha pubblicato il Release Candidate di TypeScript 7.0 il 18 giugno 2026, e il titolo principale non riguarda una nuova sintassi. Riguarda il compilatore stesso. Nell'ultimo anno il team ha portato TypeScript dalla propria codebase JavaScript in Go, e il risultato controlla i tipi circa 10 volte più velocemente di TypeScript 6.0. I numeri pubblicati sono netti: la codebase di VS Code, circa 1,5 milioni di righe, scende da un controllo dei tipi di 77,8 secondi a 7,5 secondi. Sentry passa da 133 secondi a 16. L'avvio dell'editor scende da circa 9,6 secondi a 1,2, e l'utilizzo della memoria è circa dimezzato.
Due dettagli contano più della velocità grezza. Primo, si tratta di un porting, non di una riscrittura da zero. Il team ha trasferito la logica di controllo dei tipi esistente in Go mantenendo la semantica, quindi 7.0 dovrebbe applicare le stesse regole che il tuo codice già supera sotto 6.0. Secondo, lo si installa come qualsiasi altra release, direttamente dal pacchetto typescript su npm. Una release stabile è prevista per circa un mese, e le regressioni vanno al repository microsoft/typescript-go anziché a quello principale di TypeScript.
Dunque cosa porta concretamente a un team un compilatore 10 volte più veloce? Più di quanto sembri a prima vista.
Il vantaggio non è il tuo laptop, è la CI
Un editor più veloce è piacevole. Una CI più veloce cambia il modo in cui si lavora. Quando costruiamo app cloud-native per clienti enterprise su PHP e Docker, il controllo dei tipi è di solito uno dei gate più lenti nella pipeline, e si trova sul percorso critico per ogni singolo merge. Ridurre un controllo di due minuti a quindici secondi non fa solo risparmiare due minuti. Cambia i comportamenti. Gli sviluppatori smettono di raggruppare le modifiche per evitare la pipeline lenta, i reviewer ottengono una spunta verde quando il contesto è ancora fresco, e l'abitudine di «faccio il merge e aspetto la CI» che spezza silenziosamente il main comincia a svanire.
Abbiamo visto team architettare attorno a strumenti lenti senza rendersene conto: pull request enormi, controlli locali saltati, un riflesso --no-verify su ogni commit. La maggior parte è una risposta a feedback che arriva troppo tardi. Togli l'attesa e molte di quelle abitudini perdono la loro ragione di esistere.
Un compilatore più veloce rimane comunque una modifica a una dipendenza
Ecco la parte che si perde nell'entusiasmo. Sostituire il compilatore con un binario scritto in un linguaggio diverso è una decisione sulla supply chain, non un guadagno gratuito. Nel nostro lavoro di pentesting e security review, la toolchain di build è uno dei primi posti che guardiamo, perché viene eseguita con accesso completo al tuo sorgente e spesso ai tuoi segreti, su ogni macchina dello sviluppatore e ogni runner CI. Un nuovo tsc è esattamente quel tipo di componente.
Niente di tutto ciò significa che il RC sia rischioso da provare. Microsoft lo esegue su codebase da milioni di righe all'interno e all'esterno dell'azienda da oltre un anno. Significa che dovresti adottarlo intenzionalmente: fissa la versione esatta, leggi il changelog prima di aggiornarlo, e non lasciare che un singolo ingegnere sostituisca silenziosamente il compilatore per l'intero team il venerdì pomeriggio.
Cosa fare questa settimana
Non rendere ancora 7.0 il tuo controllo CI bloccante. Aggiungilo accanto a quello che hai già. La maggior parte dei sistemi CI permette di eseguire un secondo job che compila con typescript@rc e riporta il risultato senza bloccare il merge. Eseguili entrambi per un paio di settimane, confronta gli errori, e saprai esattamente dove 7.0 non è d'accordo con la tua build attuale prima che diventi un problema. Poiché si tratta di un porting piuttosto che di una riscrittura, la maggior parte dei team trova che il diff è vuoto, ma i pochi che incappano in un caso limite vorranno trovarlo secondo i propri tempi, non durante un aggiornamento frettoloso dopo l'arrivo della release stabile.
Questo approccio non è specifico di TypeScript. Usiamo lo stesso approccio shadow in tutto il nostro lavoro web e mobile ogni volta che uno strumento core rilascia una versione major. Gestiamo un bump di Xcode o Android Gradle Plugin nei nostri progetti iOS e Android nativi allo stesso modo, in un job parallelo, molto prima che tocchi la macchina di tutti. I team che vengono bruciati di solito sono quelli che leggono «i test passano ancora» come prova che nulla è cambiato. Se vuoi un'idea di come lo gestiamo in pratica, il nostro lavoro di sviluppo è costruito esattamente attorno a questo tipo di aggiornamento graduale e senza drammi.
Se una pipeline lenta attorno a cui il tuo team ha silenziosamente imparato a lavorare ti suona familiare, parliamone.