Стоит ли уже переходить на TypeScript 7?

Переходите на TypeScript 7 прямо сейчас, если ваш проект написан на чистом TypeScript и уже собирается без ошибок на 6.0. Если же вы используете typescript-eslint, Vue, Svelte, Astro, MDX или проверку шаблонов Angular, запускайте tsc из 7.0 параллельно с 6.0 и дождитесь версии 7.1, прежде чем переходить полностью.

Цифры прироста скорости впечатляют. Но потом вспоминаешь, что конвейер линтинга, файлы .vue и самописный скрипт кодогенерации импортируют typescript, и переход на новую мажорную версию начинает казаться рискованным.

TypeScript 7.0 вышел 8 июля 2026 года. В этой статье разберём, как выглядит ускорение на практике, какие изменения конфигурации сломают сборку, какие инструменты пока не работают с 7.0 и как использовать оба компилятора в одном репозитории. В конце — рекомендации для проектов каждого типа.

Насколько быстрее TypeScript 7?

TypeScript 7.0 — это порт компилятора TypeScript на Go, и, по словам Microsoft, полная сборка с ним обычно выполняется в 8–12 раз быстрее, чем с TypeScript 6.0. Команда не перепроектировала компилятор: версия на Go повторяет структуру и логику работы исходного кода, поэтому оба компилятора выдают одинаковые результаты. Выигрыш достигается за счёт выполнения в виде нативного кода и проверки типов в нескольких потоках с общей памятью.

Ниже приведены показатели полной сборки из анонса TypeScript 7.0 от Microsoft:

Microsoft запускала эти сборки на крупных open-source-кодовых базах с четырьмя воркерами проверки типов по умолчанию (--checkers 4). В анонсе не указано, на каком оборудовании проводились замеры. Самый низкий результат — у tldraw, 7,7x — немного не дотягивает до заявленного Microsoft диапазона «от 8 до 12 раз».

Реальная экономия времени с TypeScript 7 зависит от размера кодовой базы. Если исходить из цифр Microsoft, vscode экономит около 115 секунд на каждой полной сборке, а tldraw — меньше 10. Небольшое приложение, которое и так проходит проверку типов за две секунды, ускорится примерно во столько же раз, но выиграет совсем немного времени.

Три изменения поменьше, по одной строке на каждое:

• --checkers и --builders управляют параллельной проверкой типов и сборкой ссылок на проекты (project references). В примечаниях к выпуску 7.0 оба флага помечены как экспериментальные.
• --watch теперь работает на Go-порте файлового наблюдателя из Parcel.
• Проверка JS и JSDoc переработана так, чтобы вести себя ближе к анализу .ts. Подробности — в CHANGES.md репозитория typescript-go.

Что ломается при переходе с TypeScript 5.x или 6.0

Код, который компилируется без ошибок на TypeScript 6.0 с включённым stableTypeOrdering и без ignoreDeprecations, должен давать тот же результат на TypeScript 7.0. Всё, что ломается, пришло из 6.0: версия 7.0 наследует новые значения по умолчанию из 6.0, а всё, что в 6.0 было помечено как устаревшее, теперь останавливает сборку. Командам, переходящим сразу с 5.x, придётся разбираться с обоими наборами изменений одновременно.

Новые значения по умолчанию

Большую часть проблем вызывают четыре значения по умолчанию TypeScript 7.0, унаследованные от 6.0:

• strict равно true. Ожидайте новых ошибок в слабо типизированном коде. Переход упростят хорошо типизированные хелперы на основе служебных типов TypeScript.
• module по умолчанию равно esnext.
• rootDir по умолчанию равно ./. Если ваш tsconfig.json лежит уровнем выше src, задайте rootDir явно.
• types по умолчанию равно []. Перечислите пакеты глобальных типов, например node или jest, по имени либо укажите ["*"], чтобы вернуть прежнее поведение.

Изменились ещё четыре значения по умолчанию: target теперь соответствует последней финализированной редакции ECMAScript (на шаг позади esnext), noUncheckedSideEffectImports равно true, libReplacement равно false, а stableTypeOrdering равно true, и отключить его нельзя.

Устаревшие опции, которые теперь вызывают фатальные ошибки

В примечаниях к выпуску TypeScript 7.0 перечислены двенадцать устаревших опций и вариантов поведения, которые теперь приводят к фатальной ошибке:

