TypeScript 7 cambia motore

TypeScript 7 nei benchmark Microsoft: tempi di compilazione, limiti del confronto e controlli su editor, API e framework prima della migrazione.

TypeScript 7 porta compiler e language server su una codebase Go nativa e parallela. I vantaggi possono essere notevoli, ma l’adozione va verificata sull’intera toolchain: TypeScript 6 resta necessario per alcuni strumenti basati sulla vecchia API, mentre framework e plugin non sono ancora tutti compatibili.

TypeScript 7 è arrivato l’8 luglio 2026 con una promessa facile da ricordare: un toolset nativo circa dieci volte più veloce. Dietro il numero, però, c’è un cambiamento più profondo. Il compiler e il language server non sono più eseguiti dalla storica codebase TypeScript/JavaScript: sono stati portati in Go, con un’architettura capace di usare codice nativo, memoria condivisa e più thread.

Per sviluppatori e responsabili tecnici, il beneficio è un ciclo di lavoro più rapido: meno attesa per diagnostiche, controlli dei tipi e compilazione. Questo non rende automaticamente più veloce l’applicazione in esecuzione. Prima di migrare occorre verificare anche editor, lint, framework e pipeline CI: sono queste integrazioni a determinare se il nuovo compilatore può entrare davvero nel lavoro quotidiano.

I benchmark: da 7,7 a 11,9 volte più veloce

Nei test pubblicati da Microsoft per il lancio di TypeScript 7, VS Code passa da 125,7 a 10,6 secondi (11,9×), Sentry da 139,8 a 15,7 secondi (8,9×), Bluesky da 24,3 a 2,8 secondi (8,7×), Playwright da 12,8 a 1,47 secondi (8,7×) e tldraw da 11,2 a 1,46 secondi (7,7×).

Il confronto riguarda la compilazione delle codebase indicate, con quattro checker in TypeScript 7. Sono misurazioni del team TypeScript, non test eseguiti da IASolutions: non descrivono la durata dell’intera pipeline né garantiscono lo stesso guadagno su altri progetti. La pagina dell’annuncio non fornisce una metodologia completa per riprodurli.

Un port nativo, non un nuovo linguaggio

Secondo l’annuncio ufficiale di TypeScript 7, il port è stato eseguito in modo fedele alla struttura e alla logica del compiler precedente. Nei full build pubblicati dal team, i miglioramenti tipici si collocano tra 8× e 12× rispetto a TypeScript 6. Il dato descrive test e codebase specifici: non garantisce lo stesso risultato su ogni repository, soprattutto quando il type-checking rappresenta solo una piccola parte della pipeline complessiva.

Il vantaggio non deriva da una formula magica associata a Go. Conta la possibilità di compilare in codice nativo, condividere memoria tra attività concorrenti e ripensare rappresentazioni interne che la vecchia API rendeva difficili da modificare. TypeScript 7 parallelizza parsing, emissione e parte del controllo dei tipi. Il numero predefinito di type checker è quattro, ma può essere regolato: più worker possono ridurre il tempo su progetti grandi, al prezzo di un consumo di memoria superiore.

La misura importante è quindi il tempo di feedback. Un full build più breve aiuta la CI, ma un editor che mostra il primo errore in pochi secondi invece che dopo una lunga attesa cambia il modo in cui si lavora. Per valutare l’impatto servono almeno tre valori separati: controllo completo, ricompilazione incrementale e risposta del language server durante modifiche reali.

Anche la memoria conta

Nello stesso annuncio, Microsoft riporta un uso di memoria aggregata inferiore: VS Code passa da 5,2 a 4,2 GB (−18%), Sentry da 4,9 a 4,6 GB (−6%), Bluesky da 1,8 a 1,3 GB (−26%), Playwright da 1,0 a 0,9 GB (−11%) e tldraw da 0,6 a 0,5 GB (−15%). I valori in GB sono arrotondati; le percentuali sono quelle pubblicate dalla fonte.

Il dato riguarda la compilazione. Per dimensionare un runner CI serve misurare anche il picco di memoria sul proprio progetto: aumentare il numero di checker può ridurre i tempi ma richiedere più RAM.

Il cambiamento arriva anche nell’editor

TypeScript 7 sostituisce il protocollo personalizzato TSServer con il Language Server Protocol, lo standard che permette a editor diversi di riutilizzare lo stesso motore per completamenti, definizioni, riferimenti e diagnostica. È una scelta architetturale, non soltanto prestazionale: separa più nettamente l’intelligenza del linguaggio dall’integrazione specifica dell’IDE.

Anche il watch mode è stato ricostruito su una base multipiattaforma derivata dal file watcher di Parcel. Insieme al supporto LSP, questo sposta il beneficio dal comando occasionale all’intero ciclo di sviluppo. Rimane comunque necessario provare l’editor effettivamente usato dal team: estensioni, auto-import, rename, linguaggi incorporati e plugin possono attraversare percorsi diversi dal semplice `tsc --noEmit`.

