Есть одно предложение, которое за последние месяцы перепечатали, кажется, все. Вот оно, в переводе с блога TypeScript:

📣 Заявка. «Проверка типов проекта VS Code (около 1,5 млн строк) ускорилась с 77.8 с до 7.5 с». Итог, который команда вынесла в заголовок, — «примерно в 10 раз быстрее».

Это не обзор релиза. Это попытка воспроизвести один график — не на кодовой базе Microsoft, а на монорепо, которое я собрал специально под замер, двумя компиляторами на одной машине, с показом каждой цифры и с репозиторием, где любую из них можно получить командой pnpm bench.

Сразу спойлер: да, TS7 быстрее, и заметно. Но „в десять раз“ живёт в одном конкретном месте, испаряется в другом, а кое-что важное в 7.0 пока не вошло — и это „кое-что“ важнее скорости.

Может быть Вам будут интересны мои предыдущие статьи:

• «Нужен ли здесь useEffect? 12 сценариев из React-код-ревью — от производного состояния до React 19.2»

• Точно ли здесь нужен any? 13 сценариев из TypeScript-код-ревью — от unknown до границы приложения.

Главная мысль:

«10×» — это про чекер на большом проекте, а не про весь ваш день. TS7 радикально ускоряет проверку типов и режет память, и замеры это подтверждают. Но в 7.0 отсутствует стабильный программный API — а с ним из сборки выпадают кастомные трансформеры, tsserver-плагины и типизированный линтинг. Поэтому вопрос миграции — не «стало ли быстрее», а «завязана ли ваша сборка на этот API».

Кому это важно прямо сейчас. Если TypeScript у вас — это tsc --noEmit в CI на современном конфиге, TS7 можно пробовать уже сегодня. Если же в игре ts-morph, типизированный ESLint, кастомные трансформеры, плагины Angular/Volar или нетривиальный emit-пайплайн — читайте это как карту рисков миграции, а не сигнал «пора переходить».

Вердикт за 30 секунд

Всё, что ниже, — доказательства к этой таблице. Замеры на монорепо в 10 000 модулей (характеристики: i9-10885H, 16 ядер, Node 24; TS 6.0.3 против 7.0.2 — первого стабильного релиза 7.0; медиана из трёх прогонов):

Все команды в отчёте завершились с exit code 0 (стенд падает с ошибкой, если нет); сырые прогоны каждой метрики — в report/results.json.

Три вывода, которые эта таблица уже выдаёт:

1. Ускорение реальное, но не «десять». На моей нагрузке — от 3.6× (сборка с эмитом на 10k) до 7.9× (инкрементал). «10×» — это про чистую проверку типов на нужном профиле кода.

2. Память — не «вдвое». На больших проектах разрыв схлопывается до ~16 %.

3. Скорость приехала раньше стабильного API. Классический import ts from "typescript" в 7.0 просто не работает — а на нём стоит значимая часть инструментов.

Правила сравнения

Прежде чем показывать графики, хочу отметить, что сравнение равное. Иначе это не аудит, а маркетинг с другим знаком.

• Один и тот же подопытный. Монорепо на pnpm workspaces: пять реалистичных пакетов (core, utils, api, ui на React, app) с настоящими project references — плюс генератор, который добавляет 1 000 / 5 000 / 10 000 тип-нагруженных модулей. Оба компилятора видят ровно один и тот же код.

• Это стресс-тест, а не «средний проект». Каждый сгенерированный модуль намеренно тип-тяжёлый (рекурсивный Infer<>) — контролируемая нагрузка на чекер, а не «средний проект по больнице». Задача стенда — не заменить ваши замеры, а показать, где заявка «10×» держится, а где начинает распадаться (полный разбор смещения — в разделе «Как я мог ошибиться»).

• Не верю одному размеру. Все замеры — на трёх масштабах. Если эффект зависит от размера проекта (а он зависит), это будет видно.

