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.

Когда подключать

Три рабочих варианта:

  1. Все целевые вакансии с TypeScript — начинайте кабинет сразу на TS. Боль больнее, меньше переписывать.
  2. JS ещё сыплется на промисах и формах — доведите тонкий JS-MVP, затем миграция файла за файлом.
  3. Уже есть 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. Дни 1–15. tsconfig strict, сборка, один экран списка переведён. Тип Order со статусом-union.
  2. Дни 16–40. Клиент API: функции с явным возвратом, обработка ошибки. Форма создания заказа типизирована.
  3. Дни 41–65. Сужение по статусу в UI (кнопка «оплатить» только на нужном статусе). Убрать as там, где можно сузить честно.
  4. Дни 66–90. README: как собрать, какие типы главные, где ещё ложь (мок API). Резюме frontend с TS. Отклики на вакансии, где TypeScript в тексте.

Откликаюсь на junior frontend с TypeScript. Кабинет заказов перевёл на TS: типы заказа и API, strict, без any в клиенте. Демо: [ссылка]. Коммерческого стажа нет. На созвоне разберу тип статуса и как отловил рассинхрон с моком. Готов к тестовому на TS.

Письмо продаёт контракт, не любовь к Microsoft. Черновик — генератор письма.

Пример 2. Было / стало в учёбе

Было. Курс: basics, generics, mapped, conditional, infer, «продвинутый TS». Практика: песочница из пяти файлов. На вакансии React+TS — пустой GitHub.

Стало. Недели 1–8: кабинет (см. React-карту) сразу или после короткого JS. Недели 9–12: типы домена, strict, один сложный union. Теория сверх этого — только если всплыла в своём коде.

Второй путь даёт файл, который открывают. Первый даёт уверенность до первого Property does not exist.

Критерии готовности и резюме

Проект собирается с strict. Вы объясняете разницу any/unknown. В PR самому себе нет пятнадцати as unknown as. Заголовок резюме совпадает: frontend + TS, не «TypeScript-инженер» без продукта.

Как описывать стек: как указать стек в резюме. Каркас фронтового файла: резюме frontend-разработчика. Проверка: cv-review.

На интервью могут спросить union vs enum, зачем unknown, что такое type guard. Держите ответы на своём OrderStatus, не на абстрактном Foo. Общие вопросы фронта: вопросы на собеседовании frontend.

Типы на границе с сервером — главный junior-навык

Компилятор не видит JSON. Если мок вернул status: "paid", а в типе только new | cancelled, UI соберётся и на проде взорвётся. На работе это ежедневная боль. Поэтому в 90-дневном проекте полезнее один честный парсер ответа, чем десять хитрых utility types.

Рабочий приём: описать тип ответа, функцию-страж или схему (если взяли одну библиотеку) и ветку UI на ошибку. В README напишите, что мок может врать и как вы это ловите. На созвоне это звучит как опыт, хотя коммерческого стажа нет.

Второй приём — статус как union, не как string. Кнопка «отменить» только на статусах, где это легально. Компилятор заставляет пройти все ветки. Это та же дисциплина, что в backend с enum статуса заказа. Рекрутеру проще поверить в аккуратность, чем в строку «TypeScript, generics, advanced types».

Не путайте «я включил strict» и «я понимаю ошибку». Если чините красноту через as any, вы откатываете навык. Лучше узкий type guard. Если библиотека без типов — один модуль-обёртка с комментарием, не any по всему приложению.

Резюме, тестовое, поиск

В skills одно имя: TypeScript. Рядом React или Node — как в проекте. Не пишите «JS, JavaScript, ES6, TS, TypeScript». Пули: «кабинет заказов, strict, типы API, без any в клиенте», ссылка на демо. Каркас файла: как составить резюме, навыки: навыки в IT-резюме.

Тестовое часто разрешает TS даже если бриф на JS — спросите. Если запрещают — не спорьте про преимущества типов, сделайте форму. Если требуют TS — включите strict и не выключайте правила, чтобы успеть к дедлайну: ревьюер это видит. Жанр домашки: тестовое задание.

Ищите объявления, где TypeScript стоит в must-have вместе с вашей ролью, не «TS engineer» без продукта. Срез: вакансии TypeScript, для фронта ещё React. Письмо — факт про типы домена, не гимн языку. Без стажа: сопроводительное без опыта.

Частые вопросы

Можно ли junior без TypeScript в 2026-м?

На части русскоязычных вакансий ещё берут JS. Смотрите свои пять объявлений. Если TS везде — без него вы конкурируете слабее. Не потому что «язык номер один», а потому что так написан фильтр.

any «только в одном месте» — нормально?

Если это граница с нетипизированной библиотекой и есть комментарий — да. Если any на всём ответе API — нет, это выключенный TypeScript.

Нужен ли Zod/Yup вместе с TS?

На junior плюс, не ядро. Тип не проверяет JSON в рантайме. Если делаете парсинг ответа — одна библиотека и короткий пример в README. Не обе.

Стоит ли учить TS ради Nest, если я фронт?

Нет, пока нет цели на Node-backend. Тот же синтаксис, другой продукт. Размоете 90 дней.

Как писать в skills: TypeScript или TS?

Одно каноническое имя, как в вакансии. Не дублируйте. Уровень «middle TypeScript» без кода не пишите.

Что делать, если тестовое на JS, а готовились на TS?

Пишите на том, что просят. Типы — бонус, если разрешают. Не срывайтесь объяснять tsconfig вместо задачи формы.

Что сделать сейчас

Откройте пять вакансий с TypeScript и посмотрите, это React, Node или оба. Подключите strict к одному кабинету или API. Уберите any из клиента. Положите ссылку в резюме и в письмо.

Искать роли, где этот объём совпадает, удобно в каталоге TypeScript-вакансий. Roadmap типов без продукта — это снова курс, только со сложными словами. Сначала кабинет или API, потом режим strict, потом точечные отклики на совпадающий стек.