Waarom we op elk project op TypeScript standaardiseren

Elke Stacklane-codebase is volledig TypeScript: backend, frontend, mobile, scripts, infra-as-code. Die keuze is geen geloofskwestie. We houden er om een praktische reden aan vast: met twee ervaren ontwikkelaars die in een abonnementsmodel rouleren over klant-codebases, is de moeite van het wisselen tussen contexten de variabele die we laag moeten houden. TypeScript is de grootste hefboom die we op die kosten hebben.

Het echte voordeel is de refactor

Type checking vangt bugs, dat klopt. De grotere winst zit in mechanisch refactoren: hernoem een field, verander een functie-signature, herstructureer een domeinmodel, en de compiler loodst je langs elke plek die mee moet veranderen. In een JavaScript-codebase is dezelfde refactor een kwestie van grep-en-duimen. De eerste keer dat je acht uur bespaart op een model-migratie omdat de compiler je precies vertelde waar je moest kijken, verdient de overhead van `tsc --noEmit` zichzelf terug.

Dat je zonder angst kunt refactoren is ook waarom we een opdracht kunnen pauzeren en drie maanden later weer kunnen oppakken zonder opstartkosten. De codebase vertelt de terugkerende ontwikkelaar wat er veranderde en wat er brak. In JavaScript lukt dat niet meer voorbij een bepaalde grootte.

Waar we het type-systeem aan de leiband houden

• Geen kunstjes met conditional types in applicatie-code. Kost een type meer tijd om te schrijven dan de functie eronder, dan klopt de functie niet, 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, webhook-payloads van derden. Schema's dienen meteen als bron van waarheid; de 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 geslaagd is.
• We gebruiken nooit `any`. `unknown` is prima. `never` komt alleen voor in exhaustiveness checks op discriminated unions.

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. Daarvoor leunen we op een kleine set integratietests, een vaste checklist bij code review, en de saaie maar nuttige gewoonte om alles in productie tegen een echte dataset te draaien voordat we het klaar noemen. TypeScript vermenigvuldigt wat die dingen opleveren, het vervangt ze niet.