0. Что даёт TypeScript, кроме типов

Вопрос не праздный. Типы — это главное, но не единственное, что приносит TS в проект.

Вот что ещё он навязывает:

Препроцессор

TS — это не просто типы, это много синтаксического сахара поверх JS.

Он требует компиляции. Всё, что ты пишешь — не исполняется напрямую. Даже const x = 1 as const — это синтаксис, который нужно разобрать и превратить обратно в JS.

Именно поэтому:

• нужна настройка tsconfig.json;
• нужен сборщик (tsc / swc / esbuild);
• нужен transpile target (ES2022? CommonJS?);
• нужна настройка импорта

Неочевидные runtime-эффекты

TS-фичи, которые не имеют смысла в runtime, но могут влиять на поведение:

• декораторы;
• emitDecoratorMetadata;
• import type, export type;
• const enum (внезапно исчезает в скомпилированном коде);
• namespace'ы (исчезают полностью, но могут конфликтовать при объединении файлов).

Если не знаешь, как это трансформируется — можно получить странный и не эффективный JS.

Ограничения по фичам языка

TS тормозит внедрение новых JS-фич:

• не всегда поддерживает новый синтаксис сразу;
• вынуждает писать в стиле, удобном для трансформации, а не читаемости;
• часто требует даунгрейда target (ради Node-совместимости);
• декларации типов для новых API появляются с задержкой.

Ты не можешь использовать свежий JS "как есть". Всё должно пройти через типовой компилятор. Чем ближе ты к нативному JS — тем сильнее TS мешает.

TS становится точкой централизованной сложности

Любая сложность в сборке, типах, импортах, конфигурации — в итоге сводится к TypeScript:

• непонятный moduleResolution;
• конфликт версий @types/...;
• магия paths и baseUrl;
• ESM + TS + Jest + Babel = боль.

Ты начинаешь тратить время не на разработку, а на отладку toolchain'а.

Что имеем в итоге?

TypeScript — это не просто типы. Это целый инструментальный стек, который требует, чтобы ты думал в его терминах. Иногда это оправдано. Чаще — нет. Если всё, что тебе нужно — это типы, можно обойтись JSDoc'ом. Без компиляции, без лишнего runtime, без скрытого препроцессинга.