• Две разные конфигурации — обе про реальные сценарии. Cold typecheck — это tsc --noEmit по всему коду из исходников (сценарий CI и редактора). Build — это tsc -b с project references и реальным declaration emit (сценарий релизной сборки). Это разные задачи; я не смешиваю их числа и каждую сверяю по exit code 0.

• Пины и медиана. typescript@6.0.3 (последний JS-компилятор) против typescript@7.0.2 (нативный Go, GA — вышел 8 июля 2026). N ≥ 3 прогонов, первый — прогрев, в отчёт идёт медиана, кэш (*.tsbuildinfo) чистится перед «холодными» прогонами.

• Измеритель не зависит от измеряемого. Стенд написан на голом Node (.mjs), без единой зависимости от TypeScript. Инструмент, который меряет компилятор, не должен сам стоять на этом компиляторе.

• TS7 меряю как нативный бинарь напрямую. typescript@7.0.2 ставит платформенный tsc.exe, а bin/tsc — это node-шим, который на Windows запускает бинарь дочерним процессом. Я зову tsc.exe напрямую: так это один Go-процесс (параллелизм — горутины внутри него), и PeakWorkingSet64 корректно отражает пиковую память. TS6 меряю как единственный node-процесс. Параллелизм TS7 (--checkers/--builders) — на дефолтах: специально не тюнил, чтобы мерить поведение «из коробки». Ручной тюнинг может ускорить сборку ценой памяти — это отдельная тема.

• Среда напечатана в отчёт. report/env.json: i9-10885H, 16 ядер, 63.9 ГБ RAM, Windows 11, Node 24.15, pnpm 9.12. Числа привязаны к этой среде — важны отношения, не абсолюты.

Весь стенд — в репозитории. Любой замер ниже воспроизводится одной командой — pnpm install && pnpm bench (абсолютные числа будут вашей машины; важны отношения).

10× — где они живут

Начнём с того, где заявка подтверждается. Холодная проверка типов (tsc --noEmit, чистый кэш) — то самое, что Microsoft вынесла в заголовок.

🔬 Замер. Cold typecheck по размерам:

Пунктир — заявленные «10×». Наша кривая идёт ниже и, что интереснее, вниз с ростом проекта.

Это огромный выигрыш. Меньше секунды против почти шести на небольшом проекте, восемь секунд против почти сорока на большом — это заметно меняет ощущение от работы и укорачивает CI-гейт в разы. Разбивка по фазам показывает, откуда он берётся: доминирует фаза check (проверка типов), и именно её нативный Go с параллелизмом ускоряет в ~5–7×. Парсинг и связывание — быстрее ещё сильнее.

⚖️ Расхождение. Заявка — «до 10×». У меня на чистом typecheck — 5.4–7.3×. Числа впечатляющие, но не десять. И «до 10×» из блога — это, судя по всему, удачный конец диапазона на конкретной кодовой базе, а не то, что вы увидите на любом проекте.

…и где они испаряются

Теперь — обратная сторона. Заголовок «10×» легко превращается в ожидание «всё станет в десять раз быстрее». Проверяем, где это ломается.

Сборка с эмитом ускоряется вдвое слабее проверки

tsc --noEmit — это только половина работы. Реальная сборка (tsc -b) ещё разворачивает project references и пишет .js + .d.ts.

🔬 Замер. Build mode (tsc -b, полная сборка из чистого состояния):

⚖️ Расхождение. На сборке с эмитом — 3.5–4.5×, и тем меньше, чем крупнее проект. Осторожно с обобщением: на моём тип-тяжёлом стенде «10×» держатся на чистой проверке типов, но не на эмит-сборке. На своих real-world проектах Microsoft заявляет и крупные ускорения полной сборки (Slack: type-check в CI 7.5 мин → 1) — так что расклад зависит от кода. Но если ваш tsc генерирует .js/.d.ts, не переносите на эмит те же цифры, что на чистую проверку.

Память — не «вдвое»

📣 Заявка. «Использование памяти — примерно вдвое меньше».

🔬 Замер. Пиковый working set процесса (peak RSS):

