root@construct:~/logs/typescript-strict-mode-changed-how-i-think$
<-- back to /logs
2026-01-07//LOG

TypeScript Strict Mode Changed How I Think

I turned on strict mode in a legacy NestJS codebase last week. It reported a wall of errors. I stared at my terminal for a solid minute before closing the laptop and going to make coffee.

A good part of them was noise: properties injected by dependency injection, DTOs filled in by the framework. But a handful were real bugs, the kind that could reach production behind loose types.

The real ones were familiar: optional properties accessed without checks, or functions returning undefined to a caller that assumes a value and reads a property off it. Objects typed as any passed through three layers of abstraction until nobody knew their shape anymore.

Enabling strictNullChecks alone surfaced a large share of them. Each one was a potential runtime crash waiting for the right (wrong) input. The kind of bugs that show up at 2 AM on a Saturday when some edge case user submits a form with an empty string where you expected a number.

strictPropertyInitialization caught another batch. Classes with properties that were "definitely assigned in the constructor" except they were not. They were assigned in some init method that gets called after construction, maybe, if the stars align.

I used to treat types as documentation. Now I treat them as contracts. When I write a function signature, I think about what happens when the input is null. When I define an interface, I think about which fields are truly optional versus which ones I was just too lazy to make required.

The migration took three painful days of adding null checks and fixing type assertions. Since then, that class of bug (null and undefined) has mostly disappeared from our incidents. Strict mode has limits, though: it does not catch an explicit any, a type assertion with as, or external input that enters the code without runtime validation. At the boundary you still need something like zod or class-validator.

My advice: enable strict mode on day one of every project. If you are inheriting a codebase without it, migrate incrementally: turn the flags on one at a time, starting with strictNullChecks, or enable strict folder by folder. It hurts, but finding those bugs in production hurts more.

TypeScript Strict Mode Changed How I Think | The Broad Way