TypeScript 6.0 вышел в стабильный релиз 23 марта 2026 года. Но важно понимать его не как релиз с одной “вау”-фичей, а как переходный этап между TypeScript 5.9 и TypeScript 7: здесь есть новые возможности, но большая часть практической ценности для реального проекта находится в измененных дефолтах и более жестком отношении к старому tsconfig.

Здесь коротко и по делу: что реально нового, что изменилось по умолчанию и какие настройки стоит проверить до апгрейда, чтобы миграция не расползлась по проекту.

Что в TypeScript 6.0 реально новое и полезное

es2025 для target и lib

В TypeScript 6.0 появился es2025 для target и lib. Это не про новую языковую революцию, а про более актуальные встроенные типы. Например, сюда уже попадают типы для RegExp.escape, а часть деклараций переезжает из esnext в es2025.

Для фронтенда это полезно по простой причине: меньше “плавающих” зависимостей от esnext, когда проекту на самом деле нужны уже достаточно стабильные API.

Встроенные типы для Temporal, но не “автоматом везде”

TypeScript 6.0 действительно добавил встроенные типы для Temporal API, но здесь есть важная оговорка: пользоваться ими можно через --target esnext, "lib": ["esnext"] или более точечный esnext.temporal.

Если проект живет на dom + es2025, глобалы Temporal сами собой не появятся. Но хорошая новость все равно есть: больше не нужно городить отдельные типовые костыли, если ранняя проверка Temporal нужна уже сейчас.

Если тема дат уже стала болезненной для проекта, это как раз тот случай, где релиз реально полезен. Более подробно про саму модель времени я уже разбирал в Temporal в JavaScript: как наконец перестать ошибаться в работе с датами.

Поддержка subpath imports с #/

TypeScript 6.0 теперь поддерживает subpath imports, начинающиеся именно с #/, при moduleResolution: nodenext | bundler.

Это тонкое, но важное уточнение. Поддержка package imports с #something сама по себе не новость, а вот возможность писать короткий префикс вроде #/utils/date без лишнего сегмента появилась только теперь и синхронизирована с более новыми релизами Node.js 20.

Для проектов со сборщиком это аккуратный способ уйти от длинных относительных путей без возврата к полумагии вокруг baseUrl.

moduleResolution bundler теперь можно сочетать с module commonjs

Раньше эта комбинация была запрещена. Теперь она допустима и часто оказывается нормальным промежуточным шагом для проектов, которые еще не готовы полностью перейти на module: preserve или nodenext, но уже хотят уйти от старого moduleResolution: node.

Это не самая громкая новость релиза, но на практике она полезнее многих “маркетинговых” фич.

Менее капризный вывод типов в generic-вызовах и JSX

В TypeScript 6.0 поменялась проверка типов для функциональных выражений в generic-вызовах, в том числе в generic JSX-сценариях. Для фронтенда это важнее, чем звучит: часть сложных React-конструкций теперь проверяется последовательнее, особенно когда внутри есть this-less functions.

Это не означает массовую ломку, но в отдельных местах компилятор теперь может либо поймать реальную ошибку, либо попросить явный type argument там, где раньше молчал.

--stableTypeOrdering

Появился флаг --stableTypeOrdering, но это важно понимать правильно: он нужен прежде всего для более чистого сравнения поведения TypeScript 6.0 и TypeScript 7.0, особенно по .d.ts-выводу и порядку типов.

Для обычного приложения это не причина обновляться и не флаг “включить всем”. Он полезен для библиотек, дизайн-систем и миграций, где важен дифф генерируемых типов. При этом флаг может ощутимо замедлять type-checking.

Какие дефолты изменились

Вот здесь у многих и начнутся реальные сюрпризы.

strict теперь по умолчанию true

Если проект раньше полагался на старый дефолт, теперь это уже не сработает. Проектам, которые сознательно не живут с strict, придется явно писать:

{
  "compilerOptions": {
    "strict": false
  }
}

module теперь по умолчанию esnext

