TypeScript 7.0: навіщо компілятор переписали на Go і що зміниться у твоєму проєкті

Коротка відповідь. TypeScript 7.0 (вийшов 8 липня 2026) – це повний нативний порт компілятора, тайпчекера і language server на Go. Команда TypeScript заявляє прискорення 7.7–11.9× на реальних проєктах – це vendor-заміри, але їх легко перевірити самому, і нижче є інструкція. Для більшості React/Next-проєктів міграція зводиться до оновлення tsconfig під нові строгі дефолти; найболючіше – видалений baseUrl, types: [] за замовчуванням і мертвий target: es5. Якщо твій стек залежить від Vue/MDX/Astro/Svelte-тулінгу – тобі поки на 6.x: програмний API обіцяють лише у 7.1.

Що саме переписали і чому

Не «частину», не «експериментальний режим» – увесь компілятор: tsc, тайпчекер і language server. Мета, за словами команди, – «нативний порт TypeScript на Go, який може взяти максимум від сучасного заліза»: багатопоточність замість однопоточного JS-рантайму.

Чому це важливо розуміти: попередні роки екосистема вирішувала повільність tsc обхідними шляхами – esbuild/SWC транспілювали без перевірки типів, а сам тайпчекінг лишався вузьким місцем CI і редактора. TypeScript 7 атакує саме тайпчекінг.

Технічно новий компілятор ще й паралелиться керовано: експериментальні флаги --checkers N (за замовчуванням 4 воркери тайпчекінгу), --builders N для project references і --singleThreaded, щоб усе вимкнути. В анонсі наводять приклад: VS Code з --checkers 8 збирається за 7.51 с проти 10.6 с на дефолтних налаштуваннях.

Що означає «10×» насправді

Цифри з офіційного анонсу (TypeScript 6 → 7, повна збірка):

Проєкт	Було	Стало	Прискорення
VS Code	125.7 с	10.6 с	11.9×
Sentry	139.8 с	15.7 с	8.9×
Bluesky	24.3 с	2.8 с	8.7×
Playwright	12.8 с	1.47 с	8.7×

Два чесні уточнення. Перше: це заміри самої команди TypeScript на обраних нею проєктах – класичний vendor benchmark, хай і правдоподібний. Друге: найвідчутніший виграш не в CI, а в редакторі – відкриття файла з помилками у VS Code прискорилось із 17.5 с до ~1.3 с, а пам'ять знизилась на 6–26% залежно від проєкту. Окремо заявлено, що новий language server дає на 80% менше невдалих команд і на 60% менше крашів сервера – якщо у тебе великий monorepo, ти знаєш, про що це.

Як повторити benchmark у своєму repo

Не вір ні мені, ні вендору – міряй своє:

# 1. Зафіксуй базову лінію на поточній версії
npx tsc --version
time npx tsc --noEmit

# 2. Постав TypeScript 7 поруч (side-by-side, нічого не ламаючи)
npm install -D typescript@latest @typescript/typescript6

# 3. Та сама перевірка новим компілятором
time npx tsc --noEmit

# 4. За потреби – старий компілятор лишився доступним як tsc6
time npx tsc6 --noEmit

Запусти кожен варіант 3–5 разів (перший прогін холодний), порівнюй медіану. Якщо різниця менша за 2× на чистому тайпчекінгу – подивись, чи не впирається твій build у щось інше: генерацію коду бандлером, ESLint, тести.

Сумісність: що обіцяють і де дрібний шрифт

Офіційна гарантія звучить так: код, який чисто компілюється TypeScript 6.0 з увімкненим stableTypeOrdering і без ignoreDeprecations, має компілюватись ідентично в 7.0. Тобто міграційний шлях: спершу 6.x із майбутніми дефолтами, потім 7 – без сюрпризів.

Але 7.0 перетворює депрекейти на hard errors і міняє дефолти. Найважливіші:

