TypeScript 7 e il compilatore in Go: cosa cambia il 10x di velocità

TypeScript 7 è la riscrittura nativa del compilatore TypeScript in Go, e controlla i tipi dei progetti grandi circa dieci volte più in fretta rispetto all'attuale tsc basato su JavaScript. Stesso linguaggio, stesso sistema di tipi, stessa sintassi. Cambia la macchina sotto: lo strumento che legge il codice e segnala gli errori di tipo ora gira come binario nativo compilato, non più come JavaScript su Node.

Se il team aspetta un tsc --noEmit lento nella CI, o l'editor si blocca un secondo ogni volta che reindicizza un repo grande, questa è la versione che toglie quel costo. Microsoft chiama il progetto Corsa. È uscito come preview installabile nel 2026 ed è il cambiamento più profondo nella toolchain di TypeScript da quando il linguaggio è diventato self-hosted.

La versione in 30 secondi

Microsoft ha portato il compilatore e il language service da TypeScript a Go. Sui benchmark ufficiali il compilatore nativo controlla il codice di Visual Studio Code (1,5 milioni di righe) in circa 7,5 secondi invece di 78, e riduce il tempo di caricamento del progetto nell'editor da circa 9,6 secondi a 1,2, con circa metà della memoria. La toolchain nativa porta il numero di versione 7.0. Il compilatore JavaScript esistente prosegue sulla linea 6.x durante la migrazione. Il controllo dei tipi arriva pronto per la produzione per primo, l'emissione del codice e i project references seguono più avanti nel rilascio.

Perché TypeScript ha riscritto il compilatore in Go

Il compilatore originale è scritto in TypeScript e gira su Node. Fu una scelta voluta: così il team costruiva il linguaggio con il linguaggio stesso, e teneva tutto in un'unica codebase. Il prezzo è la velocità. JavaScript gira su un solo thread per impostazione predefinita, ha garbage collection, e viene compilato JIT all'avvio, quindi un controllo dei tipi a freddo paga il parsing e il riscaldamento a ogni esecuzione. Man mano che le codebase superavano il milione di righe, quel sovraccarico è diventato la lamentela principale.

Go è stato scelto per un motivo preciso, non per moda. Il compilatore esistente si appoggia a strutture dati mutabili condivise e a molta traversata di grafi, che si mappano bene sul modello di memoria di Go e sulle goroutine. Anders Hejlsberg, capo architetto di TypeScript, ha spiegato che il team voleva un linguaggio che permettesse di portare il codice esistente in modo strutturale invece di ridisegnarlo, e la semantica di Go era la più vicina. Una riscrittura in Rust avrebbe significato combattere il borrow checker per riprodurre un compilatore costruito intorno a puntatori condivisi. Con Go il porting è rimasto fedele all'originale, ed è il motivo per cui è arrivato in circa un anno.

Cosa misura davvero il 10x

Il numero in evidenza riguarda il controllo dei tipi e la velocità di build, misurati da Microsoft su progetti reali:

• VS Code (1,5 milioni di righe): da circa 78s a 7,5s, una riduzione di 10,4 volte.
• Caricamento del progetto nell'editor: da circa 9,6s a 1,2s, circa 8 volte.
• TypeORM: da 17,5s a 1,3s.
• Memoria: circa la metà rispetto al compilatore JavaScript sugli stessi progetti.

Due precisazioni tengono onesto il quadro. I guadagni sono massimi sui repository grandi. Un progetto da 5.000 righe non sentirà un salto di 10 volte, perché era già veloce. E il numero riguarda la velocità del compilatore, non l'intera pipeline: se a dominare la CI sono l'installazione delle dipendenze e i test, un controllo dei tipi più rapido riduce una fetta, non il totale.

Cosa cambia per un team di sviluppo

La CI smette di aspettare il controllo dei tipi

Su un monorepo grande, un gate tsc --noEmit prima di push o merge può durare minuti. I team che hanno misurato il compilatore nativo riportano quel controllo scendere da circa cinque minuti a meno di quindici secondi. Il controllo dei tipi smette di essere un passaggio da accorpare e da temere e diventa qualcosa da lanciare a ogni salvataggio.

Gli editor smettono di arrancare sui repo grandi