Это логичный сдвиг под современный ESM-мир, но старые сборки и старые ожидания от конфига из-за этого могут начать вести себя по-другому.

target теперь по умолчанию следует за актуальным ES-стандартом

Здесь важна формулировка. В TypeScript 6.0 текущий default фактически равен es2025, но это плавающий дефолт: команда описывает его как “current-year ES version”, а не как навсегда зафиксированный es2025.

Идея простая: TypeScript больше не делает вид, что большинство новых проектов по-прежнему живет в мире старых рантаймов.

noUncheckedSideEffectImports теперь по умолчанию true

Это полезное ужесточение. Теперь опечатки и странные импорты ради побочного эффекта чаще будут ловиться раньше.

libReplacement теперь по умолчанию false

Это не самое заметное изменение, но оно полезно для скорости и предсказуемости. TypeScript меньше делает лишней работы там, где проект сам не просил дополнительную магию.

rootDir теперь по умолчанию равен директории с tsconfig.json

Если раньше проект не задавал rootDir явно и полагался на вывод TypeScript, теперь это может повлиять на структуру выходных файлов. Типичный симптом: вместо dist/index.js внезапно появляется что-то вроде dist/src/index.js.

types теперь по умолчанию []

Это одно из самых практичных изменений релиза.

Раньше TypeScript по умолчанию подтягивал все подряд из node_modules/@types. Теперь он этого не делает. Это быстрее и чище, но многим проектам после апгрейда придется явно указать нужные типы:

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

Если после обновления появляются ошибки вроде Cannot find name 'process', describe или fs, почти наверняка причина именно здесь. Если очень нужно временно вернуть старое поведение, официальный анонс допускает types: ["*"], но это скорее запасной выход, чем хороший долгосрочный выбор.

Что уже устарело и что готовить к TypeScript 7

Это, возможно, самая важная часть релиза. И здесь важно не путать два режима: часть вещей уже дает ошибку или не поддерживается в TypeScript 6.0, а часть пока можно пережить через "ignoreDeprecations": "6.0", но в TypeScript 7 эти настройки исчезнут окончательно. Этот флаг откладывает реальную работу по миграции, а не устраняет её: в TypeScript 7 он поддерживаться не будет.

Самые заметные миграционные точки

  • target: es5 deprecated. Нижней реальной целью теперь считается ES2015, а для ES5-вывода TypeScript рекомендует внешний компилятор.
  • --downlevelIteration deprecated. В TypeScript 6.0 сам факт присутствия этой опции уже ведет к deprecation error.
  • moduleResolution: node / node10 deprecated. Для Node.js-проектов логичный путь чаще всего nodenext, для фронтенд-приложений со сборщиком обычно bundler.
  • esModuleInterop: false и allowSyntheticDefaultImports: false больше не поддерживаются как осознанный старый режим. Безопасное interop-поведение теперь считается нормой.
  • alwaysStrict: false тоже уходит. TypeScript исходит из strict-mode semantics, так что старые corner cases вокруг reserved words и this могут всплыть.
  • outFile удален. Если он где-то жив, его уже пора выносить в bundler.
  • Старые import assertions через assert deprecated. Новый синтаксис здесь — with. Это касается не только import ... assert {}, но и import()-сценариев.
  • tsc foo.ts рядом с tsconfig.json теперь явная ошибка. Если запуск без конфига действительно нужен, для этого есть --ignoreConfig.

Что именно делать с baseUrl

baseUrl в TypeScript 6.0 deprecated, и это одна из самых практичных миграционных тем в релизе.

Если baseUrl использовался только как префикс для paths, новый нормальный путь выглядит так:

{
  "compilerOptions": {
    "paths": {
      "@app/*": ["./src/app/*"]
    }
  }
}

Если же baseUrl реально работал в проекте как lookup root для “голых” импортов, то одной заменой префиксов не отделаешься. Тогда нужен и явный catch-all mapping:

{
  "compilerOptions": {
    "paths": {
      "*": ["./src/*"],
      "@app/*": ["./src/app/*"]
    }
  }
}

