
TypeScript 7 è arrivato: il compilatore nativo in Go che compila 10x più veloce (2026)
- vuetelemetry
- Novità
- 8 min di lettura
TypeScript 7.0 riscrive il compilatore in Go e compila circa 10x più veloce - stessi tipi, nuovo motore. Cosa è cambiato, i benchmark reali (VS Code 77,8s a 7,5s), come provare tsc oggi, i breaking change e i compromessi onesti.
TypeScript 7.0 è uscito l'8 luglio 2026, e il titolo è semplice: il compilatore ora è scritto in Go anziché in TypeScript stesso e compila circa 10 volte più velocemente. Per chi mantiene una grande base di codice Vue, Nuxt o React, è il più grande cambiamento del flusso di lavoro quotidiano di TypeScript da anni: non una nuova sintassi, ma un nuovo motore sotto lo stesso comando tsc.
Non cambia nulla nel modo in cui scrivi i tipi. I tuoi file .ts, il tuo tsconfig.json e i tuoi errori di tipo restano identici. Ciò che cambia è la velocità con cui il compilatore analizza, verifica ed emette il tuo progetto, e quanto reattivo risulta il tuo editor mentre lavori. Questa guida copre cosa è cambiato davvero, i numeri reali dei benchmark, come provarlo oggi e i compromessi onesti prima di migrare.
Cosa è cambiato davvero

Il progetto, nome in codice Corsa, è un port più che una riscrittura. Il team di Microsoft, guidato dall'architetto principale di TypeScript Anders Hejlsberg, ha trasferito in Go gli algoritmi e le strutture dati esistenti affinché il comportamento della verifica dei tipi resti identico: la stessa inferenza, gli stessi errori. Go è stato preferito a Rust soprattutto perché gli alberi di sintassi e le tabelle dei simboli di TypeScript si basano su riferimenti ciclici, che si sposano molto meglio con il garbage collector e le goroutine di Go che con le regole di ownership di Rust.
La velocità nasce da due fattori. Il codice nativo compilato è semplicemente più rapido del vecchio compilatore scritto in JavaScript, e il nuovo compilatore lavora in parallelo: analisi, verifica dei tipi ed emissione possono avvenire su più thread invece che su uno solo. L'uso di memoria cala di circa la metà rispetto al compilatore JavaScript, e il servizio di linguaggio dell'editor carica i progetti grandi molto più in fretta.
La velocità, in numeri reali
Microsoft ha pubblicato numeri prima e dopo su progetti reali. Compilare la base di codice di VS Code (circa 1,5 milioni di righe) è passato da 77,8 secondi a 7,5 secondi, un miglioramento di 10,4x. Playwright ha compilato circa 10x più velocemente e TypeORM circa 13,5x. Sono build complete e pulite, quelle che dominano il tempo di CI e rallentano le verifiche dei tipi in locale sui repository grandi.
- TypeScript 7.0 (uscito l'8 luglio 2026) sostituisce il compilatore scritto in JavaScript con un port nativo scritto in Go: stessi tipi, nuovo motore
- Build complete circa 10x più rapide (VS Code 77,8s a 7,5s), caricamento del progetto nell'editor circa 8x più rapido e circa 50% di memoria in meno
- È un port (nome in codice Corsa) guidato da Anders Hejlsberg: comportamento di verifica dei tipi identico, ora parallelizzato su più thread
- Si installa e si esegue come tsc; le anteprime notturne usano ancora il nome tsgo sotto @typescript/native-preview
- Breaking change: target es5, modalità di risoluzione node, baseUrl e AMD/UMD/SystemJS rimossi; alcuni valori predefiniti (rootDir, types) cambiati
- Gli strumenti sull'API programmatica (typescript-eslint, ts-morph, transformer) attendono una versione 7.x successiva: per ora adottalo in parallelo
I guadagni nell'editor contano altrettanto ogni giorno. Caricare un progetto grande nel servizio di linguaggio è sceso da circa 9,6 secondi a 1,2 secondi, circa 8x. È la differenza tra aspettare che IntelliSense si svegli e avere completamento automatico, vai-alla-definizione e sottolineatura degli errori che rispondono quasi all'istante su una base di codice che prima sembrava lenta.
Come provarlo oggi
L'installazione è volutamente banale: il compilatore nativo si installa dal pacchetto abituale e si esegue come tsc, quindi la maggior parte dei progetti può provarlo con un solo aggiornamento di dipendenza. Le anteprime precedenti fornivano un binario tsgo separato, e le build notturne sono ancora pubblicate sotto @typescript/native-preview con quel nome, ma la release vera e propria è semplicemente tsc. Nuovi flag permettono di regolare il parallelismo, per esempio il numero di worker di verifica, o di disattivarlo con una modalità a thread singolo quando serve un output seriale riproducibile.
Un modo sicuro di adottarlo è affiancarlo. Puoi tenere installato il precedente compilatore 6.x sotto un alias (spesso invocato come tsc6) mentre punti la tua build principale alla 7.0. Così usi il nuovo compilatore veloce per build ed editing, mentre qualsiasi strumento che dipende ancora dalla vecchia API programmatica stabile continua a funzionare senza modifiche.
Breaking change da tenere d'occhio
Ci sono veri breaking change, quindi leggi le note di rilascio prima di aggiornare sul posto. Diverse opzioni deprecate da tempo spariscono, tra cui il target es5, la vecchia modalità di risoluzione dei moduli node, baseUrl e i formati di modulo AMD, UMD e SystemJS. Cambiano anche alcuni valori predefiniti, come rootDir e l'insieme predefinito di pacchetti di tipi ambient, cosa che può far emergere nuovi errori in configurazioni che si affidavano al vecchio comportamento implicito.
I compromessi, in tutta onestà
Il guadagno di velocità è reale, ma l'ecosistema ha bisogno di un momento per adeguarsi. Gli strumenti costruiti sull'API programmatica di TypeScript (typescript-eslint, ts-morph, transformer di compilatore personalizzati) dipendono da interfacce che si stabilizzeranno solo in una versione 7.x successiva. Fino ad allora, i team che si appoggiano molto a questi strumenti potrebbero voler usare la 7.0 per build ed editing mantenendo disponibile la linea 6.x per le parti della toolchain non ancora pronte.
Vale anche la pena mantenere aspettative realistiche: TypeScript 7 rende più veloce il compilatore, non la tua app in produzione. L'output è sempre lo stesso JavaScript che gira negli stessi browser e versioni di Node, quindi le prestazioni a runtime non cambiano. Ciò che ottieni sono tempi di build e di CI più brevi e un editor più scattante, che su una grande base di codice front-end è esattamente dove stava l'attrito. Per la maggior parte dei team Vue, Nuxt e React la mossa pratica è provarlo su un branch, tenere d'occhio le opzioni rimosse e adottarlo per build ed editor una volta che i numeri tornano.



Ci sono veri breaking change, quindi leggi le note di rilascio prima di aggiornare sul posto. Diverse opzioni deprecate da tempo spariscono, tra cui il target es5, la vecchia modalità di risoluzione dei moduli node, baseUrl e i formati di modulo AMD, UMD e SystemJS. Cambiano anche alcuni valori predefiniti, come rootDir e l'insieme predefinito di pacchetti di tipi ambient, cosa che può far emergere nuovi errori in configurazioni che si affidavano al vecchio comportamento implicito.