Mental model
TypeScript's type system is structural, set-theoretic, and erased at compile time. Types represent sets of values, where unknown is the universal set and never is the empty set.
Theory
Generic constraints (T extends K) restrict type parameter bounds. Discriminated unions leverage literal tag fields (type: 'success' | 'error') to enable control-flow type narrowing across switch/if statements. Conditional types (T extends U ? X : Y) combined with the infer keyword extract nested type signatures at compile time.
Alternatives and trade-offs
Nominal type systems (like C++ or Java) enforce type equivalence by name, whereas TypeScript enforces structural compatibility. Over-engineering deeply nested conditional types increases compiler check time (tsc --noEmit). Keep utility types shallow and explicit.
Failure modes and misconceptions
anybypass: Usinganydisables all type-checking safety. Useunknownfor unchecked external data.- Runtime type assumptions: TypeScript types do NOT exist at JS runtime. Always validate incoming network JSON with runtime schemas (Zod/Pydantic).
- Type assertions (
as T): Overriding compiler inference withasconceals runtime bugs.
Decision scenario
When designing client-server event contracts, use discriminated unions with explicit tag literals. Avoid passing raw any objects or massive optional classes.
Learning outcomes
- Explain generic constraints and discriminated union patterns.
- Apply conditional type inference to extract nested payload signatures.
- Evaluate structural type safety against runtime validation boundaries.
Trade-offs
Advanced TypeScript types improve compile-time API safety and developer velocity, but over-complex conditional types can increase compiler build latency.