Для многих фронтенд-проектов именно baseUrl будет самым заметным tsconfig-изменением после апгрейда.

Что фронтенд-команде проверить в первую очередь

Если не хочется читать весь список изменений, вот короткий рабочий список.

1. Явные значения в tsconfig

Если проект зависит от старых неявных дефолтов, лучше перестать на это надеяться. В первую очередь стоит проверить:

  • strict
  • module
  • target
  • rootDir
  • types

2. Поиск по устаревшим настройкам

Сразу стоит проверить, есть ли в репозитории:

  • target: es5
  • downlevelIteration
  • moduleResolution: node
  • baseUrl
  • outFile
  • esModuleInterop: false
  • allowSyntheticDefaultImports: false
  • alwaysStrict: false
  • import assertions через assert

Это самый быстрый способ понять, будет ли апгрейд спокойным или нет.

3. Проверка тестового и node-окружения

После апгрейда легко словить ошибки из-за types: [] по умолчанию. Если проект использует node, jest, vitest или другие глобальные типы, лучше проверить это сразу. Заодно стоит посмотреть на side-effect imports и старые CJS-interop-предположения.

4. Проверка путей вывода и .d.ts

Если в проекте есть этап сборки, который ожидает конкретную структуру выходных файлов, отдельно стоит посмотреть на rootDir. Это как раз тот случай, где ошибка выглядит “странно”, хотя причина вполне конкретная.

Если проект публикует декларации, стоит сравнить и .d.ts-вывод: там может всплыть и rootDir, и порядок типов, и старые предположения вокруг interop.

5. Проверка React-кода с generic JSX и callback-типами

В релизе появились изменения в проверке типов для функциональных выражений в generic-вызовах, особенно в JSX-сценариях с дженериками. Это не массовая ломка, но в сложных компонентах может всплыть там, где раньше TypeScript молчал. Иногда достаточно добавить явный тип и пойти дальше.

Что в 6.0 особенно интересно именно фронтенду

Если убрать переходный шум вокруг TypeScript 7, для фронтенда в TypeScript 6.0 я бы выделил пять вещей.

1. types: [] по умолчанию

Это не самая красивая фича для анонса, но на реальных проектах она одна из самых полезных. Меньше случайного мусора из @types, лучше предсказуемость, меньше лишней работы у компилятора.

2. baseUrl наконец уходит

Это хорошо. Слишком много проектов годами жили на полумагической схеме с baseUrl, которую потом никто не хотел трогать.

3. Более честная проверка generic JSX и callback-типов

Для сложных React-компонентов это важнее, чем кажется. TypeScript стал последовательнее в тех местах, где раньше поведение зависело от формы записи функции и порядка свойств.

4. dom.iterable и dom.asynciterable по сути въехали в dom

Это небольшой, но приятный quality-of-life бонус. Для браузерного кода меньше лишней возни с lib, когда работа идет с NodeList, HTMLCollection и другими DOM-коллекциями.

5. Встроенный Temporal и более современные дефолты

Тема дат и времени никуда не делась, а типовая поддержка Temporal здесь реально полезна. Плюс общий сдвиг к strict: true, современному module и current-year target делает новый baseline заметно адекватнее для фронтенда 2026 года.

Итог

TypeScript 6.0 не выглядит релизом с одной большой эффектной фичей, и это нормально. Это стабильный переходный релиз: он одновременно добавляет полезные вещи вроде es2025, Temporal, #/-импортов и более аккуратного вывода типов, но главный смысл для большинства команд все равно в другом. Нужно привести tsconfig к современной реальности и убрать то, что TypeScript 7 все равно перестанет терпеть.

Наиболее конкретный следующий шаг — инвентаризация tsconfig.json: явная фиксация strict, target, module, types и rootDir, а затем поиск по baseUrl, moduleResolution: node, downlevelIteration, outFile, старому assert-синтаксису и legacy interop-настройкам. Уже этого хватит, чтобы понять, будет переход на TypeScript 6.0 короткой рутиной или маленькой миграцией со списком хвостов.