TypeScript Strict Mode: What strict: true Turns On

Strict mode is the "strict": true option in tsconfig.json. It is one switch for eight type-checking flags that catch implicit any, unchecked null and undefined, unsafe function assignments and uninitialized class fields. In TypeScript 7, strict is on by default. This is what code that passes it looks like:

function double(x: number) { // noImplicitAny: x needs a type
  return x * 2;
}

function findUser(id: number): { name: string } | undefined {
  return id === 1 ? { name: "Ada" } : undefined;
}

const user = findUser(2);
console.log(user?.name ?? "no user"); // strictNullChecks: user may be undefined

try {
  JSON.parse("{");
} catch (err) { // useUnknownInCatchVariables: err is unknown
  console.log(err instanceof Error ? err.name : String(err));
}

console.log(double(21));

The output is no user, SyntaxError and 42. Remove the : number, the ?. or the instanceof check and the file no longer compiles.

Turning It On

{
    "compilerOptions": {
        "strict": true
    }
}

Individual flags win over strict, in either direction. "strict": true, "strictNullChecks": false keeps everything except null checking; "strict": false, "noImplicitAny": true turns on only that one. strict also opts you into checks added in future releases, since new strict-family flags join the group.

TypeScript's strict has nothing to do with JavaScript's "use strict" directive, which is a run-time mode. TypeScript 7 always emits "use strict" where it is needed, and setting alwaysStrict: false is error TS5108 (the option was removed).

What Each Flag Catches

The two that change the most code are noImplicitAny and strictNullChecks. This block breaks both on purpose:

// This does not compile: two strict errors.
function double(x) {
  return x * 2;
}

function findUser(id: number): { name: string } | undefined {
  return id === 1 ? { name: "Ada" } : undefined;
}

const user = findUser(2);
console.log(user.name, double(2));

It prints index.ts(2,17): error TS7006: Parameter 'x' implicitly has an 'any' type. and index.ts(11,13): error TS18048: 'user' is possibly 'undefined'. Without strict, this compiles and then crashes at run time with TypeError: Cannot read properties of undefined (reading 'name'). With strict, the crash becomes a compile error. The fixes are the first block on this page.

strictFunctionTypes: Why It Exists

A function that only handles strings must not be used where numbers can arrive. The check below is silenced with @ts-expect-error so you can run it and see what the error prevents:

type Handler = (value: string | number) => void;

const shout = (s: string) => console.log(s.toUpperCase());

// @ts-expect-error strictFunctionTypes rejects this assignment
const handle: Handler = shout;

try {
  handle(42); // the type allows a number, shout cannot take one
} catch (e) {
  console.log(e instanceof Error ? e.message : e); // s.toUpperCase is not a function
}

Without the comment, the assignment is error TS2322, Type '(s: string) => void' is not assignable to type 'Handler'., followed by Types of parameters 's' and 'value' are incompatible. One exception remains by design: parameters of methods declared with method syntax (handle(value: string | number): void inside an interface) are still checked the looser way, so shout could be assigned to such a method without an error.

strictPropertyInitialization

Every class field must get a value in its declaration or in the constructor. Three ways to satisfy it:

class Account {
  owner: string;                  // assigned in the constructor
  balance = 0;                    // initializer
  history: string[] = [];         // initializer
  lastLogin?: Date;               // optional: may stay undefined
  sessionId!: string;             // "!": assigned later, you promise

  constructor(owner: string) {
    this.owner = owner;
  }
}

const a = new Account("Ada");
a.sessionId = "s-1";
console.log(a);

Output:

Account {
  owner: 'Ada',
  balance: 0,
  history: [],
  lastLogin: undefined,
  sessionId: 's-1'
}

The lastLogin and sessionId properties exist with the value undefined because class fields are real JavaScript fields at target ES2022. The ! removes the check without adding any run-time protection, so prefer the other forms. This flag needs strictNullChecks; switching that off disables it too.

Turning On Strict in an Existing Project

Switching a large codebase to strict at once can produce hundreds of errors. Because strict is the TypeScript 7 default, upgrading a project whose tsconfig.json never mentioned strict turns it on by itself; write "strict": false if you need the old behavior while you migrate. A path that keeps the build green:

1. Add "strict": true and switch off the flags with the most errors, usually "strictNullChecks": false and "noImplicitAny": false.
2. Fix the remaining errors, then turn on one more flag and repeat.
3. For noImplicitAny, most fixes are parameter annotations. For strictNullChecks, add | undefined where values can be missing, then handle it with ?., ?? or an if check.
4. Where a fix has to wait, put // @ts-expect-error with a reason on the line. Unlike @ts-ignore, it reports an error once the problem is gone, so the list shrinks on its own.

Do not reach for as any or ! to silence errors in bulk: each one hides exactly the bug the flag was added to find.

Useful Flags Strict Does Not Include

These are separate because they reject code that is often correct. Many projects turn them on anyway.

noUncheckedIndexedAccess catches the most real bugs. With it on:

const scores = [90, 85];
const d: Record<string, number> = {};

const third: number = scores[2]; // error TS2322: Type 'number | undefined' is not assignable to type 'number'.
const c: number = d["x"];        // same error

const safe = scores[2] ?? 0;     // number
for (const s of scores) {        // for...of is not affected: s is number
    console.log(s);
}

tsc --init in TypeScript 7 turns on noUncheckedIndexedAccess and exactOptionalPropertyTypes in the config it generates, next to strict.