TypeScript 4.9 shipped a couple weeks ago, and most coverage I’ve seen focuses on the satisfies operator. Fair enough — satisfies is flashier. But the change I’m actually excited about? The improvement to type narrowing with the in operator. It fixes something that’s been bugging me for years.

The problem before 4.9 #

Say you’ve got a value typed as unknown and you want to check if it has a specific property before using it. Your natural instinct is:

function handleResponse(value: unknown) {
  if ("error" in (value as object)) {
    // Before 4.9: value is still 'object' here
    // You couldn't access value.error without another cast
    console.log(value.error); // Error!
  }
}

The in operator would only narrow types if the property you checked was already part of the declared type. For properties that weren’t listed — the whole reason you’re doing a runtime check — TypeScript just shrugged and kept the original type. You’d end up writing type assertions anyway, which defeated the whole point of the narrowing check.

What changed #

TypeScript 4.9 now intersects the type with Record<"propertyName", unknown> when the property isn’t in the declared type. In practice:

function handleResponse(value: unknown) {
  if (typeof value === "object" && value !== null && "error" in value) {
    // 4.9: value is now 'object & Record<"error", unknown>'
    // value.error is accessible (typed as unknown, but accessible)
    console.log(value.error); // Works!
  }
}

The type system finally acknowledges that your runtime check actually means something. The narrowed type gives you access to the property — as unknown, which is correct; you still need to validate what’s in there — without requiring a cast.

This matters most when you’re working with loosely typed data: API responses, configuration objects, message payloads. The pattern of “check if a property exists, then use it” is everywhere in real codebases, and it finally works without workarounds.

The satisfies operator (quick take) #

Since everyone’s asking about it: satisfies lets you validate that an expression matches a type without widening the inferred type. It’s useful when you want type-checking at the assignment site but don’t want to lose literal types downstream.

type Color = "red" | "green" | "blue";
type ColorMap = Record<string, Color | [number, number, number]>;

const palette = {
  red: [255, 0, 0],
  green: "#00ff00", // Error! string is not Color | [number, number, number]
  blue: [0, 0, 255],
} satisfies ColorMap;

// palette.red is still [number, number, number], not Color | [number, number, number]
palette.red.map(c => c / 255); // Works --- type is preserved

Good feature. I’ll write more about it once I’ve used it in a larger codebase. For now, the in operator fix is what I’m reaching for daily.

Other 4.9 highlights #

Auto-accessors in classes landed too, implementing the Stage 3 ECMAScript proposal. If you’ve used decorators with getter/setter pairs, auto-accessors clean up the boilerplate:

class User {
  accessor name: string = "Anonymous";
  // Generates a hidden private field with get/set automatically
}

NaN equality checks — TypeScript now flags direct comparisons to NaN as errors, nudging you toward Number.isNaN(). This is one of those JavaScript footguns that trips people up every few months; having the compiler catch it is a welcome guardrail.

Why the ‘in’ fix matters more than it seems #

Type narrowing improvements don’t get the same attention as new syntax. They’re invisible when they work and infuriating when they don’t. The in operator change removes a whole class of unnecessary type assertions from codebases — and every removed assertion is one less place where you’re telling the compiler “trust me” instead of letting it do its job.

If you’re on 4.8, upgrade. The narrowing fix alone is worth it.