TypeScript: Why a Property Does Not Exist on Type 'never'

This page explains TypeScript control-flow narrowing, why assignments inside nested functions are not reliably tracked at the call site, and why an impossible branch receives the never type. You will also learn safer patterns: returning values from functions, direct assignments, and explicit type assertions when they are genuinely necessary.

TypeScript uses control-flow analysis to narrow union types. A variable declared as Foo | null can be treated as just Foo after a check proves it is not null.

In this code, however, TypeScript sees this direct initialization:

let instance: Foo | null = null;

It also sees that the only assignment visible in the surrounding function body is inside a nested function:

const mutator = () => {
  instance = { name: "string" };
};

TypeScript deliberately does not generally use assignments made inside closures to narrow variables in the outer control flow. A nested function may be called later, called conditionally, called from another place, or may have side effects that are difficult to model safely. Therefore, at the if statement, the compiler can still treat instance as its known initialized value: null.

That makes this condition always true from TypeScript's perspective:

if (instance == null) {

The else branch is therefore considered unreachable. An unreachable value is represented by the type never, which has no possible values. Since no value of type never can have a name property, TypeScript reports the error.

This behavior has nothing to do with using an interface. Interfaces and type aliases can both describe object shapes:

interface FooInterface {
  name: string;
}

type FooType = {
  name: string;
};

The issue is about control flow and closure mutation, not the way Foo is declared.

Think of TypeScript as a careful auditor reading a checklist.

• It records that instance starts as an empty parking space (null).
• A separate worker, mutator, has instructions to park a car there later.
• Even though you call the worker in this small example, TypeScript does not rely on that worker's side effects when proving the state of the parking space.
• When it reaches the if, its checklist still says the space is empty.

So the else branch means: “the space is not empty,” but TypeScript believes that situation cannot happen. A branch that cannot happen gets the type never—like a road that leads nowhere.

Use a function return value when a function creates or updates a value. TypeScript can track returned values much more reliably than mutation captured by a closure.

interface Foo {
  name: string;
}

function createFoo(): Foo {
  return {
    name: "string"
  };
}

function go() {
  const instance: Foo = createFoo();
  console.log(instance.name);
}

createFoo() promises to return Foo, so instance is known to be a Foo. No null check is needed.

If the function may or may not create the object, return Foo | null and narrow the returned result:

function findFoo(found: boolean): Foo | null {
  return found ? { name: "Ada" } : null;
}

const instance = findFoo(true);

if (instance !== null) {
  console.log(instance.name); // instance is Foo here
}

For a simple local assignment, assigning directly is also fully understood:

let instance: Foo | null = null;
instance = { name: "Ada" };

if (instance !== null) {
  console.log(instance.name); // Foo
}

Prefer strict comparisons such as === null or !== null when checking specifically for null. The loose check value == null intentionally matches both null and undefined.

Consider the original structure:

let instance: Foo | null = null;

const mutator = () => {
  instance = { name: "string" };
};

mutator();

if (instance == null) {
  console.log("null");
} else {
  console.log(instance.name);
}

TypeScript's conservative analysis works approximately like this:

1. instance is declared as Foo | null.
2. It is immediately assigned null, so the current known value is null.
3. TypeScript notices that mutator could assign a Foo, but that assignment is inside a closure.
4. The call mutator() does happen at runtime, but TypeScript does not use this closure side effect to update its outer-flow narrowing in this situation.
5. At if (instance == null), TypeScript still considers instance to be null.
6. The if block is the only reachable path according to that analysis.
7. The else block has no possible value for instance, so instance becomes never there.
8. Accessing instance.name fails because never has no properties.

At runtime, JavaScript does call mutator() and logs string. The error is a limitation and safety choice in TypeScript's static analysis, not a claim about what JavaScript will necessarily do at runtime.

Control-flow narrowing is useful whenever a value may be absent or may have multiple shapes.

• API responses: Check whether an optional record was found before reading its fields.

  const user = await repository.findById(id); // User | null
  if (user === null) return;
  console.log(user.email);
  

• DOM queries: document.querySelector can return null.

  const button = document.querySelector("#save");
  if (button !== null) {
    button.addEventListener("click", save);
  }
  

• Parsing input: A parser can return either valid data or no result.

  const amount = Number.parseFloat(input);
  if (Number.isNaN(amount)) return;
  processAmount(amount);
  

• Configuration: Validate required settings before using them.

  if (!config.apiKey) {
    throw new Error("Missing API key");
  }
  connect(config.apiKey);
  

In each case, keep the value flow explicit so both developers and TypeScript can see where valid data comes from.

In production TypeScript, avoid hidden mutation when a function's main job is to produce a value. Returning the value makes dependencies explicit and gives TypeScript a clear type boundary.

Prefer return values

function buildSession(token: string): Session {
  return { token, createdAt: new Date() };
}

const session = buildSession(token);

Use guard clauses for nullable values

A guard clause handles invalid or absent data early. The rest of the function then works with a narrowed type.

function sendWelcomeEmail(user: User | null) {
  if (user === null) {
    return;
  }

  emailService.send(user.email);
}

Return an updated state instead of mutating captured state

interface State {
  count: number;
}

function increment(state: State): State {
  return { ...state, count: state.count + 1 };
}

let state: State = { count: 0 };
state = increment(state);

Use assertions only at trusted boundaries

An assertion can silence the compiler, but it does not add a runtime check:

console.log(instance!.name);

Use ! only when an external guarantee truly proves the value exists. In this example, redesigning mutator to return Foo is clearer and safer than asserting.

Assuming TypeScript executes functions

TypeScript checks code; it does not execute it to determine every runtime result. It can follow many direct assignments, but it intentionally does not model all side effects from closures.

let value: Foo | null = null;

function setValue() {
  value = { name: "Ada" };
}

setValue();

Do not assume the call automatically changes TypeScript's narrowed view of value in every context. Prefer a return value when possible.

Using the non-null assertion to hide a design issue

// Compiles, but can throw at runtime if instance is null.
console.log(instance!.name);

Avoid ! unless you can prove the value is present through a guarantee TypeScript cannot express.

Forgetting that == null includes undefined

if (value == null) {
  // true for null and undefined
}

This is sometimes intentional. If you only mean null, write:

if (value === null) {
  // only null
}

Declaring nullable state when it is always initialized

If a value is always created before use, avoid null entirely:

// Unnecessary union if createFoo always succeeds.
let instance: Foo | null = null;
instance = createFoo();

Use this instead:

const instance = createFoo();

Expecting interfaces and type aliases to narrow differently

Changing interface Foo to type Foo = ... does not solve a control-flow issue. Both describe types; neither changes how closure assignments are analyzed.

never is also different from null and undefined:

interface Foo {
  name: string;
}

• Foo | null means a value may be a Foo or null.

• Narrow a nullable value with a check:

  if (value !== null) {
    // value is Foo here
  }
  

• value == null checks for both null and undefined.

• value === null checks for only null.

• never means no value is possible in that code path.

• A branch can become never when TypeScript considers its condition impossible.

• Do not rely on mutation inside nested functions for outer-flow narrowing.

• Prefer returning values:

  function createFoo(): Foo {
    return { name: "Ada" };
  }
  
  const instance = createFoo();
  

• Avoid value! unless absence is impossible for a reason TypeScript cannot know.

Why does TypeScript say a property does not exist on never?

TypeScript believes the current branch is unreachable. Since never has no possible values, it cannot have any properties.

Why is the else branch unreachable in this example?

instance is directly initialized to null. TypeScript does not reliably use an assignment inside the mutator closure to update the outer control-flow analysis, so it considers instance == null always true.

Does calling mutator() not matter to TypeScript?

It matters at runtime, but TypeScript intentionally does not model every possible side effect of function calls and closures for narrowing. This keeps analysis safe and manageable.

Does an interface cause this error?

No. The same result can occur with a type alias. The issue is control-flow analysis, not interface syntax.

What is the best fix for this code?

Make the function return the created object, then assign that return value:

const instance = createFoo();

Can I use instance!.name?

You can, but it only suppresses the compiler warning. It can still fail at runtime if instance is actually null. Prefer an explicit check or a better data flow.

When should I use == null?

Use it when you intentionally want one check that handles both null and undefined. Use strict equality when you need to distinguish them.

• Union types — Foo | null is a union that represents multiple possible value types.
• Type narrowing — TypeScript reduces a union to a more specific type after checks.
• Control-flow analysis — The compiler uses branches, assignments, and returns to infer what is possible at each line.
• Nullable values — null and undefined require validation before property access.
• Closures — Nested functions can capture and mutate variables from an outer scope.
• Function return types — Returning data creates explicit, type-safe value flow.
• Non-null assertion operator — value! suppresses nullability checks but does not validate at runtime.
• Exhaustiveness checking — never is useful for proving all cases of a union have been handled.