Skip to content
Tutti gli articoli

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

, , 3 min di lettura

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.

Condividi

Hai un progetto in mente?

Raccontaci di cosa hai bisogno. Rispondiamo entro un giorno lavorativo.