The long-tail of type safety
summary
TypeScript is not sound by default — mutating a string[] into a (string|number)[] or calling JSON.parse (which returns any) can still produce runtime errors — so enable noUncheckedIndexedAccess and strict mode, add ESLint rules to ban unsafe escapes, and replace global defs with ts-reset or override JSON.parse to return unknown. Validate I/O with schema libraries like Zod (safeParse forces handling) and generate types or use tRPC/GraphQL for end-to-end safety; these approaches prove practical and reduce runtime exceptions.
AI-written summary · about
chapters (11)
- 0:00Introduction to type safety
- 1:04TypeScript’s unsound design
- 3:13Where TypeScript falls short
- 4:38Stricter TypeScript config
- 6:25Linting for type safety
- 8:10Fixing global type definitions
- 10:37Handling I/O boundaries
- 13:06Schema-based validation
- 15:33Fetching with type safety
- 16:36Routing and navigation types
- 19:25Long-tail of type safety
related talks
21mThe long-tail of type safety
22mThink you know TypeScript? Think again.
19mYou don't know TS: often unknown parts of TypeScript
21mBeyond Type Checking Building Bulletproof TypseScript Applications
05mTyping correctly matters
40mEnhanced safety with types
24mTypeScript for JavaScripties
42mFriend or Foe? TypeScript Security Fallacies