«Вдвое» держится только на маленьком проекте. Дальше разрыв схлопывается.

⚖️ Расхождение. На 1 000 модулей — почти вдвое (1.76×), как и обещано. Но на 10 000 — всего −16 %. Экономия памяти сильно зависит от нагрузки, и на тяжёлых по типам проектах её почти нет. Это не опровержение заявки — это уточнение: «примерно вдвое» верно не всегда.

Ускорение падает с ростом проекта

Обратите внимание на колонку «Ускор.»: 7.3× → 6.1× → 5.4×. Наивно ждёшь, что на большом проекте параллелизм TS7 даст больше, — а ускорение, наоборот, падает. Причина — та самая тип-тяжёлая нагрузка: вычисление рекурсивных типов как раз там, где преимущество TS7 скромнее, а давление на память растёт.

Внутренний цикл: инкрементал и watch — разные вещи

Инкрементальная пересборка tsc -b после точечной правки быстра на обоих, и TS7 держит преимущество:

Но здесь нужна оговорка о том, что именно я замерил. Эти ~138 мс — это tsc -b по .tsbuildinfo, а не редакторский сценарий --watch/LSP. Команда TypeScript отдельно заявляет улучшения --watch (новый watcher по мотивам Parcel) — но этим стендом я их не проверял. Поэтому переносить 138 мс на «ощущение в редакторе при непрерывном редактировании» некорректно: это разные вещи, а editor-цикл я меряю лишь косвенно (см. «Как я мог ошибиться»).

Если совсем упростить: TS7 великолепен там, где компилятор „думает“. Но как только он начинает ещё и писать файлы, гонять project references и жить в реальном пайплайне — выигрыш становится скромнее. Отсюда и вся эта часть: «10×» живут в чистой проверке типов, а не в рабочем дне целиком.

Цена скорости: быстрый tsc есть, старого API нет

Вот здесь заканчивается статья про скорость и начинается собственно аудит. Официально это порт, а не переписывание, с идентичной семантикой. Проверяю обе половины утверждения.

Сначала — хорошая новость) Семантику сохранили:

🔬 Замер (паритет). Один и тот же код с шестью типовыми ошибками через оба компилятора → идентичный набор диагностик (TS2322, TS2345, TS2339, TS2554, TS2741), совпали коды и количество. Declaration emit (.d.ts) для пакета core — совпал байт-в-байт после нормализации переносов строк. Оговорюсь: диагностики я проверяю на маленьком smoke-наборе ошибок, а .d.ts — на core, а не на всей экосистеме. Но на этих пробах семантика идентична — сигнал, что проверку типов можно начинать пилотировать спокойно.

А теперь — что пропало. Все пункты ниже воспроизводимы (pnpm probes → report/losses.md), каждый печатает вердикт «TS6 ✓ / TS7 ✗».

🔬 Замер (потери). Матрица совместимости:

Корень всего — форма пакета. typescript@7.0.2 по import ts from "typescript" отдаёт лишь заглушку с номером версии — без createProgram, transpileModule, transform. Инструменты загружаются, но падают на первом же вызове API:

import ts from "typescript";
ts.version;         // TS6: "6.0.3"     · TS7: "7.0.2"    (версия есть)
ts.createProgram;   // TS6: [Function]  · TS7: undefined  (Compiler API нет)

