Strict mode

Without strict, TypeScript is a linter with opinions. With it, the compiler starts catching the errors that actually reach production. Turn it on in tsconfig.json and leave it on.

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

strictNullChecks

The single most valuable flag in the set. Without it, null and undefined are members of every type, so string silently means "a string, or nothing at all". With it, they are separate:

function greet(name: string | null): string {
  return `Hi ${name.toUpperCase()}`;   // error: name may be null
}

You then handle it, and the handling is visible in the code rather than living in someone's memory:

if (name === null) return "Hi there";
return `Hi ${name.toUpperCase()}`;

?. and ?? are for the cases where a default is genuinely right:

const display = user.profile?.name ?? user.email;

Try it

1interface Profile { name?: string }2interface User { email: string; profile?: Profile }3 4function display(user: User): string {5  // Both hops may be missing, so both are optional-chained, and the6  // fallback is a real value rather than "undefined" printed to a page.7  return user.profile?.name ?? user.email;8}9 10export function run(): string[] {11  return [12    display({ email: "nino@example.com" }),13    display({ email: "ana@example.com", profile: {} }),14    display({ email: "luka@example.com", profile: { name: "Luka" } }),15  ];16}

The escape hatches, and what they cost

• as Type — an assertion. You are telling the compiler you know better. If you are wrong, nothing catches it and the failure surfaces somewhere else.
• ! — the non-null assertion. user!.name says "trust me". The same deal, in one character, which is what makes it easy to scatter.
• any — the checker off entirely for that value, and for anything derived from it.

All three are occasionally the right answer, usually at a boundary where you genuinely know something the compiler cannot. Each one is also a place where a future bug will not be caught, so each one deserves a comment saying why it is safe.

The habit worth building: when the compiler complains, ask what it has noticed before you ask how to silence it. It is usually right.

What strict does and does not switch on

strict is a family: strictNullChecks, noImplicitAny (an unannotated parameter is an error instead of a silent any), useUnknownInCatchVariables (a caught error is unknown), strictFunctionTypes, strictPropertyInitialization and a few more. Two useful checks are not in it and must be turned on separately: noUncheckedIndexedAccess (an array or record lookup may be ) and (an optional property may be absent, but not explicitly ).

1interface Settings {2  retries?: number;3  label?: string;4}5 6export function run(): unknown[] {7  const s: Settings = { retries: 0, label: "" };8 9  // || replaces every falsy value; ?? replaces only null and undefined.10  return [s.retries || 3, s.retries ?? 3, s.label || "untitled", s.label ?? "untitled"];11}

What interviewers ask

• What does strictNullChecks change? null and undefined stop being members of every type; a value that may be missing has to say so in its type and be handled before use.
• Which useful checks does strict leave off? noUncheckedIndexedAccess and exactOptionalPropertyTypes are the two usually named.
• When is the non-null assertion ! acceptable? When you know something the compiler cannot (a value set by a framework before use), with a comment — and never as a reflex to silence an error.