TypeScript 4.4.2编译器中条件类型与泛型的行为逻辑探究

Let’s unpack exactly why TypeScript is throwing those errors—this all comes down to how the compiler handles conditional types tied to unresolved generic type parameters.

First, the moo type example #

Your function T uses a generic TVal constrained to number. When you write:

type moo = TVal extends number ? true : false;

You’d logically think this should resolve straight to true, right? After all, TVal can only ever be number or a subtype of it. But TypeScript doesn’t collapse this conditional type immediately. Here’s why:

Even with the extends number constraint, TVal could still be a narrow subtype of number—think literal types like 1, union types like 2 | 5, or branded types like number & { __brand: 'UserId' }. The conditional type stays as a generic conditional instead of resolving to true because TypeScript doesn’t want to lose flexibility in how this type might behave when TVal is finally specified with a concrete type.

When you try to assign true or false to boo: moo, the compiler hasn’t locked in what TVal actually is. It has to ensure your assignment is valid for every possible instantiation of T. Even though the else branch (false) seems unreachable, the compiler treats moo as an opaque, unresolved type until TVal is concretized. So it can’t guarantee true is compatible with every possible version of moo (even though we know it should be).

Next, the meep type example #

The same logic applies here:

type meep = TVal extends number ? { sad: true } : { times: true };

Again, TVal is constrained to number, but the conditional type doesn’t collapse to { sad: true } right away. The compiler sees meep as a generic type dependent on the unresolved TVal, so it can’t confirm that { sad: true } is a valid match for every possible instantiation of meep.

When you try assigning { sad: true }, the compiler’s reasoning is: "Until TVal is a concrete type, I can’t be sure this conditional type resolves to the { sad: true } branch—even if the constraint makes the else branch impossible." It’s not that the compiler ignores the constraint; it’s that generic conditional types are designed to stay deferred until their generic parameters are resolved.

Why this behavior exists #

This is intentional design in TypeScript. The goal is to preserve the generic nature of the type so that when someone calls your function with a specific subtype of number (like T<1>()), the conditional type resolves correctly for that specific case. If TypeScript prematurely collapsed the conditional type to the true branch, it would lose the ability to adapt to different subtypes of the constrained generic parameter.

In short: conditional types with unresolved generics stay opaque. The compiler won’t collapse them to their branch results until the generic parameter is replaced with a concrete type.

内容的提问来源于stack exchange，提问作者phuhgh