strict изнутри: какие проверки он включает

strict сам по себе ничего не находит. Это выключатель, который поднимает восемь других флагов разом — примерно как --all у консольной утилиты. Пока всё включено, разница между ними незаметна; она проявляется в первый же день, когда команда решает «вот это временно отключить».

// попробуйте до запуска назвать, какие флаги strict здесь сработают
function area(w, h) {
  return w * h;
}

function grow() {
  return this.size + 1;
}

let label: string = null;

try {
  JSON.parse("{");
} catch (err) {
  console.log(err.message);
}

console.log(area(2, 3), label);

Два TS7006 на параметрах w и h — это noImplicitAny. TS2683 на this — noImplicitThis. TS2322 на null — strictNullChecks. TS18046 на err.message — useUnknownInCatchVariables. Пять ошибок в четырёх строчках, и ни одна не мешает коду выполниться: диагностики напечатались, а console.log всё равно отработал.

Начиная с шестой версии компилятора этот выключатель поднят по умолчанию. Проверяется за минуту: положите рядом файл с function area(w, h) и tsconfig.json, в котором про строгость нет ни слова, — tsc --noEmit всё равно ответит TS7006. Усилие теперь требуется в обратную сторону: чтобы проверок не было, нужно написать "strict": false. Шаблон из tsc --init по-прежнему пишет "strict": true явно — так конфиг честнее читается человеком.

Любой из восьми флагов перебивает strict в обе стороны и независимо от порядка строк. "strict": true вместе с "strictNullChecks": false оставит семь проверок из восьми; "strict": false вместе с "noImplicitAny": true — ровно одну. Именно так и переезжают старые проекты: включают по флагу за подход.

Девятым в семье когда-то был alwaysStrict — тот, что дописывает "use strict" в результат сборки. Он ушёл: теперь включён всегда, а на "alwaysStrict": false шестая версия отвечает TS5107 и обещает убрать эту возможность в седьмой.

TS7006 из главы про базовые типы — самая частая ошибка новичка в TypeScript, и обычно её понимают шире, чем следует: будто noImplicitAny запрещает любую переменную без аннотации. Это не так, и граница проходит в неожиданном месте.

let value;

value = 10;
console.log(value.toFixed(1));

value = "десять";
console.log(value.toFixed(1));

На объявлении let value; компилятор промолчал, хотя типа там нет. Переменная без аннотации и без начального значения получает «развивающийся» any: компилятор следит за присваиваниями и в каждой точке знает текущий тип. Поэтому первый вызов законен, а второй — уже TS2551: value к тому моменту строка, и toFixed у неё нет. Запускаете — и получаете тот же вывод от движка: 10.0, а следом TypeError.

Неявный any запрещён там, где следить не за чем. У параметра функции значение приходит снаружи, из мест, которых компилятор не видит, — вот его он и требует подписать. Второй такой источник — this.

const timer = {
  seconds: 0,
  tick() {
    return this.seconds + 1;
  }
};
console.log(timer.tick());

function tick() {
  return this.seconds + 1;
}

Отдельно стоящая tick даже не вызвана — TS2683 появляется на объявлении. Компилятору неоткуда узнать, кем окажется this: в части I мы видели, что это решается в момент вызова. Способ сказать ему это явно — фиктивный первый параметр с именем this, который в результат сборки не попадает.

function tock(this: { seconds: number }) {
  return this.seconds + 1;
}
console.log(tock.call({ seconds: 41 }));

Теперь this типизирован, и вызов без подходящего получателя компилятор тоже не пропустит — та самая потеря контекста из главы про this, но пойманная до запуска.

До версии 4.4 переменная в catch имела тип any, и обращаться к её полям можно было как угодно. Флаг меняет тип по умолчанию на unknown — со всеми последствиями из главы про две двери из системы типов.

function toMessage(text: string): string {
  try {
    JSON.parse(text);
    return "разобрали";
  } catch (err) {
    return "ошибка: " + err.message;
  }
}
console.log(toMessage("{"));

Пример показателен тем, что TS18046 здесь выглядит придиркой: JSON.parse действительно бросает SyntaxError, и после диагностики код печатает нормальное сообщение. Придирка кончается на первой чужой библиотеке, которая бросает строку или объект без message. throw в JavaScript принимает что угодно, поэтому unknown — единственный честный тип для пойманного значения.

function describe(err: unknown): string {
  if (err instanceof SyntaxError) {
    return "битый JSON: " + err.message;
  }
  if (err instanceof Error) {
    return err.name + ": " + err.message;
  }
  // сюда попадает всё, что бросили мимо Error: строки, объекты, undefined
  return "неизвестная ошибка: " + String(err);
}

try {
  JSON.parse("{");
} catch (err) {
  console.log(describe(err));
}

try {
  throw "просто строка";
} catch (err) {
  console.log(describe(err));
}

Одна функция-разборщик на приложение снимает вопрос навсегда: сужение через instanceof внутри неё написано один раз, а catch в коде остаётся однострочным.

