Excess Property Checks

Fresh object literals receive extra scrutiny when assigned to a known object type: TypeScript checks for unexpected property names as well as required fields.

What you will learn: the purpose of excess property checks, the rules TypeScript checks, and what its JavaScript behavior looks like in a runnable example.

This catches typos near where the value is created. Assigning an existing variable with additional fields can still be compatible under structural typing. The rule is a compile-time heuristic, not a universal ban on runtime objects having extra properties.

Key distinction: TypeScript checks the declared types during development; emitted JavaScript carries out the value-level operation at runtime. A type declaration alone never validates untrusted runtime input.

Read this illustration from the first labeled part to the last. Compare it with the example and identify which parts are type checks and which parts run in JavaScript.

This self-contained example uses fixed values, so it runs without reading input or depending on an external service. Paste it into the TypeScript Playground or save it as main.ts.

TypeScript program

interface Card { title: string; }
const source = { title: "Report", color: "blue" };
const card: Card = source;
console.log(card.title);
console.log("color" in card);

Verified output

Report
true

Run locally: npx tsc --strict --target es2022 --module commonjs main.ts, then node main.js. For projects with a tsconfig.json, build using that configuration instead.

source has both title and color. Assigning the variable source to Card is allowed because the required title exists. At runtime card still points to the same object, so "color" in card is true.

Check each step: identify the input values, follow the JavaScript operation in execution order, and match the final expression with the exact output shown. An annotation can reject invalid source before execution, but does not change the value printed.

const card: Card = { title: "Report", color: "blue" } would trigger an excess-property diagnostic for the fresh literal.

How to debug: reproduce the issue in a minimal example. For compiler errors, inspect the inferred and declared types; for a runtime surprise, log the actual values and follow their references or branches.

Create a typo such as titel in a fresh Card literal and read the compiler diagnostic. Then investigate why a preexisting variable behaves differently.

Practice routine: predict the result on paper, edit one part of the code, compile under --strict, run the JavaScript, and explain whether TypeScript caught an error or JavaScript simply behaved differently.

Excess Property Checks: Fresh object literals receive extra scrutiny when assigned to a known object type: TypeScript checks for unexpected property names as well as required fields.

source has both title and color. Assigning the variable source to Card is allowed because the required title exists. At runtime card still points to the same object, so "color" in card is true.

Before continuing, explain one valid use case, one common pitfall, and the separation between compile-time checking and runtime behavior for this feature.