TypeScript 7 e 7.1: cosa cambia con il compilatore nativo

TypeScript 7.0 è uscito ad agosto 2026 ed è la release più importante nella storia del progetto — ma non per una nuova sintassi. Il compilatore stesso è stato riscritto da zero in Go, sostituendo la base di codice TypeScript-compila-se-stesso che esisteva da oltre un decennio. Il risultato principale non è “puoi scrivere questo tipo di codice che prima non potevi”, ma “lo stesso identico codice ora tipizza 8-10 volte più veloce”.

Perché riscrivere il compilatore in Go

Il vecchio tsc è scritto in TypeScript e gira su Node.js: single-thread, con overhead della VM JavaScript e garbage collector generico. Il team, guidato da Anders Hejlsberg, ha portato l’intera logica del compilatore in Go, mantenendo per quanto possibile la stessa struttura interna. Il progetto è nato nel 2025 con nome in codice “Corsa” e distribuito come preview sotto il pacchetto @typescript/native-preview (il binario si chiamava tsgo). Con la 7.0 RC, quel compilatore nativo è diventato il tsc standard dentro il pacchetto typescript.

Due vantaggi concreti di Go rispetto a JavaScript per questo caso d’uso: codice nativo compilato invece che interpretato/JIT, e parallelismo reale a memoria condivisa — cosa che Node.js con il suo modello single-thread non può offrire senza il costo della serializzazione tra processi.

I numeri: 8-12x più veloce su progetti reali

Non sono benchmark sintetici. Sono build complete di progetti open source noti, confrontando TypeScript 6 con TypeScript 7:

Progetto	TS 6	TS 7	Speedup
VS Code	125,7s	10,6s	11,9x
Sentry	139,8s	15,7s	8,9x
Bluesky	24,3s	2,8s	8,7x
Playwright	12,8s	1,47s	8,7x
tldraw	11,2s	1,46s	7,7x

L’uso di memoria è calato anch’esso, tra il 6% e il 26% a seconda del progetto. L’apertura di file nell’editor è fino a 13 volte più rapida, e Microsoft riporta impatti concreti in produzione: Slack ha ridotto il type-check in CI da 7,5 a 1,25 minuti, Canva è passata da 58 a 4,8 secondi per il primo errore mostrato in editor.

💡 Consiglio

Il parallelismo si controlla con due nuovi flag: --checkers N (worker di type-checking in parallelo, default 4) e --builders N (build parallela dei project reference, utile nei monorepo). --singleThreaded disattiva tutto — comodo per il debug o in ambienti con risorse limitate.

I breaking change: nuovi default, non solo velocità

Qui sta la parte che richiede attenzione prima di aggiornare un progetto esistente. TypeScript 7.0 cambia diversi default storici:

strict: true di default (prima era false)
module: esnext di default
noUncheckedSideEffectImports: true di default
types: [] di default — non vengono più inclusi automaticamente tutti i pacchetti @types presenti in node_modules
rootDir di default punta alla root del progetto

Sono state anche rimosse del tutto alcune opzioni legacy: target: es5, downlevelIteration, i moduli amd/umd/systemjs, e baseUrl. Se il tuo tsconfig.json si appoggia a una di queste, il passaggio a 7.0 richiede una migrazione, non solo un aggiornamento di versione.

C’è anche un breaking change più sottile nella gestione Unicode dei template literal: emoji e caratteri multi-byte ora vengono trattati come singole unità invece che come coppie surrogate UTF-16. "😀abc" ora si divide correttamente in ["😀", "abc"], non a metà dell’emoji.

Cosa manca ancora: l’API programmatica

Il limite più rilevante di questa prima release nativa: TypeScript 7.0 non espone ancora un’API programmatica stabile. È un problema concreto per tutto ciò che si appoggia al compilatore per analizzare codice non-.ts — Vue (Volar), Svelte, Angular template, e sì, anche .astro come in questo stesso blog. Questi strumenti non possono ancora migrare a 7.0 e restano per ora sul compilatore JavaScript classico.

Per chi ha bisogno di far convivere i due compilatori durante la transizione, Microsoft suggerisce questo pattern nel package.json:

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

TypeScript 7.1: cosa arriva a novembre 2026

Al momento in cui scrivo, 7.1 non è ancora uscito: la beta è prevista per il 6 ottobre 2026 e la stable per il 24 novembre 2026. Dal piano di iterazione pubblicato dal team, i punti principali sono:

Stabilizzazione delle API: Content Mapper API, Emit API e Language Service API diventano stabili — è il pezzo che manca oggi e che sblocca la migrazione degli strumenti che processano .vue, .astro e simili.
Supporto a type sugli import attribute e ai source phase import.
es2026 come nuova opzione per lib e target.
Aggiornamenti a lib.d.ts per i nuovi metodi degli iterator e per il DOM, incluse Promise.allKeyed e Promise.allSettledKeyed.
Ulteriori ottimizzazioni di performance: costruzione dei tipi union più veloce, narrowing più rapido su assegnazioni e uguaglianze.

In sintesi: 7.0 è il salto infrastrutturale (stesso linguaggio, motore nuovo), 7.1 è il rilascio che completa l’ecosistema attorno — l’API che mancava, più qualche allineamento alle nuove feature JavaScript.

Conviene aggiornare adesso?

Se il tuo progetto è puro TypeScript/JavaScript, senza dipendenze da tool basati su API programmatica del compilatore, il salto a 7.0 vale già la pena solo per i tempi di build — soprattutto su una codebase grande o in CI. Se invece il tuo stack include framework che processano file non-standard (Vue, Astro, Svelte) tramite plugin che si appoggiano al compiler API, conviene aspettare 7.1 e la stabilizzazione della Language Service API prima di forzare la migrazione.

In entrambi i casi, vale la pena rivedere il proprio tsconfig.json prima di aggiornare: i nuovi default (strict, module: esnext, types: []) possono far comparire errori che con TypeScript 6 restavano silenziosi.

Se lavori spesso con configurazioni di oggetti tipizzati, può interessarti anche l’articolo sull’operatore satisfies, un’altra feature del linguaggio pensata per casi analoghi di inferenza precisa.