Что такое TypeScript и зачем на него переходят

TypeScript коротко

TypeScript — язык от Microsoft, который добавляет к JavaScript статическую типизацию. Любой корректный JavaScript почти всегда является корректным TypeScript, а сам TypeScript перед запуском превращается в обычный JavaScript. Браузер и Node.js исполняют именно его.

Главная идея: вы описываете, какие данные ожидаете, а инструменты проверяют это до запуска, прямо в редакторе.

function formatPrice(amount: number, currency: string): string {
  return `${amount.toFixed(2)} ${currency}`;
}

formatPrice("100", "UZS");
// Ошибка: аргумент типа "string" нельзя передать в параметр типа "number"

В JavaScript этот вызов упал бы только во время работы — у строки нет метода toFixed.

Какие ошибки TypeScript ловит до запуска

• Опечатки в свойствах. user.emial вместо user.email — сразу подсветка.
• Неверные аргументы. Строка вместо числа, забытый обязательный параметр.
• Возможный undefined. При включённом strict TypeScript заставит проверить значение, которое может отсутствовать.
• Неполная обработка вариантов. Если у статуса заказа появилось новое значение, компилятор укажет места, где оно не обработано.
• Поломки при рефакторинге. Переименовали поле в API-ответе — увидите все места, которые нужно поправить.

type Order = { id: number; status: "new" | "paid" | "shipped" };

function label(order: Order) {
  switch (order.status) {
    case "new": return "Новый";
    case "paid": return "Оплачен";
    case "shipped": return "Отправлен";
  }
}

Важно понимать: типы существуют только на этапе разработки. Данные, пришедшие из сети, TypeScript сам не проверяет — для этого используют валидацию (например, библиотеку Zod).

Как работает компиляция

1. Вы пишете файлы .ts / .tsx.
2. Компилятор tsc проверяет типы по настройкам из tsconfig.json.
3. Типы удаляются, на выходе — JavaScript.

На практике часто разделяют две задачи: сборщики (Vite, esbuild, SWC, сборщик Next.js) быстро удаляют типы без проверки, а tsc --noEmit запускается отдельно в редакторе и CI для проверки типов.

{
  "compilerOptions": {
    "strict": true,
    "target": "ES2020",
    "module": "ESNext",
    "noEmit": true
  }
}

Зачем команды переходят на TypeScript

• Меньше ошибок в продакшене из-за неверных данных и опечаток.
• Подсказки и автодополнение в редакторе — код быстрее писать и читать.
• Безопасный рефакторинг в большой кодовой базе.
• Типы как документация: по сигнатуре функции понятно, что она принимает и возвращает.
• Проще онбординг новых разработчиков.

Цена: больше кода на старте, время на изучение типов и настройку инструментов.

Сколько стоит миграция JS-проекта

Точную оценку дать без аудита нельзя — она зависит от факторов:

• Размер кодовой базы и количество связей между модулями.
• Качество текущего кода: чем больше динамики и «магии», тем сложнее описать типы.
• Зависимости: есть ли у библиотек готовые типы (@types/...).
• Строгость цели: включать strict сразу или постепенно.
• Покрытие тестами: тесты страхуют от регрессий во время переписывания.

Рабочий подход — постепенная миграция:

1. Добавить tsconfig.json с allowJs: true, чтобы JS и TS жили вместе.
2. Новые файлы писать сразу на TypeScript.
3. Переводить существующие модули по одному, начиная с общих утилит и типов данных API.
4. Включать строгие проверки по мере готовности.

Переписывать весь проект «за один заход» почти всегда рискованнее.

Частые ошибки

• Повсюду any. Это отключает проверку и сводит пользу к нулю.
• Доверие внешним данным. Тип у ответа API — это обещание, а не проверка.
• Слишком сложные типы. Если тип читается тяжелее кода, его стоит упростить.