This error means TypeScript inferred the bottom type <code>never</code> for a branch or position but you are assigning an <code>any</code> value to it. The compiler rejects it because <code>never</code> explicitly represents no possible values.
Fixes Type 'any' is not assignable to type 'never'
# Type 'any' is not assignable to type 'never'Type 'any' is not assignable to type 'never'
TypeScript uses <code>never</code> to label unreachable code paths and the base of every strict union. When a branch collapses to <code>never</code>, the compiler assumes there is no valid value for that location. Passing <code>any</code> there defeats that assumption, so TypeScript refuses to treat <code>any</code> as a legal value. The most common time this pops up is during exhaustive switches, conditional checks that drop every union member, or when a generic constraint resolves to an empty union. The fix is either to widen the branch (so it no longer becomes <code>never</code>) or give <code>any</code> a real union type before pushing it through the narrow branch.
Look at the stack trace or IDE squiggles and identify the control flow that collapsed to <code>never</code>. Common suspects are the <code>default</code> clause of a discriminated union switch, the result of <code>Extract</code> on an empty union, or a generic inference with no valid candidates. Hovering the expression should show <code>never</code> in the tooltip.
Give the variable a union that actually contains the value you are assigning. For example, change the signature of your helper from <code>function assertNever(x: never)</code> to accept the union or guard against <code>any</code> before calling it. Annotate arrays or tuples with the expected element type (e.g., <code>const values: Payload[] = []</code>), so TypeScript stops inferring an empty tuple that resolves to <code>never</code> after a push.
Use type guards, discriminated unions, or helper functions to assert the real union for the <code>any</code> value. Don't blindly pass <code>any</code> into <code>assertNever</code>; instead narrow it with <code>if (typeof payload === "string")</code> or <code>switch</code> statements so the compiler can see a real type rather than <code>any</code>. If you still need to opt out, wrap the conversion in a single <code>as unknown as RealUnion</code> near the source, not at the <code>never</code> branch.
If the error comes from a conditional type, make sure the constraint produces an actual branch. For example, don't drop every variant with <code>Exclude<T, U></code> before you use it. Add default generics, fallback branches, or widen the pattern so <code>T</code> cannot resolve to <code>never</code> when meaningful data is provided.
When you intentionally use <code>never</code> to guard unreachable cases, wrap the helper in a clear assertion helper (e.g., <code>function assertNever(x: never): never</code>). Provide a typed fallback in the caller or wrap the <code>any</code> value with a safe union before it reaches <code>assertNever</code>. Don't sprinkle <code>any</code> all the way through your control flow; keep the <code>never</code> catch-all reserved for compile-time exhaustiveness checks.
The TypeScript Handbook explains that <code>never</code> is assignable to every type, but no type is assignable back to <code>never</code> except <code>never</code> itself. That means TypeScript treats a <code>never</code> branch as impossible at runtime. If you see <code>any</code> pushed into a <code>never</code> slot, consider why the compiler thinks the branch is unreachable and fix the surrounding union or control flow instead of forcing <code>any</code>. When you trigger this error inside an <code>assertNever()</code> helper, it usually means you tried to test a branch that genuinely can still run at runtime. Adjust the helper or the argument so the compiler can prove the case is impossible before handing it to <code>never</code>.