Recursive Conditional Types

The plain-language idea

The conditional-types lesson covered T extends U ? X : Y as a type-level if/else. What it didn't cover: X or Y are just types, and nothing stops one of them from being the conditional type itself, called again with a smaller piece of T. That's a recursive conditional type — the exact same idea as a recursive function, just running at compile time instead of runtime.

type DeepReadonly<T> = T extends object
  ? { readonly [K in keyof T]: DeepReadonly<T[K]> }
  : T;

Read this like you'd read a recursive function: base case first (T isn't an object — a string, number, etc. — just return it unchanged), recursive case second (T is an object — make every property readonly, and recurse into each property's own type in case it's an object too). The recursion bottoms out naturally once every nested value is a primitive.

See it in a real thing: flattening nested arrays

type Flatten<T> = T extends readonly (infer U)[] ? Flatten<U> : T;

type A = Flatten<number>;              // number — base case, not an array
type B = Flatten<number[]>;            // number — one level unwrapped
type C = Flatten<number[][]>;          // number — two levels unwrapped
type D = Flatten<string[][][]>;        // string — three levels, still works

Each recursive call peels off exactly one layer of array-ness via infer U, then asks "is this still an array?" If yes, recurse again on the element type. If no — T is no longer an array — that's the base case, and Flatten resolves to whatever's left. You didn't have to know how deeply nested the input was; the type recurses exactly as many times as needed and stops on its own.

Compare this with DeepReadonly<T>: both are shaped identically — a base case that stops the recursion, a recursive case that peels off one layer and calls the same type again on what's left. Once you've internalized one recursive conditional type, you've internalized the pattern for all of them.

What people usually miss

Watch out

• The base case has to come first, structurally, or the recursion never terminates. A recursive conditional type without a real base case that the recursive case is guaranteed to eventually reach isn't just slow — it's a compiler error, not a runtime infinite loop, since none of this executes at runtime at all.
• This costs nothing at runtime. All of it — Flatten, DeepReadonly, however many recursive calls — is erased entirely when TypeScript compiles to JavaScript. The "recursion" only exists while the compiler is resolving your types; it produces zero recursive function calls, zero stack frames, in the actual running program.
• Readonly<T> (the built-in utility type) is deliberately shallow, DeepReadonly<T> is not — this is exactly the gap the utility-types lesson flagged and left open. A recursive conditional type is how you actually close it, since the built-in mapped-type approach alone can't reach into nested properties.
• Real-world libraries lean on this constantly — a JSON-serializable type checker, a deep-partial for patch objects, a path-string type like "user.address.city" generated from a nested object's shape, are all recursive conditional types under the hood.

Why this matters in interviews

Writing DeepReadonly<T> or Flatten<T> from scratch is a step up from the basic conditional-types-and-infer exercise — it specifically tests whether you understand that a type alias can reference itself, and whether you can reason about a base case and a shrinking recursive case the same way you would for a recursive function. It also connects straight back to that earlier lesson's point about never filtering out of unions: recursive conditional types are usually where that composability actually pays off in real code, not toy examples.