Есть одно предложение, которое за последние месяцы перепечатали, кажется, все. Вот оно, в переводе с блога TypeScript:
📣 Заявка. «Проверка типов проекта VS Code (около 1,5 млн строк) ускорилась с 77.8 с до 7.5 с». Итог, который команда вынесла в заголовок, — «примерно в 10 раз быстрее».
Это не обзор релиза. Это попытка воспроизвести один график — не на кодовой базе Microsoft, а на монорепо, которое я собрал специально под замер, двумя компиляторами на одной машине, с показом каждой цифры и с репозиторием, где любую из них можно получить командой pnpm bench.
Сразу спойлер: да, TS7 быстрее, и заметно. Но „в десять раз“ живёт в одном конкретном месте, испаряется в другом, а кое-что важное в 7.0 пока не вошло — и это „кое-что“ важнее скорости.
Может быть Вам будут интересны мои предыдущие статьи:
Главная мысль:
«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; медиана из трёх прогонов):
Метрика | TS6 (JS) | TS7 (Go) | Итог |
|---|---|---|---|
Cold typecheck ( | 39.55 с | 7.37 с | 5.4× быстрее |
— только фаза check | 31.93 с | 6.06 с | 5.3× |
Build ( | 95.64 с | 26.51 с | 3.6× быстрее |
Incremental (правка листа) | 1.08 с | 138 мс | 7.9× |
Память (peak working set) | 2630 МБ | 2196 МБ | всего 1.2× меньше |
Программный API / трансформеры / плагины | ✅ есть | ❌ нет | ждёт 7.1 |
Declaration emit · диагностики | эталон | ✅ совпали | паритет (smoke) |
Все команды в отчёте завершились с exit code 0 (стенд падает с ошибкой, если нет); сырые прогоны каждой метрики — в report/results.json.
Три вывода, которые эта таблица уже выдаёт:
Ускорение реальное, но не «десять». На моей нагрузке — от 3.6× (сборка с эмитом на 10k) до 7.9× (инкрементал). «10×» — это про чистую проверку типов на нужном профиле кода.
Память — не «вдвое». На больших проектах разрыв схлопывается до ~16 %.
Скорость приехала раньше стабильного 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 по размерам:
Модулей | Файлов | TS6 total | TS7 total | Ускор. | TS6 check | TS7 check | Ускор. |
|---|---|---|---|---|---|---|---|
1 000 | 1 080 | 5.59 с | 0.77 с | 7.3× | 4.16 с | 0.56 с | 7.5× |
5 000 | 5 080 | 21.70 с | 3.55 с | 6.1× | 17.25 с | 2.88 с | 6.0× |
10 000 | 10 080 | 39.55 с | 7.37 с | 5.4× | 31.93 с | 6.06 с | 5.3× |
Пунктир — заявленные «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, полная сборка из чистого состояния):
Модулей | TS6 | TS7 | Ускорение |
|---|---|---|---|
1 000 | 12.01 с | 2.69 с | 4.5× |
5 000 | 52.54 с | 14.98 с | 3.5× |
10 000 | 95.64 с | 26.51 с | 3.6× |
⚖️ Расхождение. На сборке с эмитом — 3.5–4.5×, и тем меньше, чем крупнее проект. Осторожно с обобщением: на моём тип-тяжёлом стенде «10×» держатся на чистой проверке типов, но не на эмит-сборке. На своих real-world проектах Microsoft заявляет и крупные ускорения полной сборки (Slack: type-check в CI 7.5 мин → 1) — так что расклад зависит от кода. Но если ваш
tscгенерирует.js/.d.ts, не переносите на эмит те же цифры, что на чистую проверку.
Память — не «вдвое»
📣 Заявка. «Использование памяти — примерно вдвое меньше».
🔬 Замер. Пиковый working set процесса (peak RSS):
Модулей | TS6 | TS7 | Отношение |
|---|---|---|---|
1 000 | 479 МБ | 272 МБ | 1.76× |
5 000 | 1327 МБ | 1116 МБ | 1.19× |
10 000 | 2630 МБ | 2196 МБ | 1.20× |
«Вдвое» держится только на маленьком проекте. Дальше разрыв схлопывается.
⚖️ Расхождение. На 1 000 модулей — почти вдвое (1.76×), как и обещано. Но на 10 000 — всего −16 %. Экономия памяти сильно зависит от нагрузки, и на тяжёлых по типам проектах её почти нет. Это не опровержение заявки — это уточнение: «примерно вдвое» верно не всегда.
Ускорение падает с ростом проекта
Обратите внимание на колонку «Ускор.»: 7.3× → 6.1× → 5.4×. Наивно ждёшь, что на большом проекте параллелизм TS7 даст больше, — а ускорение, наоборот, падает. Причина — та самая тип-тяжёлая нагрузка: вычисление рекурсивных типов как раз там, где преимущество TS7 скромнее, а давление на память растёт.
Внутренний цикл: инкрементал и watch — разные вещи
Инкрементальная пересборка tsc -b после точечной правки быстра на обоих, и TS7 держит преимущество:
Правка | TS6 | TS7 | Ускорение |
|---|---|---|---|
лист графа ( | 1.08 с | 138 мс | 7.9× |
корень графа ( | 521 мс | 98 мс | 5.3× |
Но здесь нужна оговорка о том, что именно я замерил. Эти ~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 ✗».
🔬 Замер (потери). Матрица совместимости:
Проба | TS6 | TS7 | Что это значит |
|---|---|---|---|
| ✓ | ✗ | классический программный API недоступен |
Кастомные трансформеры ( | ✓ | ✗ | плагин-трансформеры в сборке сняты |
tsserver / LS-плагины | ✓ | ✗ | нет бинаря |
Declaration emit | ✓ | ✓ | совпадает |
Паритет диагностик | ✓ | ✓ | совпадает |
Legacy-конфиг | ✓ | ✗ | удалённые опции |
Корень всего — форма пакета. 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», а «готов ли он для нашего репозитория». На него отвечают не мнением, а десятью минутами со стендом. Решающее дерево:
Ситуация | Первый вопрос | Что проверить | Проба |
|---|---|---|---|
современный tsconfig | «пройдёт ли | прогнать оба, сверить диагностики | typecheck / diagnostics |
есть кастомные трансформеры | «есть ли план на 7.1?» | собирается ли emit без них | transformer |
зависите от Compiler API / ts-morph / кодогена | «переживёт ли сборка отсутствие API?» |
| compiler-api |
используете LS-плагины (Angular/Volar/css-modules) | «работает ли редактор без них?» | наличие | ls-plugin |
линтер типозависимый (typescript-eslint) | «чем гейтить, пока API нет?» | схема сосуществования | — |
legacy в конфиге/JSDoc | «что удалено?» | прогнать | legacy |
важен watch-цикл | «как быстр ваш реальный | измерить свой редакторский цикл | — |
Стратегия сосуществования, которая работает уже сейчас: инструменты (линтер, кодоген, трансформеры) держите на 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 просядет: именно так из одного графика вырастает карта, а не одна точка.
