TypeScript 7.0: il compilatore in Go e la fine delle build lente

Il compilatore nativo in Go è arrivato l'8 luglio: build complete da 8 a 12 volte più veloci e primo errore in editor dopo 1,3 secondi invece di 17,5. I benchmark, i breaking change e come pianificare la migrazione.

Microsoft ha rilasciato TypeScript 7.0 l'8 luglio 2026, tre settimane dopo la release candidate del 18 giugno. È il porting nativo del compilatore in Go e sostituisce il codebase JavaScript, chiuso con TypeScript 6.0 il 23 marzo 2026. Per una volta il business case di un upgrade è aritmetica e non opinione: il typecheck passa da minuti a secondi. Il che non vuol dire che sia gratis.

I numeri, che stavolta contano

I benchmark pubblicati da Microsoft sono build complete di progetti veri: VS Code da 125,7 a 10,6 secondi (11,9x), Sentry da 139,8 a 15,7 (8,9x), Bluesky da 24,3 a 2,8 (8,7x), Playwright da 12,8 a 1,47 (8,7x), Tldraw da 11,2 a 1,46 (7,7x). La memoria di picco cala tra il 6% e il 26%: su VS Code da 5,2 a 4,2 GB.

Il dato che cambia davvero la giornata però non è quello della CI. Nel codebase di VS Code, aprire un file con un errore richiedeva circa 17,5 secondi prima che comparisse il primo errore; ora ne servono 1,3. Il language server segna oltre l'80% in meno di comandi falliti e oltre il 60% in meno di crash. Un feedback quasi immediato cambia come si scrive il codice, non solo quanto si aspetta.

Perché il conto torna anche su un progetto piccolo

Obiezione ricorrente: il nostro monorepo non è VS Code. Vero, ma il guadagno è moltiplicativo, non assoluto. Nei progetti che manteniamo il typecheck è quasi sempre lo step più lento della pipeline dopo i test, e gira ad ogni push. Dividere per otto quel tempo vuol dire minuti di attesa e di runner fatturati risparmiati ogni giorno. È una delle rarissime voci di costo che cala senza toccare una riga di codice applicativo.

Dove l'upgrade si paga

strict attivo di default: su un codebase che non l'ha mai avuto, l'aggiornamento fa emergere errori reali e preesistenti, non falsi positivi. Quanti siano si scopre solo lanciando il compilatore.
types ora vale []: i pacchetti @types non vengono più caricati tutti in automatico. Le dipendenze di tipi implicite vanno dichiarate una per una.
Opzioni rimosse: il target es5, i moduli AMD, UMD e SystemJS, la module resolution classic e baseUrl non esistono più, e il compilatore si ferma con un errore invece di avvisare. Cambiano anche i default di module (esnext) e rootDir (./).
API del compilatore assente: la 7.0 non espone l'API programmatica pubblica, attesa con la 7.1. typescript-eslint, Vue, Svelte, Astro, MDX e il type-checking dei template Angular per ora non ci girano sopra. Il pacchetto @typescript/typescript6 installa un binario affiancato per il periodo intermedio.

Come lo stiamo pianificando

Progetti nuovi: TypeScript 7 dal primo commit, i default nuovi sono quelli giusti. Progetti React o Next.js esistenti: si può fare adesso, su un branch dedicato, contando le ore per svuotare gli errori di strict prima di prendere impegni. Progetti Vue, Svelte o Astro: si aspetta la nuova API, punto.

Verdetto

Fatelo, e mettetelo a calendario. Un fattore otto sul typecheck non capita due volte nella vita di un progetto, e la latenza dell'editor da sola ripaga la giornata. Ma è una migrazione, non un bump di versione: pianificatela per il Q4, su un branch, con qualcuno che sistemi gli errori di strict. Non il venerdì pomeriggio.