MayaLogic
Engineering

A quiet defense of TypeScript strict mode

Strict mode is the cheapest correctness gain you can give a TypeScript codebase. Here is what each flag actually catches and why we turn them all on.

MayaLogic Admin · MayaLogic Editorial

3 min read

A quiet defense of TypeScript strict mode

The single highest-ROI configuration change we recommend on any TypeScript codebase is turning on every strict flag, including the ones not bundled into "strict": true. The compiler is the cheapest reviewer you will ever hire, and almost every flag pays for itself within a release or two.

What each flag catches

strictNullChecks. Catches the undefined is not a function family of bugs at compile time. If you turn on only one flag, turn on this one.

noImplicitAny. Forces you to think about the shape of every variable. The cost is a handful of explicit annotations; the benefit is that no variable silently becomes any because the type inference failed.

strictFunctionTypes. Closes a soundness hole in callback parameter variance that the original TypeScript designers explicitly traded off. Worth the small friction it introduces.

noImplicitReturns. Catches the path through your function that forgot to return a value. Especially useful in reducers and resolvers.

noFallthroughCasesInSwitch. Forces an explicit break or return in every case. Saves you the day you forget one.

noUncheckedIndexedAccess. Treats array indexing and record lookup as T | undefined rather than T. This is the flag teams hate the most when they turn it on and love the most after a month.

noImplicitOverride. Forces override on methods that override a parent. Catches the rename refactor that quietly orphaned a subclass method.

exactOptionalPropertyTypes. Distinguishes "absent" from "present and undefined". The friction here is real but the bugs it catches in API surfaces are the kind that ship to production silently.

The migration path

Turning these on for a large existing codebase is straightforward but unglamorous. Enable one flag at a time, fix the errors, ship the change, repeat. noUncheckedIndexedAccess is the last one to enable because it tends to surface the most warnings; do it in a quiet sprint.

The total time investment is usually one to two engineer-weeks per hundred thousand lines of code. The bug-prevention return is hard to measure precisely but consistently described by teams as "the best refactor we did all year".

If you are starting a new project, turn them all on from commit zero. It is much cheaper than retrofitting later.

After the technical detail

Talk to an engineer about this.

If this maps to a system you are building, we can help pressure-test the architecture, estimate the trade-offs, and identify the riskiest assumptions before you commit.

Book a technical call

Get the checklist for engineering.

Request the PDF guide, architecture template, or implementation checklist and we will send the most relevant resource when it is available.

Author credibility

MayaLogic Admin

MayaLogic Editorial

The MayaLogic editorial team — senior engineers and consultants sharing what we have learned from building software for ambitious teams.

Production deliveryArchitecture reviewOperational ownership

AI in production

Turn the idea into an evaluated AI workflow.

We help teams move from promising demo to secure, observable AI systems with measurable answer quality.

Newsletter

Want more notes like this?

Get occasional field notes on architecture, AI in production, cloud economics, and resilient delivery.

A quiet defense of TypeScript strict mode | MayaLogic