TypeScript нанимают не как отдельную религию, а как способ не ловить в проде опечатку в поле заказа. В CIS в 2026-м junior frontend и часть backend на Node почти везде ждут TS в вакансии — или «будет плюсом», которое на деле означает «без типов вы слабее другого кандидата с тем же React».
Эта карта — не курс «вся система типов». Это порядок: когда подключать, какой объём закрывает junior, как не утонуть в generics, какой 90-дневный артефакт показать и как связать навык с вакансиями TypeScript, а не с бейджем курса.
Коротко:
- TS — навык найма поверх JavaScript/React/Node, не замена умению собрать интерфейс или API.
- Сначала живой JS-проект или сразу TS, если все целевые вакансии на TypeScript. Не три месяца теории без репозитория.
- Достаточный junior-объём: типы пропсов и DTO, union для статусов, узкий any, понимание unknown, generics на уровне функции обёртки, а не «написать свою монаду».
- strict в tsconfig — да. «выключить половину проверок, чтобы собралось» — нет, это видно на тестовом.
- В резюме TypeScript должен совпадать с кодом. Строка без .ts в GitHub не переживает созвон.
Зачем это работодателю, не «рынку языков»
Команде нужен контракт между фронтом и API: поле называется так, статус заказа — из списка, дата — не любое строковое. TypeScript это фиксирует. Он не делает вас senior. Он снижает стоимость ревью на junior-задачах. Поэтому вакансии пишут TS рядом с React, иногда с Nest/Node.
Не выбирайте TypeScript вместо роли. Если вы не собираете кабинет, типы не спасут. Если собираете на JS и в пяти вакансиях TS — подключите его к тому же кабинету. Карта UI: React roadmap. Карта входа во фронт: как стать frontend-разработчиком.
Backend на TS (Nest, Express) — отдельная ветка. Не мешайте в одном 90-дневном плане «React + Nest + алгоритм типов». Один продукт.
Как выглядит хороший junior-дифф на ревью: новый статус заказа добавлен в union, компилятор подсветил незакрытый switch, вы добавили ветку UI. Плохой дифф: any на ответе, as unknown as Order, выключенный strict. Нанимающий фронт это читает быстрее, чем ваш список «advanced types» в LinkedIn.
Общие типы выносите в types/order.ts или рядом с API-клиентом, не плодите одинаковый interface в каждом компоненте. Если бэкенд отдаёт snake_case, решите явно: маппинг в клиенте или типы с теми же именами, что JSON. Скрытый рассинхрон имён — частая причина «у меня в типах есть, на экране undefined».
Enum vs union: для статусов заказа union строковых литералов обычно проще и ближе к JSON. Enum имейте право не использовать, если не можете объяснить зачем. На созвоне достаточно своего OrderStatus и одного type guard.
Когда подключать
Три рабочих варианта:
- Все целевые вакансии с TypeScript — начинайте кабинет сразу на TS. Боль больнее, меньше переписывать.
- JS ещё сыплется на промисах и формах — доведите тонкий JS-MVP, затем миграция файла за файлом.
- Уже есть JS-репозиторий — allowJs, потом перевод критичных модулей: API-клиент, типы заказа, форма.
Не подключайте TS в день, когда не умеете замапить массив. Тип не заменяет язык. И не откладывайте «пока не пройду курс по conditional types» — этот курс бесконечный.
Практический якорь на первую неделю: тип Order, тип CreateOrderDto, функция fetchOrders(): Promise<Order[]>, обработка не-200. Всё остальное — от потребности. Если форма раздулась, вынесите тип полей. Если появился общий список — дженерик ListResponse<T>. Не начинайте с библиотеки типов «на все случаи API».
Редактор должен показывать ошибку, а не вы её ищете глазами. Если TS «как будто не работает», проверьте, что файлы .ts/.tsx и что include в tsconfig покрывает src. Это не теория системы типов, это гигиена, без которой roadmap стопорится.
Какой объём достаточен для junior
Уметь на практике:
- interface/type для пропсов и ответов API;
- union и сужение: if, switch, проверка поля;
- optional и строгость null, если включили strictNullChecks;
- generics: обёртка ApiResult<T>, не «инфер всего мира»;
- не использовать any без комментария, зачем;
- читать ошибку компилятора, а не выключать правило.
Можно не уметь в первые 90 дней: mapped types наизусть, декораторы как основа, module augmentation, «написать свой Zustand на типах». Если в вакансии Nest и декораторы — учите точечно на сервисе, не абстрактно.
tsconfig: strict true. Не копируйте конфиг с «всё выключено». Цель — чтобы тестовое не собралось, если вы проигнорировали поле.
Связка с API и с React
Самый полезный навык на созвоне: описать тип ответа и не притвориться, что сервер всегда 200. Сделайте клиент, который различает ошибку сети, 400 и 500, и прокидывает это в UI. Это сильнее, чем «знаю Utility Types».
В React: типизируйте пропсы формы и колбэки. События — не any. Дети — если уже понимаете ReactNode, не раньше, чем заработает форма. Избыточные дженерики на каждой кнопке — шум в ревью.
Общий блок навыков фронта: навыки frontend-разработчика. Не дублируйте «JavaScript, TypeScript, ES6, JS» пятью синонимами.
Пример 1. 90 дней: миграция кабинета
Исходник: учебный кабинет заказов на JS. Цель: те же экраны на TS, типы заказа и API, без any в клиенте.
- Дни 1–15. tsconfig strict, сборка, один экран списка переведён. Тип Order со статусом-union.
- Дни 16–40. Клиент API: функции с явным возвратом, обработка ошибки. Форма создания заказа типизирована.
- Дни 41–65. Сужение по статусу в UI (кнопка «оплатить» только на нужном статусе). Убрать as там, где можно сузить честно.
- Дни 66–90. README: как собрать, какие типы главные, где ещё ложь (мок API). Резюме frontend с TS. Отклики на вакансии, где TypeScript в тексте.
Откликаюсь на junior frontend с TypeScript. Кабинет заказов перевёл на TS: типы заказа и API, strict, без any в клиенте. Демо: [ссылка]. Коммерческого стажа нет. На созвоне разберу тип статуса и как отловил рассинхрон с моком. Готов к тестовому на TS.
Письмо продаёт контракт, не любовь к Microsoft. Черновик — генератор письма.