try {
  JSON.parse("{");
} catch (err: any) {
  console.log(err.message);
}

strictNullChecks разобран отдельно в главе про сужение типов — он самый дорогой при переезде и самый полезный после. Здесь важно другое его свойство: он несущая стена, на которой стоят соседи.

class Session {
  token: string;

  constructor(raw: { token?: string }) {
    if (raw.token) {
      this.token = raw.token;
    }
  }
}

const guest = new Session({});
console.log(guest.token.length);

TS2564 — работа strictPropertyInitialization, и предупреждение оказывается точным: на исполнении guest.token равен undefined, и чтение length валит программу. Способов честно закрыть три: объявить token: string | undefined, задать значение по умолчанию или, если присваивание гарантировано вне конструктора, поставить восклицательный знак — token!: string. Подробности — в статье про TS2564 из главы о классах.

А теперь связь. Попробуйте включить strictPropertyInitialization без strictNullChecks — компилятор откажется собирать проект: «Параметр "strictPropertyInitialization" невозможно указать без указания параметра "strictNullChecks"», TS5052. Это логично: без учёта null и undefined тип string и так включает их обоих, проверять нечего.

Эти два флага почти не попадаются в учебных примерах, зато срабатывают в живом коде с обработчиками. Начнём с того, который ловит настоящую ошибку подстановки.

type Animal = { name: string };
type Dog = { name: string; bark(): void };

type Listener = (a: Animal) => void;

const barkAt = (d: Dog) => d.bark();
const listener: Listener = barkAt;

listener({ name: "кот" });

TS2322 с вложенной причиной: «Свойство "bark" отсутствует в типе "Animal"». Проигнорируйте её — и на исполнении получите TypeError: d.bark is not a function. Правило звучит наоборот тому, чего ждёт интуиция: на место функции, принимающей Animal, годится функция, принимающая больше вариантов, а не меньше. Сужать параметр небезопасно — вызывающая сторона имеет право прислать кота.

А теперь то, из-за чего этот флаг стоит знать по имени. Один и тот же обработчик, записанный двумя способами, проверяется по-разному.

type Animal = { name: string };
type Dog = { name: string; bark(): void };

interface AsMethod {
  handle(a: Animal): void;
}
interface AsProperty {
  handle: (a: Animal) => void;
}

const byMethod: AsMethod = { handle: (d: Dog) => d.bark() };
const byProperty: AsProperty = { handle: (d: Dog) => d.bark() };

byMethod.handle({ name: "кот" });

Диагностика одна — на byProperty. Совершенно такое же присваивание строкой выше компилятор пропустил, и падает программа именно на нём. Это не баг: strictFunctionTypes сознательно не распространяется на свойства, записанные синтаксисом метода. Иначе развалилась бы стандартная библиотека — массив собак перестал бы быть массивом животных, потому что push(item: Dog) и push(item: Animal) объявлены методами.

Хотите, чтобы обработчик в интерфейсе проверялся честно, — объявляйте его полем со стрелочным типом, а не методом. Разница в одном двоеточии и в целом классе пойманных ошибок.

Второй флаг проще. До его появления call, apply и bind были объявлены через any[], и аргументы в них не проверялись вообще.

function repeat(text: string, times: number): string {
  return text.repeat(times);
}

console.log(repeat.call(null, "ту", 2));
console.log(repeat.call(null, "ту", "два"));

TS2345 на второй строке — и обратите внимание, чем оборачивается её игнорирование: не падением, а пустой строкой. String.prototype.repeat приводит "два" к NaN, а NaN к нулю. Ошибка, которая не бросается, а тихо портит вывод, — как раз тот случай, ради которого систему типов и заводят. bind с частичным применением проверяется так же строго.

Флаг появился в версии 5.6 и сразу вошёл в strict — поэтому при обновлении компилятора он ломает сборку в проектах, которые ничего в конфиге не меняли. Речь о ручном обходе встроенных итераторов.

const iterator = new Set([1, 2, 3]).values();

iterator.next();
iterator.next();
iterator.next();

const extra = iterator.next();
console.log(extra.value.toFixed(1));

TS18048: «Возможно, "extra.value" имеет значение undefined». Раньше value у встроенных итераторов был просто number, и такой код собирался молча — а на исполнении давал ровно то, что вы сейчас увидели после диагностики. Флаг привёл типы в соответствие со стандартом: у исчерпанного итератора value действительно undefined.

Обычный for..of флаг не трогает — цикл сам смотрит на done и до пустого результата не добирается. Ломается только код, который дёргает next() руками, а таких мест в проекте обычно единицы.

const map = new Map([["a", 1]]);

const entry = map.entries().next().value;
console.log(entry[0]);

Общий вывод по всем восьми: strict — не позиция «всё или ничего». Если какая-то проверка сейчас неподъёмна, честнее оставить "strict": true и выключить один флаг строкой ниже, с комментарием и датой, чем написать "strict": false и потерять восемь проверок вместо одной. Тем более что теперь по умолчанию они включены — усилие требуется, чтобы от них отказаться.