Условные типы: тернарник на уровне типов, завязанный на совместимость

extends здесь означает «совместим с», а не «потомок класса»

Почему это важно? Если читать extends как наследование классов, вы ожидаете, что через проверку проходят только более узкие типы — и тогда широкий объект, удовлетворяющий узкому интерфейсу, кажется невозможным. Как только вы видите в этом проверку совместимости, каждый служебный тип в стандартной библиотеке становится очевидным.

Условный тип — это тернарник на уровне типов:

type IsString<T> = T extends string ? true : false;

type A = IsString<"hello">; // ^? true
type B = IsString<number>;  // ^? false

Слово extends — то же ключевое слово, что используют классы, и эта путаница — главный источник недопонимания. В условном типе T extends U задаёт один вопрос: является ли каждое значение T допустимым значением U? — то есть совместим ли T с U? Это не имеет отношения к цепочкам прототипов JS или class X extends Y. Структурная совместимость (юнит 01) — это и есть вся проверка.

type T1 = { a: 1; b: 2 } extends { a: 1 } ? "yes" : "no"; // ^? "yes"
//   более широкий объект СОВМЕСТИМ с более узким
type T2 = 42 extends number ? "yes" : "no";               // ^? "yes"
type T3 = string extends "a" ? "yes" : "no";              // ^? "no"
//   string шире литерала "a", поэтому НЕ совместим

Голые параметры типа дистрибутируют по объединениям

Вот поведение, которое удивило вас в подсказке. Когда проверяемый тип — голый параметр типа (T стоит на левой стороне extends без обёрток) и вы инстанцируете его объединением, TypeScript разбивает объединение и применяет условие к каждому члену по отдельности, а затем объединяет результаты:

type ToArray<T> = T extends unknown ? T[] : never;

type R = ToArray<string | number>;
// ^? string[] | number[]
//   НЕ (string | number)[] — объединение дистрибутировано:
//   ToArray<string> | ToArray<number>  =>  string[] | number[]

T extends unknown ? всегда берёт истинную ветку, так что это просто «обернуть в массив» — но поскольку T голый, оно выполняется по разу на каждый член объединения. Это дистрибутивные условные типы. Полный разбор — в юните 05; здесь усвойте триггер: голый параметр типа + аргумент-объединение.

Полезное следствие: дистрибуция над never даёт never, потому что never — это пустое объединение (ноль членов для перебора):

type Z = ToArray<never>; // ^? never  — а не never[]

Отключение дистрибуции обёрткой-кортежем

Иногда нужно сравнить объединение как единое целое. Оберните обе стороны в одноэлементный кортеж, чтобы T перестал быть голым:

type IsExactlyStringOrNumber<T> =
  [T] extends [string | number] ? true : false;

type Y = IsExactlyStringOrNumber<string | number>; // ^? true
//   [string | number] extends [string | number] — проверено целиком, без разбиения

type N = IsExactlyStringOrNumber<string | boolean>; // ^? false

[T] делает параметр неголым, поэтому дистрибуция подавляется и объединение проверяется за один проход. Идиома [T] extends [U] — каноничный приём «не дистрибутировать»; вы встретите её повсюду в типовом коде библиотек.

Отложенные условия: когда T ещё обобщённый

Если условие пока не может решиться — потому что T ещё не разрешён внутри другого обобщения — TypeScript откладывает разрешение. Он держит условный тип символическим, пока не станет известно достаточно при инстанцировании:

function unwrap<T>(x: T): T extends Promise<infer U> ? U : T {
  // внутри тела возвращаемый тип всё ещё *неразрешённое* условие:
  // T extends Promise<infer U> ? U : T  — TS не может его вычислить, T открыт
  throw new Error("impl elided");
}

const a = unwrap(Promise.resolve(5)); // ^? number   — разрешено в точке вызова
const b = unwrap("plain");            // ^? "plain"

Эта отложенность и позволяет моделировать перегрузочные возвращаемые типы одной сигнатурой: конкретный T вызывающей стороны определяет, какая ветка сработает. Это также значит, что условие над обобщённым T ленивое — совместимость двух неразрешённых условий держится, только когда их проверяемый/extends/ветки структурно совпадают, поэтому обобщённый условный код иногда отказывается упрощаться, пока вы его не инстанцируете.

Цена: где условный тип перестаёт окупаться

Дистрибуция — ещё и комбинаторная ловушка. Условие выполняется по разу на каждый член объединения, и если его ветки строят новые объединения, число членов перемножается. TypeScript ограничивает объединение 100 000 членами и затем сдаётся с Expression produces a union type that is too complex to represent; кортеж, переросший внутренний предел, даёт родственное Expression produces a tuple type that is too large to represent. Достичь потолка объединения можно одним слишком жадным дистрибутивным условием, которому скормили большой keyof — и сбой проявится не как чистый тип, а как any плюс красное подчёркивание в несвязанных точках вызова.

Senior-критерий: условный тип даёт вам возвращаемый тип, который автоматически отслеживает вход, с нулевой стоимостью в рантайме. Счета приходят на этапе компиляции и в читаемости ошибок. Когда ветка идёт не так, подсказка показывает всё неразрешённое условие — T extends Promise<infer U> ? U : T extends ... вложенное на четыре уровня — вместо имени, и junior, читающий точку вызова, не понимает, почему выведенный тип — never. Тянитесь к условию, когда тип действительно меняется с аргументом (случай unwrap/Awaited). Когда нужно лишь одно решение в рантайме, размеченное объединение плюс обычный if читается дешевле, компилируется дешевле и даёт сообщение об ошибке, по которому коллега может действовать. Если тип и значение должны выводиться вместе (карта параметров роутера, тип строки ORM), предпочтите шаг кодогенерации, выдающий плоские именованные типы, вместо башни дистрибутивных условий — сгенерированный type Row = { id: number; ... } человек может навести и понять; условие, его породившее, — нет.