exactOptionalPropertyTypes

The plain-language idea

By default, age?: number on an interface means "the age property is either a number, or it's absent, or it's present with the value undefined — all three are fine." That third case is easy to miss: an optional property's type is secretly widened to include undefined as an assignable value, not just as "missing."

interface User {
  name: string;
  age?: number;
}

const a: User = { name: "Ada" };              // ✅ age absent
const b: User = { name: "Ada", age: undefined }; // ✅ age explicitly set to undefined

Both compile identically by default. exactOptionalPropertyTypes: true (a tsconfig.json flag) turns off that equivalence: age?: number now means either the key is completely absent, or it's present with an actual number — explicitly assigning undefined to it becomes a type error.

See it in a real thing: a settings object that must not overwrite a default

interface Settings {
  theme?: "light" | "dark";
}

function applySettings(overrides: Settings, defaults: Settings) {
  return { ...defaults, ...overrides };
}

const custom: Settings = { theme: undefined };
applySettings(custom, { theme: "dark" });
// with exactOptionalPropertyTypes off: { theme: undefined } — the spread silently
// overwrites "dark" with undefined, because `theme` really is a key on the object
// with exactOptionalPropertyTypes on: `custom` itself fails to compile —
// TypeScript refuses to let you construct that ambiguous object in the first place

Without the flag, { theme: undefined } is a perfectly valid Settings value — and then { ...defaults, ...overrides } does exactly what object spread always does: overwrite theme with undefined, silently discarding "dark". The bug isn't in the spread; it's that TypeScript let you construct an object that looks like "no opinion on theme" but actually carries a real, overwriting undefined value. With the flag on, that object is rejected at the point it's created — the error moves to where the ambiguity was actually introduced.

What people usually miss

Watch out

• age?: number and age: number | undefined look similar but mean different things even with the flag on. The first still permits the key to be fully absent; the second requires the key to be present, just possibly holding undefined as its value. The flag makes this distinction actually enforced instead of cosmetic.
• This flag is famous for surfacing real, pre-existing bugs the moment it's turned on, particularly in code that does { ...obj, prop: cond ? value : undefined } to "conditionally" set a property — that pattern always sets the key, it just sometimes sets it to undefined, which is not the same as omitting it.
• It's opt-in for a reason: enabling it on an existing codebase is often not a clean flip. Expect a wave of new errors anywhere code relied on the missing/undefined equivalence, especially around API response types and default-merging patterns like the settings example above.

Why this matters in interviews

"What's the actual difference between an optional property and a property typed T | undefined?" is a question that separates people who've only used ? from people who've hit a real bug from the ambiguity — being able to explain the settings-merging failure mode above, and name the flag that catches it, is a strong, concrete answer.