tsconfig — это не файл «для компилятора», а контракт между репой и IDE

Если в проекте TypeScript ведёт себя странно, чаще всего проблема не в коде, а в настройках: один пакет тянет лишние типы, другой собирается в CommonJS, третий внезапно начинает видеть лишние файлы. tsconfig должен отвечать на три вопроса: что компилируем, где ищем типы, в каком формате отдаём результат.

Базовый минимум для проверки:
• strict: true — ловит неявные дыры в типах
• noEmit: true — если сборку делает отдельный инструмент
• module: NodeNext или ESNext — чтобы не маскировать ESM-ошибки
• moduleResolution: NodeNext — если есть реальная миграция на ESM
• skipLibCheck: true — только если важнее скорость, чем чужие декларации
• include/exclude — чтобы не тащить тесты, артефакты и сгенерёнку

Для монорепы лучше не плодить копии: делайте base tsconfig и наследуйте его через extends. Так проще держать одинаковые правила для package.json, алиасов и путей, а различия выносить в отдельные файлы для app, lib и tests. Иначе спустя пару месяцев у вас появятся «почти одинаковые» конфиги, которые расходятся в одном флаге и ломают предсказуемость сборки.

Если нужен быстрый чек: откройте tsconfig и уберите всё, что не отвечает за типизацию и границы проекта. Чем меньше магии в конфиге, тем меньше сюрпризов в Vite, Bun и CI.