7 типовых ошибок в tsconfig, которые потом аукнутся на сборке и в рантайме

7 типовых ошибок в tsconfig, которые потом аукнутся на сборке и в рантайме

Если TypeScript в проекте «как будто работает», а потом внезапно ломает импорт, типы или сборку — обычно виноват не код, а конфиг.

— strict: false маскирует проблемы до релиза. Лучше включать строгий режим сразу и точечно ослаблять правила, а не наоборот.
— noUncheckedIndexedAccess часто отключают из-за шума. Потом ловят undefined там, где ожидали объект.
— skipLibCheck: true ускоряет типизацию, но прячет конфликты между пакетами. Для монорепы это особенно дорого.
— module и moduleResolution должны совпадать с тем, как реально собирается проект: ESM, CJS, bundler.
— baseUrl и paths без синхронизации с Vite, Jest, ESLint и runtime дают «работает в IDE, падает в проде».
— esModuleInterop и allowSyntheticDefaultImports лучше понимать, а не включать на автомате. Иначе импорт выглядит чисто, а на деле зависит от транспилятора.
— isolatedModules помогает ловить код, который ломается при пофайловой трансляции через esbuild или swc.

За неделю в репах чаще всего вижу одну и ту же схему: типы чинят в компонентах, а источник проблем сидит в конфиге.

Проверь tsconfig как часть архитектуры, а не как служебный файл. Это дешевле, чем потом разбирать «магические» ошибки на сборке и в рантайме.