I turned on strict mode in a legacy NestJS codebase last week. It reported 847 errors. I stared at my terminal for a solid minute before closing the laptop and going to make coffee.
Every one of those errors turned out to be a real problem, the kind of bug that could reach production behind loose types.
The worst offenders were familiar: optional properties accessed without checks, or functions returning undefined to a caller that assumes a value. Objects typed as any passed through three layers of abstraction until nobody knew their shape anymore.
Enabling strictNullChecks alone surfaced about 200 issues. Every one of them 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 now, 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, soul-crushing days of adding null checks and fixing type assertions. Since then, we have had zero type-related bugs in production. The compiler has caught them all at build time.
My advice: enable strict mode on day one of every project. If you are inheriting a codebase without it, carve out a week and just do it. It hurts enough to make you question your career choices, but finding those bugs in production hurts more. I treat strict TypeScript as a required quality check.