Именно так — import ts from "typescript" — в экосистему входят typescript-eslint (типизированный линтинг), ts-morph, ts-jest с кастомными трансформерами, TypeDoc, кодогенераторы и десятки плагинов. Сразу оговорка, чтобы не звучало апокалиптично: это не «сломались навсегда». Они просто не работают напрямую с typescript@7 через старый импорт — но спокойно продолжают жить на typescript@6 рядом, side-by-side (это и есть стратегия сосуществования ниже). А переезд на новый нативный API — отдельная миграционная работа: стабильный программный API в 7.0 сознательно не вошёл, его перенесли в 7.1. Вместо него есть typescript/unstable/* (ключи API, Checker, Emitter…), но он другой по форме и прямо помечен как нестабильный.

Из этого следует:

• Кастомные трансформеры. Классического ts.transform нет, а предложение о плагине-трансформере для tsc сняли — биндинг JS↔Go дорог, и его делают «последним, если вообще». Если у вас DI-метадата, кодоген в emit или ts-jest-трансформер — это блокер.

• Плагины языкового сервиса. В TS7 нет бинаря tsserver — только tsc и нативный LSP. Классический механизм plugins из tsconfig, на котором живут Angular Language Service, Vue/Volar, typescript-plugin-css-modules, к нему не применить напрямую.

И маленький, но показательный штрих про роль TS6. Возьмём конфиг с опциями, которые TS7 удалил (target: es5, moduleResolution: node10, baseUrl, downlevelIteration):

• TS6 ругается на них как на deprecation и предлагает "ignoreDeprecations": "6.0" — с ним всё ещё работает. Это буквально мост миграции: последний JS-компилятор заранее показывает, что уедет.

• TS7 отвечает error TS5108: Option 'target=ES5' has been removed. Мост кончился.

⚖️ Расхождение. «Идентичная семантика» — на моих пробах правда: типы и declaration emit совпадают. Но «порт» не равно «то же самое»: значимая часть инструментальной экосистемы завязана на API, которого в 7.0 нет. Это не сырость, а датированная граница готовности — 7.1.

Как я мог ошибиться

Аудит без этого раздела — это реклама. Необходимости, про которые необходимо проговорить:

• Синтетика — не ваш код, и намеренно тип-тяжёлая. Мои модули гоняют рекурсивный Infer<Schema> в каждом — это осознанно один конец спектра: однородный (10k похожих модулей) стресс на чекер, а не репрезентативный средний фронтенд или бэкенд. Здесь преимущество TS7 скромнее (и, вероятно, отсюда падение ускорения с масштабом). Кодовая база VS Code, на которой Microsoft получила 10×, — другой профиль: больше «обычного» кода, где параллельный нативный чекер раскрывается сильнее. Правда — посередине и зависит от вашего кода; поэтому в репозитории есть генератор: подставьте свой профиль.

• Почему не «настоящий» OSS-репозиторий. Полноценный real-world замер требует, чтобы репозиторий одинаково собирался и на TS6, и на нативном TS7 с одним пином — а это редкость: у крупных проектов свои версии TS, свои плагины и часто конфиг, который 7.0 уже не примет. Синтетика даёт контролируемую переменную (одна нагрузка, два компилятора) и воспроизводимость; плата — цифры про чекер, а не про «средний GitHub-проект». Прогон на своём репо — следующий логичный шаг, и стенд под него готов.

• Одна машина, одна ОС, одна сессия. i9 ноутбучный, Windows, тепловой троттлинг возможен. На сервере с другим числом ядер расклад по параллелизму сместится.

• GA только вышел. TypeScript 7.0 стал GA 8 июля 2026; я мерил на 7.0.2, но патчи 7.0.x ещё будут двигать абсолютные значения — берите отношения, а не секунды.

• С памятью тоньше: «память» у V8 и Go считается по-разному. Я беру peak working set процесса, а не self-reported heap — он ближе всего к «сколько съело» из воспроизводимого. Замер памяти идёт через PowerShell и потому только на Windows; тайминги и пробы кроссплатформенны.

• Cold start IDE — прокси, а не прямой замер. Я хотел скриптовый LSP-харнесс. Но у TS7 нет входа для языкового сервера из командной строки: пакет отдаёт только tsc, tsserver отсутствует, флага --lsp нет — сервер поднимает лишь VS Code-расширение через нестабильный API. Поэтому «загрузку проекта» я меряю тем, что делает сервер при открытии проекта, — полной холодной проверкой типов (те же parse + bind + check). Это доминирующая часть project load, но не весь он. Само отсутствие скриптуемого LSP — тоже находка.

• Все числа сняты с включённым Windows Defender. Отключать антивирус я не стал — это системное изменение. В репозитории лежит rig/defender.ps1, чтобы вы измерили дельту у себя: на Windows реалтайм-сканирование заметно бьёт по фазе parse и по вотчингу.

Ни один из этих пунктов не отменяет вывод. Но каждый очерчивает его границы — и это ровно то, чего нет в пересказах релиза.

Что с этим делать

Практический вопрос не «готов ли TypeScript 7», а «готов ли он для нашего репозитория». На него отвечают не мнением, а десятью минутами со стендом. Решающее дерево:

Стратегия сосуществования, которая работает уже сейчас: инструменты (линтер, кодоген, трансформеры) держите на typescript@6, а tsgo/tsc из TS7 подключайте на typecheck и CI параллельно — как второй, быстрый гейт. Это даёт 5–7× на проверке типов в CI, не ломая цепочку инструментов. Мигрируйте пилотом по одному пакету, а не всем монорепо разом.

Вердикт

TypeScript 7 — не «просто стало быстрее» и не «сырьё, которое рано трогать». Это смена движка с чёткой, датированной границей готовности.

• Чистая проверка типов — быстрее в разы (у меня 5.4–7.3×): это уже сегодня ускоряет CI и локальный tsc --noEmit. На editor/watch-цикл мои числа напрямую не переносятся.

• Сборка с эмитом и экономия памяти — выигрыш есть, но скромнее заголовка (3.6× на большом проекте и ~16 %).

• Семантика и declaration emit — на моих пробах совпали: TS7 уже можно безопасно пилотировать как дополнительный typecheck-гейт.

• А вот программный API, кастомные трансформеры и tsserver-плагины ждут 7.1 — и это, а не скорость, определит, можете ли вы переехать.

Так что «быстрее ли он в десять раз?» — неправильный вопрос. Правильный: «десять раз чего, на каком проекте, и что мы за это отдаём?» Для чекера в CI на современном конфиге TS7 уже можно брать — как параллельный, быстрый гейт рядом с рабочим TS6. Для сборки, которая стоит на трансформерах и типизированном линтинге, — следите за 7.1 и пока держите два компилятора рядом.

Репозиторий и источники

• Стенд аудита: 003_typescript_7. Воспроизвести любую цифру: pnpm install && pnpm bench && pnpm probes.

• A 10x Faster TypeScript — исходная заявка и методология Microsoft.

• Announcing TypeScript 7.0 — GA-анонс (8 июля 2026), в т.ч. про новый API для экосистемы после 7.0.

• Announcing TypeScript 7.0 RC — RC, с которого стартовал этот аудит.

• microsoft/typescript-go — статус фич и CHANGES.md.

• Transformer Plugin or Compiler API · issue #516 — почему трансформеры отложены.

Об авторе

Меня зовут Виктор Горбачёв. Мой Telegram — @team_viktoriko. Senior Frontend-разработчик и Team Lead. Более 7 лет занимаюсь коммерческой разработкой, в основном на React и TypeScript. Моя основная зона интереса — архитектура frontend-приложений: проектирование сервисов с нуля, развитие крупных enterprise-систем, микрофронтенды, сборка проектов на Webpack и Vite, а также постепенное разбиение больших монолитов.

На Хабре пишу о frontend-архитектуре, командной разработке, инженерных процессах и практическом опыте, который обычно остаётся за пределами документации.

Мне интересны не только отдельные технологии, но и способы превращать техническую экспертизу в командный результат: понятные архитектурные решения, воспроизводимые процессы и развитие разработчиков.

Подписывайтесь, чтобы не пропустить новые статьи. У меня есть ещё чего разобрать)

Что дальше

Прогоните стенд у себя, принесите свои числа в комментарии, особенно если они разойдутся с моими. Мне интереснее всего профили кода, на которых у вас получится больше 10× или, наоборот, где TS7 просядет: именно так из одного графика вырастает карта, а не одна точка.