• strict: true – тепер за замовчуванням;
• module: esnext замість commonjs; module: amd/umd/systemjs/none – видалені;
• target: es5 більше не підтримується, downlevelIteration – видалено;
• moduleResolution: node/node10 → лише nodenext або bundler;
• baseUrl видалено – шляхи тепер через paths відносно root;
• types: [] замість автоматичного підхоплення всіх @types/* – глобальні декларації треба перелічити явно: "types": ["node", "vitest/globals"];
• rootDir: ./ за замовчуванням – якщо конфіг лежить поза src, пропиши "rootDir": "./src" явно;
• esModuleInterop і allowSyntheticDefaultImports не можуть бути false.

Є й одна поведінкова зміна в самій мові: у template literals емодзі та інші багатобайтові символи тепер обробляються як один юніт, а не як сурогатна пара UTF-16. Якщо у тебе є утиліти, що ріжуть рядки по «символах», – перевір їх окремо.

Міграційний чекліст для React/Next-проєкту

1. Онови 6.x до останньої і ввімкни stableTypeOrdering. Почисти всі depreciation warnings – це 90% майбутньої міграції.
2. Перевір tsconfig проти списку вище. Найчастіші правки: замінити baseUrl + відносні paths; додати явний types; прописати rootDir.
3. Постав 7.0 side-by-side (npm install -D typescript@latest @typescript/typescript6) і ганяй обидва в CI тиждень-два: tsc --noEmit новим, tsc6 --noEmit старим. Розбіжності – сигнал.
4. Редактор: для VS Code є окреме розширення TypeScript 7; Visual Studio вмикає його автоматично за workspace.
5. JS-файли з JSDoc: аналіз JavaScript переписаний – @enum більше не розпізнається, @class не робить функцію конструктором, постфіксний ! у JS не підтримується. Якщо у тебе легасі з JSDoc-типами, це окремий фронт робіт.

Коли НЕ оновлюватись у день релізу

• Vue, MDX, Astro, Svelte. Їхній тулінг сидить на програмному API TypeScript 6, якого в Go-версії поки немає – API обіцяють у 7.1. До того часу ці проєкти фактично прив'язані до 6.x (він лишається підтримуваним і доступним як tsc6).
• Кастомні transformers і будь-що, що імпортує typescript як бібліотеку – та сама причина: нового API ще немає, у 7.1 він буде «новим і іншим», тож готуйся до переписування інтеграцій.
• CI, де важлива бінарна відтворюваність: нові паралельні --checkers – експериментальні; для початку можеш зафіксувати --singleThreaded і порівняти стабільність.

Якщо ж у тебе звичайний React/Next-застосунок без екзотики – відкладати немає сенсу: виграш у швидкості редактора відчувається щодня, а релізний цикл тепер обіцяють кожні 3–4 місяці, тож 6.x почне відставати швидко.

Типові помилки

1. Мігрувати одним стрибком замість «останній 6.x → почистити warnings → 7.0». Гарантія сумісності працює лише через цей міст.
2. Забути про types: [] і довго дивуватись, куди зникли глобальні типи node чи тестового фреймворка.
3. Порівнювати непорівнюване: міряти 6.x з холодним кешем проти 7.0 з гарячим і постити «у нас 20×».
4. Чекати прискорення build-у, який і так робив esbuild. Go-порт прискорює тайпчекінг; якщо транспіляцію давно робить бандлер, зміниться саме --noEmit-перевірка і редактор.

Практичне завдання

Візьми свій робочий проєкт і проведи міні-аудит на 20 хвилин: (1) заміряй time npx tsc --noEmit на поточній версії; (2) перевір tsconfig проти списку змінених дефолтів і випиши, що доведеться правити; (3) постав 7.0 side-by-side і заміряй ще раз. У тебе буде не думка з інтернету, а власна цифра і конкретний список правок – рівно те, що потрібно, щоб аргументувати міграцію команді.

До речі, про аргументацію на співбесідах: питання «що нового в TypeScript» тепер має конкретну правильну відповідь – і вона не «satisfies». Базу генериків, яка не змінилась ні на йоту, можна освіжити в розборі TypeScript generics, а як TypeScript працює в парі з фреймворком – у гайді по Next.js і новому розборі Instant Navigations у Next.js 16.3.