<b>7 ошибок с TypeScript, которые тихо ломают типизацию и замедляют разработку</b>

<b>7 ошибок с TypeScript, которые тихо ломают типизацию и замедляют разработку</b>

TypeScript часто используют как «прикрутить типы сверху», а потом удивляются, почему ошибки всё равно доходят до рантайма. Обычно проблема не в языке, а в настройках и привычках команды.

— Не включать <code>strict</code>. Без него типы быстро превращаются в декорацию: часть багов уходит в <code>any</code>, часть — в неявные допущения компилятора.
— Разрешать <code>skipLibCheck</code> без причины. Это ускоряет сборку, но прячет конфликты в типах зависимостей. Для монорепы и сложных пакетов это особенно больно.
— Разбрасывать <code>any</code> по коду. Один «временный» <code>any</code> обычно размножается быстрее, чем TODO.
— Путать <code>interface</code> и <code>type</code> без правил. Сам по себе выбор не критичен, критично — когда в проекте нет единого паттерна для объектов, union-типов и расширения контрактов.
— Игнорировать <code>noUncheckedIndexedAccess</code> и <code>exactOptionalPropertyTypes</code>. Именно они ловят классические ошибки с массивами, словарями и опциональными полями.
— Слишком доверять автодополнению. Если тип получен через цепочку утилит и маппингов, его нужно читать как код, а не как подсказку IDE.
— Не держать типы рядом с доменной логикой. Если контракт живёт отдельно от функции, он быстро устаревает.

Для рабочих реп лучше начать с <code>strict</code>, потом точечно добирать флаги и убирать <code>any</code> из самых шумных мест. TypeScript полезен не там, где он «не ругается», а там, где он заставляет договориться о контракте до запуска кода.