TYPESCRIPT — CONSTRAINT.

//What types are actually for#

The value isn't catching misspelled properties — a test would find those. It's that a well-chosen type makes a whole category of bug impossible to write. If a request can be loading, loaded or failed, modelling it as a discriminated union means there's no way to express "loaded with an error and no data". A boolean pair plus an optional field lets you write that state, and eventually someone will.

So I treat type design as interface design. What states can this component be in? Which combinations are nonsense? Answering that in the type system means the compiler enforces the answer, and more importantly it forces the question early — usually surfacing an ambiguity in the design that nobody had noticed.

//Where it gets misused#

Elaborate conditional and mapped types that take twenty minutes to read. I've written them, been briefly proud, and then watched a colleague spend an afternoon trying to extend the thing. A type that can't be understood quickly is a liability regardless of how correct it is. Two simpler types and a small amount of duplication is nearly always the better trade.

The other misuse is any at a boundary, which quietly removes every guarantee downstream. Data arriving from a network is genuinely unknown, and the honest move is to validate it at the edge and have a real type after that point — not to assert a shape and hope the server agrees.

//Settings#

Strict mode from the first commit, no exceptions. Retrofitting strictness onto a mature codebase is a long, joyless project, and I've done it twice to learn that once would have been sufficient.

In practice this pairs with React at the component boundary, and with the build tooling described under Node.js.