• target: es5
• downlevelIteration
• moduleResolution: node / node10 (используйте nodenext или bundler)
• moduleResolution: classic (используйте bundler или nodenext)
• module: amd, umd, systemjs, none (используйте esnext или preserve)
• baseUrl (указывайте paths относительно корня проекта)
• esModuleInterop или allowSyntheticDefaultImports со значением false
• alwaysStrict со значением false
• Ключевое слово module в объявлениях пространств имён
• asserts в импортах (используйте with)
• /// <reference no-default-lib /> при skipDefaultLibCheck
• Пути к файлам, переданные в командной строке, если в каталоге есть tsconfig.json, — если не добавить --ignoreConfig

outFile в этом списке нет, но его тоже больше не существует. В примечаниях к выпуску 6.0 сказано, что 6.0 уже удалила эту опцию и что все опции, объявленные устаревшими в 6.0, в 7.0 удалены полностью. Если вы всё ещё используете outFile, переложите эту задачу на бандлер.

Есть и изменение на уровне типов: при выводе типов из шаблонных литеральных типов символ вроде эмодзи больше не разбивается на две половины. Заметите вы это, только если писали строковые хелперы на уровне типов, которые полагались на старое разбиение по UTF-16.

Вот типичная устаревшая конфигурация и версия, которая работает на 7.0:

// Before: hard errors on 7.0
{
  "compilerOptions": {
    "target": "es5",               // error: es5 unsupported
    "downlevelIteration": true,    // error: removed
    "moduleResolution": "node",    // error: node/node10 unsupported
    "baseUrl": "./src",            // error: baseUrl unsupported
    "paths": { "@/*": ["*"] }
  },
  "include": ["./src"]
}

// After: valid on 7.0
{
  "compilerOptions": {
    "moduleResolution": "bundler",
    "rootDir": "./src",
    "types": ["node", "jest"],
    "paths": { "@/*": ["./src/*"] }
  },
  "include": ["./src"]
}

В новой версии удалена опция target, чтобы применялось значение по умолчанию, paths указывают относительно корня проекта, а rootDir и types заданы явно.

Microsoft рекомендует сначала перейти на 6.0. Обновитесь до 6.0, исправьте все предупреждения об устаревании (каждое из них разобрано в анонсе TypeScript 6.0), удалите ignoreDeprecations и только после этого устанавливайте 7.0.

Какие инструменты пока не работают с TypeScript 7?

Инструменты, импортирующие компилятор TypeScript как библиотеку, а также инструменты, обеспечивающие проверку типов в Vue, MDX, Astro, Svelte и шаблонах Angular, пока не работают с TypeScript 7.0, потому что TypeScript 7.0 не предоставляет программного API. Согласно анонсу 7.0 от Microsoft, инструменты, импортирующие компилятор как библиотеку (например, typescript-eslint), должны продолжать работать на TypeScript 6.0 через пакет совместимости @typescript/typescript6. Если ваша настройка линтинга с учётом типов через typescript-eslint опирается на peer-зависимость от typescript, ей потребуется настройка алиасов, описанная в следующем разделе.

Затронуты и встроенные языки. В анонсе 7.0 Microsoft говорится, что проектам на Vue, MDX, Astro и Svelte пока стоит оставаться на TypeScript 6.0. Volar и подобные инструменты добавляют поддержку TypeScript в эти форматы файлов, напрямую обращаясь к компилятору, а у 7.0 нет API, к которому можно было бы обратиться. У проверки типов в шаблонах Angular то же ограничение. Для Angular в анонсе предлагается разделение: используйте tsc из 7.0 в командной строке и в CI, чтобы быстро находить ошибки во всём проекте, а редактор оставьте на 6.0, чтобы проверка шаблонов продолжала работать.

В VS Code специальное расширение Microsoft для TypeScript 7 добавляет в палитру команд две команды — «Disable TypeScript 7 Language Server» и «Enable TypeScript 7 Language Server», — так что вы можете переключать редактор между 6.0 и 7.0 в любой момент. Если после переключения редактор начинает вести себя странно, по-прежнему работает привычный процесс отладки TypeScript в VS Code.

Microsoft планирует вернуть API в TypeScript 7.1, хотя он не будет совпадать со старым. Именно этот выпуск — реалистичный момент для перехода таких интеграций.

Как использовать TypeScript 7 и 6.0 параллельно

Чтобы использовать обе версии в одном репозитории, примените алиасы npm. Направьте имя пакета typescript на пакет совместимости 6.0, а 7.0 установите под другим именем. Тогда инструменты, импортирующие typescript, будут загружать 6.0. Пакет совместимости предоставляет API версии 6.0 и команду tsc6, запускающую 6.0.

В обычном npm-проекте npx tsc после этого будет запускать 7.0. Но есть подвох. Пакет совместимости зависит от полной копии TypeScript 6.0, которая объявляет собственную команду tsc, поэтому за это имя конкурируют два пакета. Пользователи сообщали, что Yarn и Bun могут связывать tsc с 6.0. Скрипт typecheck ниже вызывает файл 7.0 напрямую, поэтому не зависит от того, какой пакет получит имя tsc. Это та самая конфигурация, которую описывает Microsoft, дополненная скриптами:

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  },
  "scripts": {
    "typecheck": "node node_modules/@typescript/native/bin/tsc --noEmit",
    "typecheck:6": "tsc6 --noEmit",
    "lint": "eslint ."
  }
}

typecheck запускает 7.0. typecheck:6 запускает 6.0 — это удобно, чтобы во время миграции убедиться, что оба компилятора дают одинаковый результат. lint через алиас разрешает typescript в 6.0. Чтобы настроить алиас для 6.0 из терминала, выполните npm install -D typescript@npm:@typescript/typescript6. Если ограничиться только этим, вы получите tsc6 и больше ничего, поэтому добавьте и алиас для 7.0.

Выполните npx tsc --version, чтобы узнать, какой компилятор вызывается обычной командой tsc. Microsoft документирует эту конфигурацию только для npm, поэтому, если вы используете pnpm, Yarn или Bun, проверьте результат самостоятельно.

Стоит ли переходить? Рекомендации по ситуациям

Переходить ли на TypeScript 7, зависит от двух факторов: насколько чисто собирается проект на 6.0 и импортирует ли что-нибудь в вашем тулчейне компилятор.

Новый проект: начинайте на 7.0. Если вы мигрируете с Flow на TypeScript, сразу ориентируйтесь на значения по умолчанию 7.0, чтобы не пришлось мигрировать второй раз.

Небольшая кодовая база на чистом TS: перейдите на 6.0, исправьте все предупреждения об устаревании, затем переключайтесь. Выигрыш во времени будет небольшим, зато вы окажетесь на поддерживаемой ветке.

Крупный монорепозиторий: настройте алиас, уже сейчас переведите проверку типов в CI на tsc из 7.0, а линтинг, кодогенерацию и редактор оставьте на 6.0, пока в 7.1 не появится API.

Заключение

TypeScript 7.0 проверяет типы практически так же, как 6.0, только быстрее. Почти всё, что ломается, связано либо с устаревшими опциями из 6.0, либо с инструментами, которым нужен API компилятора. Начните с того, чтобы добиться чистой сборки на 6.0 без ignoreDeprecations. После этого либо переходите полностью, либо добавьте алиас npm и позвольте CI запускать tsc из 7.0, пока ваши инструменты остаются на 6.0 до выхода 7.1.

Часто задаваемые вопросы

tsgo и @typescript/native-preview — это то же самое, что TypeScript 7?

Уже нет. До выхода 7.0 компилятор на Go распространялся в виде превью в пакете @typescript/native-preview, а его команда называлась tsgo. Последняя версия этого пакета — 7.0.0-dev.20260707.2, опубликованная за день до стабильного релиза. В TypeScript 7.0 нативный компилятор входит в обычный пакет typescript и запускается как tsc. Ночные сборки теперь публикуются как typescript@next, поэтому замените tsgo на tsc в своих CI-скриптах.

Ускоряет ли TypeScript 7 сборки на Vite, esbuild или SWC?

Нет. Vite, esbuild и SWC превращают TypeScript в JavaScript, просто удаляя типы без их проверки, поэтому они никогда не вызывают tsc, и время транспиляции у них не меняется. TypeScript 7 ускоряет отдельный этап проверки типов — обычно это tsc --noEmit в CI или pre-commit-хуке — и языковой сервер в редакторе. Если проверка типов не самый медленный этап вашего конвейера, переход не сделает сборку заметно короче.

Работает ли ts-node с TypeScript 7?

Напрямую — нет. ts-node компилирует файлы через API компилятора TypeScript, а в 7.0 этого API нет. При настройке алиасов npm импорт typescript в ts-node разрешается в пакет совместимости 6.0, поэтому ts-node продолжает работать на 6.0, а tsc — на 7.0. Код, использующий только стираемый синтаксис, в последних версиях Node.js можно запускать из файлов .ts вообще без компилятора благодаря удалению типов (type stripping), но проверки типов при этом не выполняется.

Может ли TypeScript 7 по-прежнему компилировать в ES5 для старых браузеров?

Нет. TypeScript 6.0 поднял минимальную поддерживаемую цель до ES2015 и объявил target es5 устаревшим. В 7.0 target es5 приводит к фатальной ошибке. Если вам по-прежнему нужен вывод в ES5, настройте tsc на генерацию ES2015 или новее и обработайте результат с помощью Babel или другого компилятора. Как вариант, компилируйте исходный код на TypeScript напрямую этим внешним инструментом.