TypeScript Caught My Bug Before It Hit Production — I Owe It an Apology

An API we integrated returned IDs as strings in the JSON response. Somewhere in the migration from JavaScript to TypeScript, a developer had typed the ID as number. The consuming code used it in arithmetic — worked fine in testing because the IDs happened to be numeric strings. Would have broken the moment an ID had a letter in it.

TypeScript caught it when we updated the type definition to match the actual API contract. Suddenly thirty-seven call sites lit up with errors. Every one of them was a real bug — a calculation or comparison that would have silently produced wrong output at runtime.

Before this incident, I treated TypeScript like a linter — nice to have, mostly in the way when I just wanted to ship something. The type errors were obstacles between me and running code. After it, I started treating type errors as the compiler telling me something true about my code.

The shift is subtle but significant. A type error isn't 'TypeScript being annoying.' It's a precise description of a contract violation in your code. The question isn't 'how do I make this error go away' — it's 'why is this contract being violated, and is the type wrong or is the code wrong?'