TypeScript 7 is er: waarom een 10x snellere compiler jouw workflow verandert

Deze week stond TypeScript 7.0 bovenaan Hacker News — 703 punten en bijna 300 reacties (discussie hier). En dat is terecht. Het is niet zomaar een minor release met een handvol nieuwe utility types. Het is de eerste versie die draait op de nieuwe compiler die volledig in Go is herschreven. Het resultaat: tot 12x snellere type-checking en builds.

Als freelance .NET-developer die dagelijks tussen C# op de backend en TypeScript op de frontend switcht, heb ik jarenlang gemopperd op één ding: tsc is traag. Niet stuk, maar traag genoeg om je flow te breken. In dit artikel kijk ik naar wat er écht verandert, welke brekende defaults je gaan bijten, en of je vandaag al moet migreren.

De cijfers: dit is geen marketing

Microsoft heeft de nieuwe compiler op echte, grote codebases losgelaten. De getallen uit de aankondiging spreken voor zich:

Project	TypeScript 6	TypeScript 7	Versnelling
VS Code	125,7s	10,6s	11,9x
Sentry	139,8s	15,7s	8,9x
Playwright	12,8s	1,47s	8,7x

Geheugengebruik daalt tussen de 6% en 26%. En misschien nog belangrijker voor je dagelijkse werk: het openen van een bestand met fouten in de editor ging van 17,5 seconden naar onder de 1,3 seconde. Dat is het verschil tussen "ik wacht op de squigglies" en "de squigglies wachten op mij".

Waarom kan Go dit en de oude compiler niet? De originele tsc is geschreven in TypeScript zelf en draait op één Node.js-thread. Elegant voor zelfhosting, maar single-threaded en gebonden aan de garbage collector van V8. De Go-port compileert naar native code en gebruikt echte multithreading voor het type-checken van onafhankelijke modules. Voor .NET'ers is de parallel makkelijk te trekken: het is alsof je van een puur interpreterende laag naar AOT-gecompileerde, geparalleliseerde code gaat.

Wat dit betekent voor CI/CD

Hier wordt het concreet. In veel pipelines is tsc --noEmit de trage stap die je build gijzelt. Een monorepo met 400k regels TypeScript die twee minuten stond te type-checken, doet dat straks in vijftien seconden. Dat verandert je hele mentaliteit rond type-checking.

Voorheen was de afweging: draai ik type-checking op elke push, of alleen op de PR? Bij tien seconden hoef je die afweging niet meer te maken. Je zet het gewoon overal aan. Een typische GitHub Actions-stap wordt van een noodzakelijk kwaad naar iets dat je nauwelijks nog voelt:

# .github/workflows/ci.yml
name: CI
on: [push, pull_request]

jobs:
  typecheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      # Vroeger: 90-120s. Met TS7: ~10-15s op dezelfde codebase.
      - run: npx tsc --noEmit

Ik draai voor mijn eigen SaaS-producten (CronGuard, CertGuard) een gedeelde TypeScript-frontend met een .NET-backend. De type-check-stap was altijd de langste in de pipeline — langer dan de dotnet build en de tests samen. Met TS7 kantelt die verhouding volledig. Dat is niet alleen sneller, het verandert waar je aandacht naartoe gaat: opeens is de bottleneck weer je testsuite, waar die hoort.

De brekende defaults die je gaan bijten

Snelheid is het verkoopargument, maar de release-notes verstoppen iets belangrijkers: TypeScript 7 herziet een aantal defaults. Als je een oude tsconfig.json blind meeneemt, krijg je verrassingen. De belangrijkste wijzigingen:

• strict staat nu standaard aan. Eindelijk. Maar als je codebase nooit onder strict mode heeft gedraaid, regent het straks null-fouten.
• module is nu standaard esnext. CommonJS is niet meer de aanname.
• types is nu standaard []. Vroeger werden alle pakketten in node_modules/@types automatisch meegenomen. Dat gebeurt niet meer — je moet expliciet zijn.
• rootDir is standaard ./. Dit kan je output-structuur veranderen als je erop leunde.
• Verwijderde vlaggen: ES5 als target is weg, net als downlevelIteration en de legacy module-systemen AMD, UMD en SystemJS.

Die types: []-wijziging is de sluipmoordenaar. Ik heb projecten gezien die leunden op impliciet ingeladen @types/node of @types/jest, zonder dat ooit in de config te zetten. Onder TS7 breekt dat stil: types die er waren zijn er niet meer. Wees dus expliciet:

// tsconfig.json — TS7-vriendelijk en expliciet
{
  "compilerOptions": {
    "target": "es2023",
    "module": "esnext",
    "moduleResolution": "bundler",
    "strict": true,
    "types": ["node", "vitest/globals"], // expliciet, geen auto-include meer
    "verbatimModuleSyntax": true,
    "noEmit": true,
    "skipLibCheck": true
  },
  "include": ["src"]
}

