Рішення щодо оновлення до 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, навмисно зберігаючи її структуру якомога ближчою до існуючого коду. Цей вибір має значення: саме точний порт, а не переробка, допомагає зберігати відхилення у поведінці на низькому рівні — між 6 та 7.

Що відрізняється на практиці

Набагато швидша перевірка типів

Опубліковані 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() для аналізу програми, ретельно перевірте цей підхід перед тим, як впровадити його у продакшн.

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

Уявіть собі середнього розміру monorepo на 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 значно її усуває; якщо ви покладаєтесь на внутрішні механізми компілятора, почекайте ще одну версію.