Property 'x' does not exist on type 'never' is a distinct, often more confusing variant of the general property-access error — never is TypeScript's type for "this value cannot possibly occur," and seeing it in an error usually means your code's control flow logic has narrowed a type down to nothing, often revealing a real logic bug in how your conditions are structured, not just a typing gap.
This error means TypeScript has determined, through type narrowing, that at this point in your code, the value's type is never — no possible value satisfies all the narrowing conditions applied so far, which is either a genuine logic error in your conditionals, or (in exhaustiveness-checking patterns) an intentional signal that you've correctly handled every case.
Why This Error Happens
TypeScript narrows types progressively through your code based on conditional checks — each if, type guard, or discriminant check narrows the type further. never appears when narrowing conditions are mutually exclusive or contradictory in a way that leaves no possible remaining type — this is often an actual bug (an if/else if chain with an impossible condition, or comparing against the wrong value) but is also deliberately used as an exhaustiveness-checking technique in switch statements over discriminated unions.
Reproducing the Error
A logic bug in conditional narrowing producing an unintended never:
type Status = "pending" | "active" | "completed";
function handleStatus(status: Status) {
if (status === "pending" || status === "active") {
// status is "pending" | "active" here
if (status === "completed") {
// Error: Property doesn't apply — status is narrowed to `never` here,
// since "completed" is impossible given the outer condition already excluded it
console.log(status.length);
}
}
}
The inner check for "completed" is impossible given the outer condition already narrowed status to exclude it — TypeScript correctly identifies this branch as unreachable, narrowing to never.
Core Concepts Behind This Error
never in an unintentional context (like the example above) almost always indicates a real logic bug — dead code that can never execute, or conditions that don't actually express what you intended; the fix is correcting the conditional logic, not working around the type error.
never used deliberately for exhaustiveness checking is a legitimate, valuable TypeScript pattern — assigning a narrowed value to a variable typed never inside the default case of a switch statement over a union causes a compile error specifically when a new union member is added without a corresponding case, catching incomplete handling at compile time.
Type narrowing accumulates across nested conditionals, meaning a never type deep in a nested if/switch structure reflects the combination of every enclosing condition, not just the innermost one — tracing back through the full nesting is necessary to understand exactly which combination of conditions produced the impossible state.
This error is distinct from the more general "Property does not exist on type X" error in that never specifically signals zero possible values, versus a type that has some possible values just not including the accessed property — recognizing never specifically should immediately shift your focus to the narrowing logic rather than the type definition.
Fixing "Property Does Not Exist on Type 'never'"
Fix 1: Correct the conditional logic causing the unintended narrowing, removing the impossible branch or restructuring the conditions to express what you actually intended:
function handleStatus(status: Status) {
if (status === "pending" || status === "active") {
console.log(`In progress: ${status}`);
} else if (status === "completed") {
console.log(status.length); // fine here — reachable, not narrowed to never
}
}
Fix 2: Use never deliberately for exhaustiveness checking in switch statements, catching incomplete case handling when a union type grows:
function handleStatus(status: Status) {
switch (status) {
case "pending":
return "Waiting";
case "active":
return "In progress";
case "completed":
return "Done";
default:
const exhaustiveCheck: never = status; // errors if a case was missed
throw new Error(`Unhandled status: ${exhaustiveCheck}`);
}
}
Fix 3: When narrowing logic is genuinely complex, add explicit logging or a debugger breakpoint to inspect the actual narrowed type step by step, since nested conditions can make it non-obvious exactly where the impossible narrowing occurred — your editor's hover-for-type feature at each nesting level is the fastest way to trace this.
Is Seeing never Always a Bug, or Sometimes Expected?
It's expected specifically in the deliberate exhaustiveness-checking pattern (a never-typed variable in a switch's default case) — that's a feature, not a bug, and the compile error it produces when triggered is telling you a new union case needs handling. In any other context — accessing a property on a value TypeScript narrowed to never unintentionally — it's virtually always revealing a real logic error in your conditional structure worth tracing back and fixing.
Preventing This Error in Production
Use the exhaustiveness-checking never pattern deliberately in switch statements over discriminated unions, turning what would otherwise be a runtime gap (a new case silently falling through) into a compile-time error instead. When encountering an unintentional never, treat it as a signal to review your conditional logic's actual correctness, not just a type annotation issue to work around, since it usually means a branch you believed was reachable genuinely isn't.
If you hit this error, trace back through every enclosing conditional to understand which combination of narrowing produced never — the fix lives in correcting that logic, not in the specific line where the property access failed.