TypeScript 6.0: що змінилося насправді, що зламається після апдейту і чи варто оновлюватися вже зараз
Практичний розбір TypeScript 6.0 після релізу в березні 2026 року: нові дефолти, внутрішні зміни, чому збірки часто стали швидшими, де міграція болить найбільше, як перейти з TypeScript 5 без сюрпризів, і що вже зараз видно по TypeScript 7 та native-напряму команди Microsoft.
головне на старті
TypeScript 6.0 варто сприймати не як набір дрібних фіч, а як реліз, у якому команда нарешті почала жорсткіше прибирати старі дефолти. Через це одні проєкти просто пришвидшаться, а інші вперше побачать, чому їхній tsconfig тримався на мовчазних припущеннях.
types тепер за замовчуванням порожній масив. У release notes команда прямо пише, що в частини проєктів це дало приріст часу збірки на 20-50%. [2]У березні 2026 року Microsoft випустив TypeScript 6.0. Якщо коротко, це реліз не стільки про одну велику фічу, скільки про нові базові правила гри. Команда змінила дефолти, вичистила частину старого конфігураційного багажу і підсунула екосистемі більш сучасну відправну точку. [1][2]
В офіційному анонсі це добре видно по тону. Там немає спроби продати реліз як щось «космічне». Натомість є чесний список речей, які доведеться підкрутити відразу: types, rootDir і старі припущення про компіляторні дефолти. Це неприємно, але саме так зазвичай і виглядає доросле оновлення інфраструктурного інструмента. [1]
Ще один важливий контекст: TypeScript 6 не існує сам по собі. Його треба читати в парі з курсом на TypeScript 7. Ще в 2025 році команда оголосила, що 6.x буде JavaScript-гілкою з проміжними деprecations, а 7.x стане native-напрямом із tsgo, новою архітектурою і набагато швидшим type-checking. [3][4]
У TypeScript 6 найцікавіше не на поверхні API, а в тому, як команда переглянула дефолти і внутрішні витрати компілятора на великі репозиторії.
types більше не тягне все підряд
Найкорисніша зміна для реальних монорепозиторіїв. Раніше TypeScript міг автоматично перебирати все, що лежить у node_modules/@types. У 6.0 дефолтне значення types стало [], і це прямо зменшує зайву роботу компілятора. Команда пише, що в частини проєктів це дало 20-50% покращення часу збірки. [2]
rootDir перестав бути магією
Сучасний JavaScript тепер не виглядає як edge-case
strict тепер увімкнений за замовчуванням. module тепер за замовчуванням esnext. target за замовчуванням рухається до актуального стабільного ECMAScript, зараз це es2025. Тобто 6.0 уже не прикидається, що старі дефолти досі найтиповіші. [1]
TS 6.0 не зводиться лише до болючих налаштувань. Там є і нормальні мовні та платформні речі, які з часом стануть просто новою нормою.
• Підтримка import attributes. Це важливо для платформних сценаріїв і сучасного ESM-ланцюжка. [2]
• Підтримка
export defer. Поки це не масова щоденна фіча, але для екосистеми модулів це важливий крок. [2]• Новий
--module node20. Це ще одна ознака того, що TypeScript дедалі ближче підлаштовується під реальні режими Node, а не під абстрактну суміш із минулого. [2]• Нові типи для
Temporal. Якщо екосистема часу й дат вас уже втомила, це одна з тих речей, які виглядають дрібними до першого реального проєкту. [2]•
lib.dom.iterableіlib.dom.asynciterableфактично вбудовані вdom. Це маленький, але дуже здоровий крок до менш плутаногоtsconfig. [2]
У більшості команд реліз ламається не через мову, а через накопичений конфігураційний борг. Нижче саме ті місця, де TypeScript 6 найчастіше зачіпає реальні проєкти. [1][2][4]
Збірка починає складати файли у дивні шляхи на кшталт dist/src/... замість очікуваної структури. Це майже завжди сигнал, що вам треба явно задати rootDir. [1]
Проєкт, який роками жив без strict, раптом починає кричати на все. Це не баг. У 6.0 strict став дефолтом, тому стару поведінку треба або прийняти, або явно вимкнути. [1]
Частина команд сприйме покращення продуктивності як магію і пропустить головне. Щоб реально виграти, треба не просто оновити пакет, а вичистити tsconfig так, щоб компілятор робив менше зайвого. [2]
Висновок
Найкращий спосіб пережити апдейт на 6.0 не героїзм, а короткий міграційний спринт із перевіркою types, rootDir, strict і legacy-опцій ще до масового rollout-у.
Цей порядок зазвичай працює краще, ніж просто оновити версію і дивитися, що впало.
Спочатку зафіксуйте поточний стан збірки і type-check у CI
Вам потрібна точка відліку. Без неї неможливо відділити нові проблеми релізу від старих проєктних боргів.
Окремо вирішіть, чи ви приймаєте strict, чи тимчасово фіксуєте стару поведінку
У проді краще мати явне рішення, ніж випадкову зміну якості перевірки по всьому репо. [1]
Прокрутіть оновлення на одному великому пакеті або на одному app entrypoint, а не на всьому репо одразу
Це дає нормальний контроль над регресіями і одразу показує, де у вас справжній конфігураційний борг.
TypeScript 6 не є релізом, який однаково добре підходить усім. Тут усе дуже залежить від того, наскільки сучасний у вас конфіг і наскільки болить швидкість великих репозиторіїв.
Оновлюватися вже зараз
Сучасний Node- або bundler-стек, ESM або близько до нього, явні типи середовища, мінімум legacy-конфігу, реальна потреба зменшити шум у збірках і підготувати команду до 7.0.
Оновлюватися після короткої підготовки
Монорепо, де tsconfig накопичувався роками, але команда готова витратити кілька днів на розчищення types, rootDir, baseUrl і модульних режимів.
Краще спершу стабілізувати основу
Старий проєкт без strict, з купою глобальних типів, старим резолвінгом модулів і чутливими build pipelines. Тут оновлення без підготовки майже гарантовано перетвориться на хаос.
| Comparison point | TypeScript 5.x | TypeScript 6.0 |
|---|---|---|
types | Часто мовчки перебирає все в @types | За замовчуванням [], усе важливе краще вказувати явно |
strict | false за замовчуванням | true за замовчуванням |
rootDir | Часто інференс із source tree | За замовчуванням директорія tsconfig.json |
module | Старі дефолти довше жили разом | Дефолт рухається в бік esnext і сучасного ESM |
| Ставлення до legacy | Більше режимів сумісності | Більше deprecations як підготовка до 7.0 |
Соціальні обговорення добре показують, де люди реально чекають болю або, навпаки, найбільшого виграшу.
Якщо дивитися на 6.0 лише як на черговий реліз, легко пропустити головне. TypeScript 6 потрібен ще й для того, щоб підготувати екосистему до 7.0. Про це команда говорить прямо ще з моменту анонсу native-напряму. [3]
У грудневому оновленні про TypeScript 7 команда вже писала, що tsgo можна впевнено використовувати для type-checking, що підтримка --build, project references та --incremental майже дійшла до великого рівня паритету, а повні збірки нерідко показують близько 10x прискорення порівняно з гілкою 6.0. [4]
Але тут теж не треба романтизувати. У тому ж оновленні команда чесно попереджає про відмінності в API і про те, що частина deprecations із 6.0 стане вже жорсткішою в 7.0. Тобто TypeScript 6 треба сприймати як вікно, у якому можна привести конфіг до сучасного стану до того, як native-лінійка стане основною. [4]
TypeScript 6.0 вийшов не для того, щоб усім було комфортно. Він вийшов для того, щоб компілятор перестав вічно тягнути старі звички, які вже не відповідають сучасному стеку JavaScript. І в цьому сенсі реліз вийшов чесним.
Якщо у вас охайний сучасний проєкт, апдейт на 6.0 виглядає логічним уже зараз. Ви отримаєте передбачуваніший tsconfig, менше зайвих глобальних типів і нормальну підготовку до того, що далі принесе 7.0.
Якщо ж ваш проєкт роками спирався на неявні дефолти, то TypeScript 6 просто покаже це без прикрас. І це теж корисно. Бо значно краще виявити конфігураційний борг на 6.0, ніж зустрітися з ним пізніше вже в момент, коли команда захоче серйозно пробувати tsgo і native-лінійку.
Ні. Але якщо у вас сучасний стек і ви все одно планували чистити `tsconfig`, відкладати надовго сенсу мало. Якщо ж проєкт сильно залежить від старих дефолтів, міграцію краще робити окремим коротким технічним етапом.
Для багатьох команд це нова поведінка `types`. Саме вона часто дає відчутний виграш у швидкості, але водночас вимагає явніше описати, які глобальні типи реально потрібні проєкту.
Так, але з нормальним міграційним підходом. Це не той реліз, який варто оновлювати наосліп. Спочатку перевірте `types`, `rootDir`, `strict`, модульні режими і CI.
Команда вже показала серйозний прогрес по native-лінійці `tsgo`: type-checking, `--build`, project references і `--incremental` уже дійшли до високого рівня готовності, а в окремих бенчмарках приріст швидкості близький до 10x. Але 7.0 ще вимагає уваги до API-відмінностей і сумісності екосистеми.
Пов'язані статті
AI SEO / GEO у 2026: ваші наступні клієнти — не люди, а агенти
Пошук зміщується від кліків до відповідей. Боти та AI-агенти сканують, цитують, рекомендують і дедалі частіше купують. Дізнайтесь, що таке AI SEO / GEO, чому класичного SEO вже недостатньо, і як PAS7 Studio допомагає брендам перемагати у «агентному» вебі.
Найпотужніший чіп від Apple? M5 Pro і M5 Max б'ють рекорди
Аналітичний розбір Apple M5 Pro і M5 Max станом на березень 2026 року. Пояснюємо, чому ці чіпи можна вважати найпотужнішими професійними ноутбучними SoC від Apple, як вони виглядають на тлі M4 Pro, M4 Max, M1 Pro, M1 Max і що показують у порівнянні з актуальними Intel та AMD.
Artemis II і код, який веде до Місяця
У цьому блозі розбираємо місію NASA Artemis II, яка стартувала 1 квітня 2026 року, і пояснюємо, що вона насправді говорить про сучасну інженерію: бортове ПЗ, резервні контури, симуляції, телеметрію, людський контроль і дуже обережну роль ШІ в космічній сфері.
Автоматичне тегування та пошук збережених посилань
Інтеграція з GDrive/S3/Notion для автоматичного тегування та швидкого пошуку через пошукові API
Професійна розробка для вашого бізнесу
Створюємо сучасні веб-рішення та боти для бізнесу. Дізнайтеся, як ми можемо допомогти вам досягти цілей.