TypeScript Strict Mode

Every any is a runtime bug that the compiler was ready to catch and was told not to. Strict TypeScript converts a class of production failures - undefined access, wrong-shape API responses, unhandled union cases - into compile errors that cost seconds instead of incidents. This skill enforces strictness in new code and migrates existing loose codebases without a big-bang rewrite.

Operating procedure

1. Determine the mode. Greenfield code: apply the full config and the banned/required patterns below from the first commit. Existing loose codebase: jump to the migration procedure - do not flip every flag at once, because a wall of 2,000 errors gets the whole effort reverted.
2. Set the config. The target tsconfig is the artifact below. "strict": true is the floor, not the ceiling - noUncheckedIndexedAccess and exactOptionalPropertyTypes catch real bugs that strict alone misses.
3. Write to the banned/required pattern lists. Every review comment and every fix should cite one of them.
4. Prefer narrowing over asserting. When the compiler complains, the question is "how do I prove this to the compiler," not "how do I silence it." Use the narrowing toolkit.
5. Contain unavoidable casts with the escape-hatch policy. A cast is a claim the compiler cannot check; isolate it, validate it, and never let it propagate.

Inputs to collect

Before migrating or reviewing, gather: (1) the current tsconfig, (2) whether the codebase is greenfield or existing - and if existing, the error count per flag (tsc --noEmit after toggling each flag tells you), (3) any third-party libraries with missing or bad types, since those are where casts concentrate. If the error counts are unknown, measure them first; label any estimate a guess.

Target tsconfig