Решения по обновлению TypeScript 7: параллельные проверщики, режим наблюдения и пробелы в API

TypeScript 7 — это необычная крупная версия: сам язык остается прежним, в то время как инструмент для его проверки и компиляции был заменён. Для большинства команд обновление приводит к значительному ускорению работы без необходимости в правках, но для тех команд, чьи инструменты взаимодействуют напрямую с компилятором, это может стать препятствием. В этом руководстве объясняется, в чём именно заключаются отличия между версиями 6 и 7, как использовать новые средства управления параллельной обработкой и как решить, стоит ли начинать работу над проектом сейчас или подождать следующую версию.

В блоге уже подробно рассматривались преимущества в скорости, полученные благодаря переписке на Go и причины, по которым порт нарушил работу инструментов проверки кода и фреймворков; поэтому здесь акцент сделан на практических аспектах принятия решения об обновлении.

Тот же язык, новый движок

На момент написания этого текста TypeScript 7.0 уже выпущен в качестве стабильной версии (дата выпуска — 8 июля 2026 года; для уточнения текущего статуса ознакомьтесь с записями об обновлении). Это переписывание компилятора с языка TypeScript на Go, проект, о котором Microsoft объявила в марте 2025 года под кодовым названием Corsa. Это не новая версия языка в обычном понимании: новой синтаксиса нет, семантика системы типов предполагается неизменной, и существующие файлы с расширением .ts не должны перестать работать. Ваш код остается прежним; меняется только подложная инфраструктура.

Почему пришлось переписывать компилятор

До версии TypeScript 6, включительно, компилятор был написан на самом TypeScript и запускался с помощью движка JavaScript, что на практике означало использование одной потоковой оболочки для проверки типов. Это создавало проблемы в крупных монорепозиториях, проявляющихся тремя характерными способами:

• Редакторы так долго загружали проект, что разработчики научились ждать.
• Проверка типов в CI занимала несколько минут на каждую операцию.
• Использование памяти было настолько высоким, что ноутбуки сильно тормозили.

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

В чём разница на практике

Значительно более быстрая проверка типов

Опубликованные Microsoft тесты показывают масштаб улучшений: проверка типов в кодбазе VS Code сократилась с 77,8 секунд до 7,5 секунд, что примерно в десять раз быстрее, а Playwright — с 11,1 секунд до 1,1 секунды. Этому способствуют два фактора. Компилятор теперь работает в виде нативного машинного кода вместо JavaScript, выполняемого движком, и может выполнять проверки параллельно с помощью горутин, чего старая однопоточная архитектура никогда не могла сделать. Ваши собственные показатели будут зависеть от структуры проекта; множество небольших независимых файлов позволяют лучше параллелизовать работу, чем один огромный клубок типов.

Новые команды линейной оболочки для параллелизма

Ваш файл tsconfig.json не меняется, поскольку он описывает язык и проект, а не способ, которым компилятор планирует свою работу. Приведённая ниже конфигурация действительна для обеих версий:

// tsconfig.json — nothing changes here, this is the language, not the compiler
{
  "compilerOptions": {
    "strict": true,
    "target": "ES2022"
  }
}

Новые настройки теперь находятся в командной строке. Параметр --checkers определяет количество рабочих процессов для проверки типов, которые работают параллельно, --builders контролирует количество одновременных сборок проектов, а --singleThreaded полностью отключает параллелизм:

# But at the CLI level, TypeScript 7 gives you real knobs to turn:
tsc --checkers 4        # number of parallel type-checker workers
tsc --builders 2        # parallel project-reference builds
tsc --singleThreaded    # opt out entirely, useful for reproducible CI logs

Режим однопоточной работы полезен, когда требуются детерминированные и легко читаемые журналы CI или при выявлении проблем с порядком выполнения операций. На общедоступных серверах CI ограничение значения --checkers количеством доступных ядер предотвращает перегрузку машины; большее количество рабочих процессов также приводит к увеличению использования памяти, поэтому лучше измерять нагрузку, а не слепо стремиться к максимуму.

Переработанный режим наблюдения

В крупных проектах старый механизм отслеживания файлов на основе опросов часто становился проблемой: команда tsc --watch отставала от внесенных изменений. TypeScript 7 переносит подход к отслеживанию файлов, используемый в инструменте Parcel, на язык Go, благодаря чему пересборка начинается сразу после сохранения файлов, без задержек.

Проще упаковка

Во время пробной версии для тестирования нативного компилятора требовалась установка отдельного пакета @typescript/native-preview. В версии 7.0 всё снова находится под стандартным названием пакета, поэтому процесс установки выглядит точно так же, как и раньше:

npm install -D typescript

Если вы экспериментировали с пробной версией, удалите этот дополнительный пакет и все скрипты, которые запускали его отдельный бинарник, чтобы не использовать два компилятора одновременно.

Настоящая проблема: программный API

Именно это определяет возможность многих обновлений. Инструменты, построенные на API компилятора TypeScript, такие как плагины language-service, пользовательские правила проверки кода и модификаторы кода, пока не могут полагаться на стабильный программный API компилятора Go версии 7.0; на момент написания текста ожидается его появление в более поздней версии, конкретно упоминается версия 7.1. Если ваша работа с кодом включает использование такого метода, как ts.createProgram() для анализа программы, тщательно протестируйте этот подход перед переходом на него в производственной среде.

Реалистичный сценарий миграции

Рассмотрим среднего размера монорепозиторий Next.js с примерно 40 000 строками кода на TypeScript и несколькими ссылками на проекты. Переход на версию 7.0 в такой конфигурации может сократить время выполнения команды tsc --noEmit с примерно 52 секунд до около 6. Казалось бы, экономия в 46 секунд незначительна, но это касается каждой задачи CI, каждого хука перед коммитом и каждой ручной проверки во время отладки, и в совокупности для всей команды это составляет несколько часов в неделю.

Для проектов, где tsc используется только для проверки и сборки, сам процесс миграции обычно оказывается не таким значительным: достаточно обновить пакет, запустить проверку и убедиться, что она пройдена без изменений в коде.

npm install -D typescript@latest
npx tsc --noEmit   # ran clean, zero code changes needed

Чистое выполнение — это ожидаемый результат, но не гарантия. Сохраните результаты работы TypeScript 6 для сравнения и сравните сообщаемые ошибки при первом запуске, поскольку в проекте такого размера всегда могут возникнуть крайние случаи.

Стоит ли обновляться прямо сейчас?

• Обновите сейчас, если вы используете tsc только для проверки типов и сборки. Это практически мгновенное улучшение.
• Подождите или разделите, если вы зависите от программного API компилятора через собственные инструменты, плагины редактора или кодомоды. Подождите появления стабильного API или оставьте установленным TypeScript 6 для этих инструментов, используя 7 для проверки.
• Уделите этому приоритет, если вы управляете очень большим монорепозиторием, где время выполнения тестов — это реальные затраты. Экономия времени может компенсировать усилия по миграции в течение нескольких дней.

Основные выводы

• TypeScript 7 меняет компилятор, а не сам язык; ваши файлы tsconfig.json и исходный код остаются прежними.
• Ускорение достигается за счёт работы с нативным кодом и параллельной проверки, которую можно настроить с помощью параметров --checkers, --builders и --singleThreaded.

Основной риск заключается не в вашем коде, а в инструментах, содержащих компилятор, поэтому сначала оцените их перед переходом.

Если медленная проверка была вашей главной претензией к TypeScript, версия 7 в значительной степени устраняет эту проблему; если вы полагаетесь на внутренние механизмы компилятора, подождите ещё одну версию.