TypeScript 5.x — стоит ли включать strictest режим или это мазохизм?

[olga_tcp]

В команде спор: тимлид хочет включить максимально строгий TypeScript — strict: true плюс noUncheckedIndexedAccess, exactOptionalPropertyTypes, и ещё пяток флагов. Говорит, это стандарт индустрии в 2026. Я согласен с базовым strict, но noUncheckedIndexedAccess это ад — буквально каждое обращение к массиву требует проверки на undefined, весь код раздувается. Кто реально работает с такими настройками на больших проектах?

[elena_official]

Работаю с noUncheckedIndexedAccess уже полтора года. Первые две недели — боль, это правда. Потом привыкаешь и начинаешь писать код по-другому: вместо arr[0] используешь arr.at(0) и обрабатываешь undefined явно, или деструктуризацию с дефолтами. В итоге поймали реальных багов в проде которые раньше бы прошли незамеченными. Конкретный пример: у нас была функция сортировки которая в редком кейсе возвращала undefined[0] — с обычным strict это молча компилировалось, с noUncheckedIndexedAccess — ошибка компиляции. Рекомендую включать на новых проектах сразу.

[grigory2102]

Мой подход для новых проектов в 2026: базовый strict: true — обязательно, это уже давно норма. noUncheckedIndexedAccess — да, включаю. noImplicitOverride — да, полезно. exactOptionalPropertyTypes — нет. noPropertyAccessFromIndexSignature — ситуативно. Важно ещё включить 'moduleResolution': 'bundler' если используете Vite или modern Next.js — это новый резолвер который правильно понимает exports в package.json. Без него бывают странные проблемы с импортами.

[demid9722]

@gopher_max, Практический совет по noUncheckedIndexedAccess: поставьте eslint-правило prefer-destructuring и array-callback-return строго, тогда паттерны работы с массивами сами встанут в нужное русло. Плюс с TypeScript 5.5+ появился вывод типов для type guards в filter — теперь arr.filter((x): x is NonNullable<typeof x> => x != null) правильно сужает тип, это сильно упрощает работу с массивами где могут быть дыры.

[proxyquant4000]

exactOptionalPropertyTypes — вот это реально спорный флаг. С ним { x?: number } и { x?: number | undefined } это разные типы, что ломает кучу распространённых паттернов типа spread-а объектов. Очень много библиотек не совместимы с этим флагом, будете постоянно делать as any или type assertion. Лично я его не включаю даже на строгих проектах — выхлоп не стоит головной боли.

[makar_dev]

Для уже существующего большого проекта резкое включение всех флагов — плохая идея. Лучше стратегия постепенного ужесточения: сначала включаете флаг, смотрите сколько ошибок (tsc --noEmit | wc -l), если меньше 50 — чините сразу, если больше — добавляете в backlog и чините в течение спринта. Так мы подняли проект на 120к строк с базового strict до почти максимального за три месяца не останавливая разработку фич.