TypeScript 7 fik en native compiler i Go — så målte vi den

TypeScript 7 blev udgivet — og det er ikke en almindelig minor. Microsoft har porteret TypeScript-compileren og language services fra TypeScript til en ny native implementering i Go, med et mål om ~10× hurtigere typecheck. Samtidig udkom en Next.js preview der kan bruge den.

Så jeg gjorde det oplagte: bad Claude om at måle det på min egen kodebase. Ikke et syntetisk benchmark — den rigtige www-site (Next.js, ~4.200 filer), før og efter, på den samme maskine.

Det her indlæg er to dele. Første del er tallene — hvad Go-compileren faktisk gav os. Anden del er hvordan vi lavede målingen — de præcise prompts fra sessionen, så du kan gøre det samme.

Del 1 — Tallene

Kort version: typecheck blev ~10× hurtigere, og fordi typecheck er den tungeste fase i vores next build, faldt hele produktionsbygget fra 116 sekunder til 72 — uden at ændre en eneste linje runtime-kode.

Detaljerne bag søjlerne:

• Ren compiler (tsc --noEmit, koldt): total tid ~31,5s → ~3,0s (~10,5×), selve check-fasen 26s → 2,2s (~11,6×).
• Typecheck inde i bygget (next build, linjen "Finished TypeScript in …"): 33,7s → 4,0s (8,4×).
• Fuld npm run build wall clock: 116,4s → 71,6s — −44,8s, ~38% hurtigere. Compile-fasen (~36s) og static-generation (~5s) rørte sig ikke; hele deltaet er typecheck der kollapser.

En detalje jeg ikke havde ventet

Go-compileren kom med en nyere lib.dom.d.ts, og den fangede tre ægte type-fejl som TypeScript 5.8 havde accepteret i tavshed — Node's Buffer / Uint8Array var ikke længere implicit tildelbar til web-typerne BodyInit / BufferSource. Tre rigtige steder i produktionskoden (to route-handlers og en PWA-komponent). De er fikset og er værd at lande uanset TS7-beslutningen.

Hurtigere og strengere. Det er en sjælden kombination.

Og loadtesten?

Den oprindelige idé var en før/efter loadtest. Den kørte jeg bevidst ikke — resultatet er givet på forhånd: den ville vise nul forskel. Vores tsconfig.json har noEmit: true, så tsc producerer ikke JavaScript overhovedet; Next.js transpilerer med SWC/Turbopack, som er fuldstændig uafhængig af tsc. De sendte bundles er byte-for-byte de samme, uanset om TS5 eller TS7 tjekkede typerne. TS7's gevinst er 100% udvikler- og CI-gennemløb: typecheck, next build, editor-responsivitet, pre-commit- og CI-gates. Ikke runtime.

Det er den ærlige overskrift: TypeScript 7 gør bygningen hurtig, ikke appen. Men når typecheck falder fra 34 til 4 sekunder på hver eneste CI-kørsel og hver eneste commit, mærker du det hver dag.

Opskriften (den korte)

Det er stadig preview-software — vent på en stabil Next 16.3 før du læner dig på det i CI — men det virker i dag:

• typescript@7.0.2 (den native Go-tsc)
• next@16.3.0-preview.6
• experimental.useTypeScriptCli: true i next.config.ts (PR vercel/next.js#95639 — TS7 droppede JS-API'et, så Next kalder tsc som CLI)

Én gotcha: en version-pinnet patch-package-patch på Next skal flyttes til side eller regenereres for preview-versionen, ellers fejler postinstall.

Del 2 — Sådan lavede vi målingen

Det interessante er ikke kun tallene — det er hvor lidt der skulle til for at producere dem. Hele spiket var to prompts.

Den første satte rammen: worktree, isoleret, valider først at appen overhovedet bygger med TS7, mål derefter.

Bemærk to ting i den prompt. For det første: "in a worktree" — spiket kører i en isoleret git worktree, så hverken versionsbump eller den flyttede patch rører min rigtige checkout. For det andet: "First step would be to validate" — en eksplicit gate. Ikke "byg et benchmark", men "bevis at det virker, så mål". Den gate er grunden til at tallene er til at stole på: målingen blev kørt seriel på en ellers tom maskine (upgrade → mål → downgrade → mål i den samme worktree), aldrig parallelt — parallelle arme ville have forurenet timingen.

Da valideringen var grøn og tallene lå fast, kom anden prompt — den der bad om netop det her indlæg:

Det er hele lineage'en. Prompten du lige læste er grunden til at Del 1 åbner med en graf, og til at Del 2 citerer sig selv verbatim — inklusive supprot, diffrence og implmentation. Teksturen er pointen; jeg renser den ikke.

Målemetoden, konkret

Ingen magi — bare disciplin om at måle det samme to gange. Fra src/apps/www-site:

# Baseline (TypeScript 5.8, JS-compiler)
npm ci
npx tsc --noEmit --extendedDiagnostics        # ~32s total, ~26s check

# → TypeScript 7 (native Go-compiler)
#   next.config.ts: experimental.useTypeScriptCli: true
#   flyt den version-pinnede patch til side så patch-package ikke fejler:
mv patches/next+16.2.10.patch /tmp/
npm install -D typescript@7.0.2
npm install next@16.3.0-preview.6
#   ret de 3 Buffer→Uint8Array type-fejl TS7 fanger

npx tsc --noEmit --extendedDiagnostics        # ~3s total, exit 0
rm -rf .next && npm run build                  # "Finished TypeScript in ~4s", ~72s total

--extendedDiagnostics er nøglen: det giver "Total time" og "Check time" direkte fra compileren, så jeg ikke gætter ud fra wall clock. Og fordi tsconfig.json har incremental: true, skal *.tsbuildinfo slettes før hver kold kørsel — ellers måler man en cache, ikke en compiler.

Konklusion

TypeScript-teamet lovede ~10×. På en rigtig produktions-Next.js-app med ~4.200 filer leverede den native Go-compiler ~10,5× på typecheck og skar 38% af hele produktionsbygget — og fangede tre bugs på vejen. Prisen: preview-software og en enkelt patch-gotcha.

Og hele undersøgelsen var to prompts og en worktree. Det er måske den egentlige pointe: den dyre del af den slags spørgsmål plejede at være arbejdet med at svare på dem. Nu er det bare at spørge præcist.