tsconfig — это не «настройка TypeScript», а договор между кодом и сборкой

tsconfig — это не «настройка TypeScript», а договор между кодом и сборкой

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

База, которую стоит держать почти всегда:
— strict включён, иначе типизация даёт ложное чувство безопасности
— moduleResolution и module согласованы с реальным рантаймом
— baseUrl и paths используются только если они повторяются в Vite, тестах и CI
— noEmit включают там, где сборку делает отдельный инструмент

Отдельно проверьте две ловушки: esModuleInterop и allowSyntheticDefaultImports. Они часто маскируют несовместимость между CommonJS и ESM, а потом всплывают при миграции пакета или выносе кода в монорепу.

Ещё одна полезная привычка: хранить не один tsconfig, а набор. Базовый для проекта, отдельный для приложения, отдельный для тестов, отдельный для Node-скриптов. Так проще держать разные цели сборки без магии в одном файле.

Если tsconfig нельзя объяснить за минуту, значит он уже слишком дорогой в поддержке.