La migrazione comincia da TypeScript 6

La release di TypeScript 6 è stata progettata come ponte. Ha reso `strict` il valore predefinito, ha aggiornato target e risoluzione dei moduli e ha deprecato il target ES5, la risoluzione dei moduli node10 e i formati AMD, UMD e SystemJS. In TypeScript 6 molte di queste impostazioni possono ancora essere temporaneamente ignorate; in TypeScript 7 vengono rimosse o trasformate in errori. Eliminare gli avvisi della versione 6 prima dell’upgrade riduce il numero di variabili da diagnosticare.

Per confrontare le diagnostiche e i file di dichiarazione delle due versioni, TypeScript 6 offre inoltre il flag stableTypeOrdering, che allinea l’ordinamento dei tipi a quello della versione 7. Va usato come controllo di compatibilità: può rallentare il type-checking della versione 6, quindi il suo utilizzo deve essere dichiarato quando si misurano le prestazioni. Mantieni separata la baseline della configurazione abituale del progetto.

Controlla anche i default di rootDir e types: percorsi di output e dichiarazioni globali possono richiedere impostazioni esplicite nel tsconfig. Un upgrade che compila non dimostra, da solo, che tutti gli artefatti e gli strumenti si comportino come prima.

La frattura temporanea: l’API programmatica

TypeScript 7.0 non espone ancora una nuova API programmatica stabile. Gli strumenti che importano direttamente il package `typescript` non possono considerare il port nativo un sostituto trasparente. È il caso di parti dell’ecosistema lint e di language service incorporati in Vue, Svelte, Astro, MDX e Angular. Il compiler a riga di comando può essere pronto mentre l’esperienza completa del framework non lo è ancora.

Il repository ufficiale del port nativo documenta questa asimmetria e le differenze intenzionali rispetto a TypeScript 6. Microsoft propone una convivenza controllata: TypeScript 7 per il compiler e, dove serve, il package di compatibilità `@typescript/typescript6` per gli strumenti dipendenti dalla vecchia API. Non è una configurazione da applicare automaticamente, ma una strategia transitoria da verificare sul proprio grafo di dipendenze.

Un’adozione misurata

La migrazione più sicura separa compatibilità e prestazioni. Prima si stabilisce che il progetto produce le stesse diagnostiche e gli stessi artefatti attesi; soltanto dopo si misura il guadagno. Un test limitato al tempo di un singolo comando rischia di nascondere regressioni nell’editor, consumo di memoria sui runner o incompatibilità con strumenti che leggono l’AST.

1. Aggiornare prima a TypeScript 6, rendere espliciti i default rilevanti e risolvere tutte le deprecazioni invece di silenziarle.

2. Registrare una baseline per full type-check, modalità incrementale, memoria di picco e tempo necessario all’editor per mostrare la prima diagnostica.

3. Eseguire TypeScript 7 su un progetto pilota rappresentativo, confrontando l’elenco delle diagnostiche e non soltanto la durata del comando.

4. Inventariare gli strumenti che importano l’API di TypeScript: lint, generatori, transformer, framework, plugin del language server e analisi personalizzate.

5. Prevedere una configurazione reversibile o affiancata finché editor, CI e framework non producono risultati coerenti per l’intero team.

I progetti TypeScript puri, che usano soprattutto la CLI e strumenti già compatibili, possono ottenere benefici prima. Le codebase con template incorporati, transformer personalizzati o una forte dipendenza dall’API del compiler hanno più ragioni per attendere o mantenere le due versioni affiancate. In entrambi i casi, la scelta corretta nasce da un inventario della toolchain, non dalla dimensione del repository presa da sola.

La lezione oltre TypeScript

Guardando al passo successivo, il piano ufficiale di TypeScript 7.1, aperto il 31 luglio 2026, include la stabilizzazione delle API. È una roadmap: non equivale alla disponibilità delle integrazioni e non garantisce che ogni framework sia compatibile al rilascio. Le decisioni operative devono basarsi sulle versioni effettivamente supportate dai propri strumenti.

TypeScript 7 mostra che una riscrittura può preservare la logica del linguaggio e, allo stesso tempo, cambiare profondamente l’esperienza di sviluppo. La velocità ha valore quando accorcia un ciclo affidabile: modifica, diagnostica, verifica e correzione. Se per ottenerla si perde coerenza tra editor e CI, il numero del benchmark smette di rappresentare produttività.

La decisione finale può essere semplice: adottare ora dove il nuovo compiler è già un componente isolato e misurabile; sperimentare in parallelo dove l’ecosistema usa ancora l’API precedente; attendere dove la compatibilità del framework è parte essenziale del lavoro quotidiano. Cambiare motore è utile solo quando tutto il veicolo continua a rispondere nello stesso modo.