tsconfig strictness: what `strict` actually flips, and the flags it leaves out

strict is one switch wired to eight

strict: true does not add a single check — it sets a default for a family of flags, each of which you can still override individually:

// tsconfig.json
{
  "compilerOptions": {
    "strict": true
    // implies, unless you override each:
    //   strictNullChecks, strictFunctionTypes, strictBindCallApply,
    //   strictPropertyInitialization, noImplicitAny, noImplicitThis,
    //   useUnknownInCatchVariables, alwaysStrict
  }
}

Each of these changes checking only — none of them changes the emitted JS (except alwaysStrict, which prepends "use strict"). They tighten what the compiler will accept, surfacing bugs that were always latent. The override pattern matters during migration: you can turn strict on but selectively relax the loudest one.

{
  "compilerOptions": {
    "strict": true,
    "strictNullChecks": false  // temporarily; everything else stays strict
  }
}

strictNullChecks: the one that re-types everything

Without it, null and undefined are assignable to every type — string silently includes null. With it on, they are their own types and must be modelled explicitly:

// strictNullChecks: true
function greet(name: string) {
  return name.toUpperCase(); // safe: name cannot be null/undefined
}

const el = document.querySelector(".btn"); // Element | null
el.addEventListener("click", handler);
//  ^^ Error: 'el' is possibly 'null'.  ts(18047)
//  fix: if (el) el.addEventListener(...)  — or el?.addEventListener(...)

This is the flag that produces the 1,400-error wall, because it reveals every place the old type system was lying. It is also the single biggest correctness win in the whole bundle.

The high-value flags strict does NOT enable

Why does it matter which flags are missing? Because the most common TypeScript bugs — off-by-one array access, a missing config key returning undefined — live exactly in the gaps the strict bundle doesn’t cover. These two catch real bugs and are not part of the strict bundle — you opt in separately:

{ "compilerOptions": { "noUncheckedIndexedAccess": true, "exactOptionalPropertyTypes": true } }

noUncheckedIndexedAccess makes every index access on an array or record return T | undefined, because the index might be out of bounds or the key absent:

// noUncheckedIndexedAccess: true
const xs = [1, 2, 3];
const first = xs[0];   // number | undefined  (not number!)
first.toFixed();       // Error: 'first' is possibly 'undefined'.

const cfg: Record<string, string> = {};
const v = cfg.missing; // string | undefined

It is loud, and almost every complaint it raises is a genuine latent bug (off-by-one, missing-key, empty-array access). The cost is real ceremony at loop bodies and lookups; the payoff is that “array access can’t be undefined” stops being a lie.

exactOptionalPropertyTypes fixes a subtle hole. Without it, { a?: string } and { a: string | undefined } are treated as equivalent — so you can assign { a: undefined } to an “optional” property. With it on, the two diverge: an optional property may be absent, but you may not explicitly write undefined into it.

// exactOptionalPropertyTypes: true
interface Opts { timeout?: number }       // may be ABSENT, not set to undefined

const a: Opts = {};                        // ok — absent
const b: Opts = { timeout: undefined };    // Error: undefined not assignable;
//  timeout? means "missing", not "present and undefined"
const c: Opts = { timeout: 200 };          // ok

This matters when code does "timeout" in opts or Object.keys(opts) — under the loose default those branches misbehave because { timeout: undefined } has the key.