La parte più lenta quando si lavora su tanto TypeScript non è la compilazione, è il language service: autocompletamento, vai-alla-definizione e sottolineature degli errori che si inceppano mentre il server reindicizza. Il language service nativo riduce i tempi di caricamento e di risposta di un fattore simile, così un repo grande inizia a comportarsi come uno piccolo.

Meno motivi per spezzare una codebase per la velocità

Molti team spezzano un monorepo in pacchetti solo per rendere sopportabile il controllo dei tipi. Quando un singolo controllo di oltre un milione di righe finisce in pochi secondi, quella pressione si allenta. La scelta di architettura torna a riguardare responsabilità e confini, non le prestazioni del compilatore.

Cosa non cambia

Il sistema di tipi è identico. TypeScript 7 è una nuova implementazione, non un nuovo disegno: stessa inferenza, stessi errori, stesso tsconfig.json. Microsoft riporta una compatibilità nel controllo dei tipi superiore al 98% rispetto al compilatore esistente, con una manciata di casi limite tracciati apertamente. Le impostazioni della strict mode e la configurazione attuale passano invariate.

A restare indietro rispetto al controllo dei tipi, durante il rilascio, è stato il resto della toolchain: l'emissione di JavaScript e dei file di dichiarazione, la modalità --build con i project references, e l'insieme completo delle funzioni del language service. Per questo il punto d'ingresso pratico è tsgo --noEmit come controllo dei tipi veloce accanto al tsc esistente per l'emissione, invece di uno scambio totale al primo giorno.

Parte di uno spostamento verso il tooling nativo

TypeScript 7 è un caso di un motivo che attraversa il tooling frontend nel 2026: gli strumenti JavaScript critici per le prestazioni riscritti in un linguaggio compilato. Bundler e linter sono passati a Rust e Go per la stessa ragione del compilatore, perché i carichi di lavoro sono grandi, ripetitivi e parallelizzabili. Per un team il senso è questo: i passaggi di build che prima giustificavano lo spezzare i progetti o il caching aggressivo stanno diventando un ordine di grandezza più veloci da soli. Ne teniamo conto nelle scelte di stack per i progetti nuovi: un controllo dei tipi nativo cambia quanto costa davvero mantenere una superficie TypeScript grande. E si abbina alla disciplina di tenere snello il grafo delle dipendenze, perché un controllo veloce deve comunque leggere tutto ciò che importi.

Quando adottarlo e quando aspettare

Adottalo subito come controllo dei tipi se hai una codebase grande e i tempi di controllo in CI si misurano in minuti. Lancia tsgo --noEmit in parallelo alla build attuale e confronta i due. Il rischio è basso, perché non produce l'output che spedisci. Aspetta prima di renderlo il tuo unico compilatore se dipendi dall'emissione delle dichiarazioni per un pacchetto pubblicato, dai project references per orchestrare la build, o da un'estensione dell'editor non ancora portata. Considera il 2026 l'anno in cui lo aggiungi come controllo veloce, e il ciclo successivo l'anno in cui diventa il default.

Come provarlo oggi

Il compilatore nativo esce come @typescript/native-preview ed espone un binario tsgo. Installalo come dipendenza di sviluppo, poi lancia tsgo --noEmit su un progetto con un tsconfig.json esistente. Dato che legge la stessa configurazione, puoi collegarlo alla CI come job aggiuntivo e tenere il passaggio tsc attuale finché emissione e project references non sono stabili per il tuo caso. C'è un'estensione sperimentale per l'editor sul language service nativo, se vuoi sentire di persona il cambio di reattività.

Dove si colloca nelle scelte di stack

Un controllo dei tipi nativo cambia i conti su alcune scelte vicine. La strict mode costa meno da eseguire, quindi i motivi per rimandarla si riducono. I confini di un monorepo smettono di essere un espediente per le prestazioni e tornano a essere una questione di responsabilità. E l'idea di spezzare un'app grande in servizi solo per tenere veloci le build locali perde forza. Niente di tutto questo è un motivo per riprogettare oggi. È un motivo per smettere di trattare il tempo di controllo dei tipi come un costo fisso quando pianifichi la prossima codebase, perché nel 2026 ha smesso di esserlo.