Waarom we op elk project op TypeScript standaardiseren

Elke Stacklane-codebase is volledig TypeScript: backend, frontend, mobile, scripts, infra-as-code. De keuze is niet religieus. De reden dat we de lijn vasthouden is operationeel: met twee ervaren ontwikkelaars die rouleren over klant-codebases op een abonnementsmodel, zijn de kosten van context-switchen de variabele die we laag moeten houden. TypeScript is de grootste enkele hendel die we op die kosten hebben.

Het echte voordeel is de refactor

Type checking vangt bugs, zeker. De grotere uitbetaling is mechanische refactoring: hernoem een field, verander een functie-signature, herstructureer een domeinmodel, en de compiler loopt je door elke plek heen die moet veranderen. Op een JavaScript-codebase is dezelfde refactor een grep-en-bid oefening. De eerste keer dat je acht uur bespaart op een model-migratie omdat de compiler je precies vertelde waar te kijken, betaalt de runtime-belasting van `tsc --noEmit` zichzelf terug.

Refactor-zonder-angst is ook wat ons in staat stelt een engagement te pauzeren en drie maanden later te hervatten zonder spin-up kosten. De codebase vertelt de terugkerende engineer wat veranderde en wat brak. Dat is onmogelijk op JavaScript voorbij een bepaalde codebase-grootte.

Waar we het type-systeem aan de leiband houden

• Geen conditional-type gymnastiek in applicatie-code. Als een type langer kost om te schrijven dan de functie eronder, is de functie verkeerd, niet het type.
• `zod` (of `valibot` voor kleinere bundles) voor runtime-validatie aan elke grens die de compiler niet kan zien: API-requests, env vars, third-party webhook-payloads. Schema's verdubbelen als bron van waarheid; types worden eruit afgeleid.
• `as`-casts zijn een code smell, geen tool. We staan ze op één plek toe: het parsen van volledig gevalideerde externe data naar een getypeerde vorm, nadat de schema-check al is geslaagd.
• We gebruiken nooit `any`. `unknown` is prima. `never` verschijnt alleen binnen discriminated-union exhaustiveness checks.

Waar TypeScript niet genoeg is

Types vangen geen logica-fouten, geen performance-regressies, geen n+1 queries. Ze checken niet of je migratie omkeerbaar is of dat je background job idempotent is. We leunen op een kleine suite integratietests, een gestructureerde code-review checklist, en een onsexy operationele gewoonte om alles in productie tegen een echte dataset te draaien voor we het klaar verklaren. TypeScript is een force multiplier bovenop die dingen, geen vervanging ervan.