TypeScript Strict Mode: Is the Pain Worth It?

I avoided enabling strict: true in TypeScript for almost a year. The errors it throws feel punishing when you're in the middle of building something and you just want things to work. Looking back, that reluctance cost me more time than it saved.

What Changed My Mind

While working on Strix-Ink, I had a function that retrieved a document from local storage and returned it for rendering. I was accessing a property on the returned object directly — it looked fine, it compiled fine with strict off. In testing it worked because there was always a document loaded. In a fresh install with no documents, the app crashed trying to access a property on undefined.

With strict mode, that exact line would have failed to compile. The type system would have forced me to handle the undefined case before I could build. Instead I found it via user testing and had to trace it backwards through the call chain.

What Strict Mode Actually Enables

• strictNullChecks — the most impactful flag. Variables can't be used when they might be null or undefined without first checking.
• noImplicitAny — forces you to type every parameter. Stops you from accidentally opting out of the type system.
• strictFunctionTypes — catches subtle errors in callback signatures that are otherwise very hard to debug.
• noUncheckedIndexedAccess — array lookups return T | undefined, not just T. Painful at first, genuinely useful for data parsing code.

When It Is Actually Overkill

Throwaway scripts, quick prototypes, one-file utilities where you're the only user. Turning on strict mode for a 50-line script that you run once is unnecessary friction. The value of strict mode scales with the size of the codebase and the number of people touching it.

For any project that I expect to last longer than a week or that has actual users, strict mode is non-negotiable for me now.