Строгость tsconfig: что на самом деле включает `strict` и какие флаги он оставляет за бортом

strict — один переключатель, замкнутый на восемь

strict: true не добавляет ни одной отдельной проверки — он задаёт значение по умолчанию для семейства флагов, каждый из которых при этом можно переопределить индивидуально:

// tsconfig.json
{
  "compilerOptions": {
    "strict": true
    // подразумевает, если не переопределить каждый:
    //   strictNullChecks, strictFunctionTypes, strictBindCallApply,
    //   strictPropertyInitialization, noImplicitAny, noImplicitThis,
    //   useUnknownInCatchVariables, alwaysStrict
  }
}

Все они меняют только проверку — ни один не меняет генерируемый JS (кроме alwaysStrict, который добавляет "use strict"). Они ужесточают то, что компилятор примет, обнажая баги, которые всегда были скрыты. Паттерн переопределения важен при миграции: можно включить strict, но выборочно ослабить самый громкий флаг.

{
  "compilerOptions": {
    "strict": true,
    "strictNullChecks": false  // временно; всё остальное остаётся строгим
  }
}

strictNullChecks: тот, что перетипизирует всё

Без него null и undefined присваиваемы любому типу — string молча включает null. С ним они становятся собственными типами и должны моделироваться явно:

// strictNullChecks: true
function greet(name: string) {
  return name.toUpperCase(); // безопасно: name не может быть null/undefined
}

const el = document.querySelector(".btn"); // Element | null
el.addEventListener("click", handler);
//  ^^ Ошибка: 'el' is possibly 'null'.  ts(18047)
//  фикс: if (el) el.addEventListener(...)  — или el?.addEventListener(...)

Именно этот флаг создаёт стену из 1400 ошибок, потому что показывает каждое место, где старая система типов лгала. И это же — главный выигрыш по корректности во всём наборе.

Ценные флаги, которые strict НЕ включает

Почему важно знать, каких флагов нет в наборе? Потому что самые частые TypeScript-баги — выход за границы массива, отсутствующий ключ конфига, возвращающий undefined — живут именно в пробелах, которые набор strict не закрывает. Эти два ловят настоящие баги и не входят в набор strict — вы подключаете их отдельно:

{ "compilerOptions": { "noUncheckedIndexedAccess": true, "exactOptionalPropertyTypes": true } }

noUncheckedIndexedAccess делает так, что любой доступ по индексу к массиву или record возвращает T | undefined, потому что индекс может выйти за границы, а ключ — отсутствовать:

// noUncheckedIndexedAccess: true
const xs = [1, 2, 3];
const first = xs[0];   // number | undefined  (а не number!)
first.toFixed();       // Ошибка: 'first' is possibly 'undefined'.

const cfg: Record<string, string> = {};
const v = cfg.missing; // string | undefined

Он громкий, и почти каждая его жалоба — настоящий скрытый баг (off-by-one, отсутствующий ключ, доступ к пустому массиву). Цена — реальная церемония в телах циклов и при поиске; выигрыш в том, что «доступ к массиву не может быть undefined» перестаёт быть ложью.

exactOptionalPropertyTypes закрывает тонкую дыру. Без него { a?: string } и { a: string | undefined } считаются эквивалентными — то есть можно присвоить { a: undefined } «опциональному» свойству. С ним они расходятся: опциональное свойство может отсутствовать, но писать в него явный undefined нельзя.

// exactOptionalPropertyTypes: true
interface Opts { timeout?: number }       // может ОТСУТСТВОВАТЬ, а не быть undefined

const a: Opts = {};                        // ок — отсутствует
const b: Opts = { timeout: undefined };    // Ошибка: undefined не присваиваем;
//  timeout? значит «отсутствует», а не «есть и undefined»
const c: Opts = { timeout: 200 };          // ок

Это важно, когда код делает "timeout" in opts или Object.keys(opts): при слабом дефолте эти ветки ведут себя неверно, потому что { timeout: undefined } имеет ключ.