Mijn advies: behandel de migratie naar strict mode niet als een big-bang. Zet strict: true aan, tel het aantal fouten, en werk het per module weg. Voor een grote legacy-codebase kun je tijdelijk strictNullChecks isoleren met overrides per bestand, maar het echte doel is: overal groen.

Coëxistentie: 6 en 7 naast elkaar

Microsoft is hier verstandig geweest. Je hoeft niet in één keer over. Er is een @typescript/typescript6-pakket waarmee je beide versies naast elkaar kunt draaien. Handig, want er is een flinke kanttekening: TypeScript 7.0 ship't zonder publieke API. Versie 7.1 krijgt een nieuwe (en andere) API.

Dat klinkt als een detail, maar het is de reden dat frameworks die TypeScript embedden — Vue, Svelte, Astro, Angular — nog niet mee kunnen. Zij gebruiken de programmatische API van tsc intern om templates te type-checken. Zolang die API er niet is, moeten die teams op TypeScript 6 blijven. Gebruik je zo'n framework, dan is de aanbeveling helder: blijf op 6.0 voor die workflow, en gebruik 7 voor je losse pakketten en CLI-checks.

Voor een typische React- of Next.js-frontend zonder embedded compiler zit je goed. Voor een Angular-monorepo: nog even geduld.

Een concreet migratiepad

Zo zou ik het aanpakken bij een klant, in oplopende risicovolgorde:

1. Draai eerst alleen tsc --noEmit met TS7 in CI, náást je bestaande build. Puur observeren: welke fouten komen naar boven door de strengere defaults? Nog niks laten falen.
2. Fix de types- en module-fouten. Dit is meestal mechanisch werk: expliciete types-array, imports opschonen, verbatimModuleSyntax respecteren.
3. Zet strict mode module voor module aan. Begin bij nieuwe code en veelgewijzigde bestanden.
4. Pas als CI groen is: maak TS7 de bron van waarheid voor je type-check en emit.

Een detail dat vaak vergeten wordt: je editor. VS Code moet de nieuwe language service gebruiken, anders zie je in de editor nog de oude (trage) tsc terwijl je pipeline al de snelle draait. Prik de workspace-versie vast:

// .vscode/settings.json
{
  "typescript.tsdk": "node_modules/typescript/lib",
  "typescript.enablePromptUseWorkspaceTsdk": true
}

De C#-parallel die niemand maakt

Wat me het meest opvalt, is hoe dit rijmt met wat er in de .NET-wereld al jaren speelt. Roslyn — de C#/VB-compiler — is óók geschreven in de taal die hij compileert (C#), en dat werkt prima omdat de CLR een serieuze, geoptimaliseerde runtime is. Node.js/V8 is snel, maar niet gebouwd voor de rekenintensieve, breed-parallelle workload van een type-checker over een miljoen regels.

De keuze voor Go boven C# of Rust heeft de gemoederen op Hacker News flink beziggehouden. Anders Hejlsberg — de architect achter zowel C# als TypeScript — koos Go omdat het qua geheugenmodel en control-flow dicht bij de bestaande TypeScript-codebase ligt, wat een grotendeels mechanische port mogelijk maakte in plaats van een volledige herontwerp. Voor een codebase van deze omvang is "we kunnen het 1-op-1 porten" een enorm risicoreducerend argument. Ik snap de keuze, ook al had ik als .NET'er stiekem op een NativeAOT-C#-port gehoopt.

De diepere les is universeel, los van de taal: compilerprestaties zijn developerprestaties. Elke seconde die tsc of dotnet build sneller wordt, vermenigvuldig je met het aantal keer per dag dat elke developer erop wacht. Op een team van tien mensen die honderd keer per dag builden, telt dat op tot uren. Dat is precies waarom de branche jaren aan deze rewrite heeft gewerkt.

Moet je vandaag migreren?

Mijn nuchtere advies:

• Greenfield of een schone React/Next-frontend? Begin meteen met TS7. De snelheidswinst is direct voelbaar en je hebt geen legacy-config die je bijt.
• Grote codebase, nog niet op strict mode? Zet TS7 als schaduw-check in CI, verzamel de fouten, en migreer gecontroleerd. Niet forceren.
• Angular, Vue, Svelte of Astro met embedded compiler? Blijf op TypeScript 6 tot 7.1 met de stabiele API landt. Dwing niks.

De echte winst is niet dat je build tien seconden sneller is. Het is dat type-checking zó goedkoop wordt dat je het overal aan kunt zetten zonder na te denken — in pre-commit hooks, op elke push, in elke watch-mode. Dat verschuift de kosten-batenafweging van "type-checking is duur, dus we knijpen een oogje dicht" naar "het is gratis, dus we doen het overal". En dat is precies het soort verandering dat je codebase over een jaar merkbaar gezonder maakt.

TypeScript 7 is niet spannend vanwege nieuwe taalfeatures. Het is spannend omdat het een fundamenteel trage stap in je workflow bijna gratis maakt. Zulke sprongen komen zelden — pak hem beet.

---

Bronnen: Announcing TypeScript 7.0 — Microsoft DevBlogs · Hacker News-discussie