IT Developer 19.03.2025

Что нового в TypeScript 5.8? Подробный обзор с примерами

TypeScript 5.8 делает код более надёжным, удобным и быстрым. В этой версии улучшена проверка типов, добавлена поддержка новых возможностей Node.js и оптимизирована компиляция. Если вы обновляетесь с версии 5.6 или 5.7, вас ждёт более строгая проверка кода, улучшенная работа с модулями и ускорение работы компилятора.

Тезисы статьи

  • Безопаснее – строгая проверка типов предотвращает ошибки раньше;
  • Проще работать с модулями – require() в nodenext, ‑‑module node18;
  • Быстрее компиляция – меньше лишней работы благодаря ‑‑libReplacement;
  • Можно запускать TypeScript без компиляции! (‑‑erasableSyntaxOnly).

TypeScript 5.8 делает код ещё надёжнее, а работу – комфортнее. Если вы используете версию 5.6 или 5.7, обновление принесёт много пользы.

Возможность TypeScript 5.6 TypeScript 5.8
Проверка return Ошибки могли быть пропущены Строгая проверка всех веток
require() в nodenext Вызывало ошибку Теперь разрешено
‑‑module node18 Не существовало Новый режим для стабильности
‑‑erasableSyntaxOnly Не было Можно запускать TS без компиляции
‑‑libReplacement Автоматическая замена библиотек Можно отключить замену (ускоряет компиляцию)
.d.ts‑файлы Потеря вычисляемых свойств Теперь сохраняют точные имена

1. Строгая проверка типов в return

Теперь каждая ветка return проверяется отдельно, что помогает находить ошибки, связанные с any или несовместимыми типами.

До TypeScript 5.8 (ошибка могла остаться незамеченной):

declare let anyValue: any;

function getNumber(flag: boolean): number {
  return flag ? anyValue : "не число";  // Ошибка могла не выявляться, если `anyValue` — `any`
}

Теперь в TypeScript 5.8:

function getNumber(flag: boolean): number {
  return flag ? 10 : "oops";   // Ошибка: 'string' не может быть присвоен 'number'!
}

Теперь TypeScript не пропустит ошибку, даже если одна из веток содержит any.


2. Поддержка require() для ESM в ‑‑module nodenext

Теперь в Node.js можно использовать require() для ESM‑модулей, если включён ‑‑module nodenext.

До TypeScript 5.8:

const { readFile } = require("fs/promises"); // Ошибка: 'fs/promises' является ESM‑модулем

Теперь в TypeScript 5.8:

const { readFile } = require("fs/promises"); // Код компилируется без ошибок

Это облегчает миграцию с CommonJS на ESM.


3. Новый режим модулей ‑‑module node18

Теперь TypeScript может компилировать код строго в соответствии с возможностями Node.js 18, без новых экспериментов.

Пример разницы:

// Ошибка в режиме `node18`, но разрешено в `nodenext` const esmModule = require("./module.mjs");

Однако в node18 разрешены import assertions:

import data from "./data.json" assert { type: "json" }; // OK в node18

Этот режим полезен для больших production‑проектов, которым нужна предсказуемость.

4. Флаг ‑‑erasableSyntaxOnly — запуск TypeScript без компиляции

TypeScript теперь может проверять, можно ли просто удалить типы без трансформации кода. Это нужно для запуска .ts‑файлов в Node.js без компиляции.

Это особенно полезно при прямом выполнении TypeScript‑кода в Node.js 23.6 с флагом ‑‑experimental‑strip‑types, обеспечивая, что код можно безопасно транспилировать простым удалением типо

Корректный код (будет работать в Node.js напрямую):

function greet(name: string) { console.log(`Привет, ${name}!`); }

Некорректный код (нельзя просто удалить enum, он генерирует код):

enum Direction { Up, Down, Left, Right } // Ошибка с `‑‑erasableSyntaxOnly`

Теперь можно запускать .ts‑файлы без компиляции, если они не используют конструкции, требующие трансформации.


5. Флаг ‑‑libReplacement — контроль замен стандартных объявлений

Теперь можно запретить TypeScript автоматически заменять стандартные библиотеки (lib.dom.d.ts, lib.esnext.d.ts и т. д.), что ускоряет компиляцию.

Как включить строгий режим?

{ "compilerOptions": { "libReplacement": false } }

Это полезно, если ваш проект не использует кастомные определения API.


6. Сохранение вычисляемых имён свойств в .d.ts‑файлах

Теперь TypeScript сохраняет точные имена вычисляемых свойств в .d.ts, улучшая поддержку Symbol.toStringTag, динамических ключей и export.

До TypeScript 5.8:

export declare class MyClass { [x: string]: number; // Потеря информации }

Теперь в TypeScript 5.8:

export declare class MyClass { [propName]: number; // Теперь сохраняется! }

Благодаря этому .d.ts‑файлы теперь точнее отражают код.

Что ждет в TypeScript 7.0?

TypeScript 7.0 станет важным этапом развития языка, предлагая значительное ускорение компиляции и снижение потребления ресурсов благодаря переходу на нативную реализацию компилятора на Go.

  • Компилятор TypeScript будет переписан с JavaScript на Go, что обеспечит прирост производительности и лучшее управление памятью.
  • Ожидается ускорение компиляции в 9‑13 раз, например, сборка VS Code сократится с 77,8 сек до 7,5 сек.
  • Проверка типов и сборка станут быстрее и стабильнее, что улучшит опыт работы с кодом.
  • Новый компилятор будет потреблять меньше оперативной памяти, что важно для больших проектов и сред с ограниченными ресурсами.
  • Улучшенная интеграция с редакторами кода ускорит анализ кода, вывод ошибок и рефакторинг.
  • Будет лучше поддерживаться в VS Code, WebStorm, Neovim и других IDE.
  • Переход к TypeScript 7.0 начнётся с версий 5.8+ и 6.x, которые подготовят инфраструктуру для нового компилятора.
  • Полноценный релиз TypeScript 7.0 на Go обеспечит высокую производительность и более эффективную работу компилятора.

Native реализация

Новая Native реализация для TypeScript 7.0 уже способна загружать многие популярные TypeScript‑проекты, включая сам компилятор TypeScript. Вот результаты замера времени выполнения tsc на некоторых популярных репозиториях GitHub разных размеров:

Проект Размер (LOC) Current Native Ускорение
VS Code 1,505,000 77.8s 7.5s 10.4x
Playwright 356,000 11.1s 1.1s 10.1x
TypeORM 270,000 17.5s 1.3s 13.5x
date‑fns 104,000 6.5s 0.7s 9.5x
tRPC (server + client) 18,000 5.5s 0.6s 9.1x
rxjs (observable) 2,100 1.1s 0.1s 11.0x

Скорость редактора

Большая часть времени разработчика тратится на редакторы, и именно здесь производительность имеет наибольшее значение. Мы хотим, чтобы редакторы быстро загружали большие проекты и быстро реагировали во всех ситуациях.

Современные редакторы, такие как Visual Studio Code, обладают превосходной производительностью, если базовые языковые службы также быстры. С нашей собственной реализацией мы сможем обеспечить невероятно быстрые возможности редактора.

Теги: