Definite Assignment Assertion

The plain-language idea

strictPropertyInitialization (part of strict: true) requires every class field to either have an initializer, be assigned in the constructor, or be typed to include undefined. That's a good default — an uninitialized field really can be undefined at runtime, and the compiler is right to want proof otherwise.

But sometimes you have proof the compiler can't see: a field genuinely gets set, just not by the constructor directly — maybe by a decorator, a dependency-injection framework, an init() method called right after construction, or a test's beforeEach. The definite assignment assertion (!, placed right after the field or variable name, not after an expression) tells the compiler "trust me, this will be assigned before it's read" and turns off the check for that one declaration.

See it in a real thing: a field set outside the constructor

class ChartWidget {
  // Set by connectedCanvas(), called immediately after construction —
  // the compiler has no way to know that from the constructor alone.
  canvas!: HTMLCanvasElement;

  connectedCanvas(el: HTMLCanvasElement) {
    this.canvas = el;
  }

  draw() {
    const ctx = this.canvas.getContext("2d"); // no error — canvas is trusted non-undefined
  }
}

const widget = new ChartWidget();
widget.connectedCanvas(document.querySelector("canvas")!);
widget.draw();

Without the ! after canvas, this file fails to compile: strictPropertyInitialization sees a field with no initializer and no constructor assignment, and refuses to let draw() treat this.canvas as definitely an HTMLCanvasElement. The ! is a promise about the field, made once at the declaration site — different from the non-null assertion operator, which is a promise about one expression, made at each read site.

The same syntax works on top-level let variables, for the same reason:

let config: AppConfig;

function loadConfig() {
  config = readConfigFile(); // the compiler sees this assignment
}

loadConfig();
console.log(config.env); // ❌ still flagged — TS can't prove loadConfig() ran before this line

let config2!: AppConfig;
loadConfig2();
console.log(config2.env); // ✅ trusted

What people usually miss

Watch out

• It's a compile-time-only promise, with zero runtime check. If canvas genuinely never gets assigned — say connectedCanvas() is never called — this.canvas.getContext throws a real TypeError at runtime, exactly as if the ! weren't there. TypeScript trusted you; it didn't verify you.
• It only silences the specific check it's meant for. canvas!: HTMLCanvasElement doesn't make canvas optional or nullable — reads of this.canvas are still typed as plain HTMLCanvasElement, not HTMLCanvasElement | undefined. That's the entire point: you're asserting definite presence, not admitting possible absence.
• A real initializer or constructor assignment is almost always better. Reach for ! specifically when the assignment genuinely happens outside code the compiler can trace — framework-managed fields, decorators, DI containers — not as a shortcut past a real "I forgot to initialize this" bug.

The genealogy: a sibling of the non-null assertion operator

This is the declaration-site counterpart to the non-null assertion operator (expr!) covered in the strictNullChecks lesson — both are ways of telling the compiler "I have information you don't," and both share the same risk: the compiler stops checking, but the runtime doesn't stop enforcing. If you understand why user!.name can still throw, you already understand why an unassigned canvas! field can too.