Почему переписали фундамент

Большие TypeScript-проекты тратят заметное время на загрузку, typecheck и операции language server. Нативная реализация использует shared-memory parallelism и должна лучше масштабироваться на многоядерных машинах. Команда проекта показывала многократное ускорение и снижение памяти на крупных codebase.

Это особенно важно в агентном workflow. Чем быстрее компилятор отвечает, тем больше циклов «изменить — проверить — исправить» можно выполнить за то же время.

TypeScript 6 как мост

TypeScript 6 стал последним релизом старой JavaScript-кодовой базы и подготовил defaults к новой эпохе: strict включён по умолчанию, module ориентирован на ESM, target — на современный ECMAScript, а глобальные types нужно перечислять явнее.

Перед переходом стоит обновиться до 6.x, убрать deprecated options и включить проверки, которые приближают поведение к 7.0. Это превращает большой прыжок в две контролируемые миграции.

Главное ограничение 7.0

Первая версия TypeScript 7 не предоставляет стабильный programmatic API. Инструменты, которые встраивают компилятор или language service, не могут сразу перейти. Официальный анонс отдельно предупреждает о Vue, MDX, Astro, Svelte и Angular workflows.

Для переходного периода опубликован пакет @typescript/typescript6: можно использовать быстрый tsc версии 7 рядом с API версии 6. Но такая схема требует явной фиксации в CI и документации проекта.

Как принимать решение

Попробуйте TypeScript 7 сначала как отдельный CI check и сравните ошибки, время и совместимость. Не переводите editor всей команды, пока не проверены framework plugins, eslint, test runner и генерация declarations.

Для чистого React/Vite-проекта переход может быть быстрым. Для монорепозитория с custom transformers и embedded languages разумнее дождаться API 7.1. Скорость ценна только тогда, когда не ломает инструменты вокруг компилятора.

Источники

  1. TypeScript — Announcing TypeScript 7.0
  2. TypeScript — Announcing TypeScript 6.0
  3. TypeScript — A 10x Faster TypeScript