Node.js 24: встроенный TypeScript и ESLint 10 для модерна

[hannadev]

Экосистема Node.js сделала очередной рывок вперед. Node.js 24 привносит встроенную поддержку TypeScript прямо из коробки, а ESLint 10 переходит на плоский конфиг и наконец-то правильно работает с JSX. Если ты ещё не обновился - самое время разобраться, что изменилось и почему это важно.

Включена поддержка ESM как стандарта для модульной разработки. Теперь можно писать код на современном JavaScript без лишних танцев с CommonJS. А если ты работаешь с TypeScript - вообще боль кончилась.

TypeScript прямо в Node.js: без танцев с компилятором

До недавних пор запустить TypeScript-файл в Node.js означало либо предварительно компилировать его через tsc, либо использовать какой-нибудь бойлерплейт вроде ts-node. Это было раздражающе медленно и отнимало время на настройку.

Node.js 24 поддерживает type stripping - механизм, который на лету стирает типы и запускает код. Это работает для erasable-синтаксиса: обычных type annotations, interfaces, type-алиасов. Просто пиши node index.ts и готово.

Но есть важный нюанс: полная трансформация TypeScript-функционала (enum, декораторы, path aliases, namespace) по-прежнему требует честного компилятора. Node.js не будет генерировать JavaScript код для таких конструкций - выбросит ошибку. Если тебе нужна полная поддержка - используй tsc как и раньше. Это логично: встроенная поддержка - это не замена TypeScript-компилятору, а ускорение простого случая.

Чтобы включить type stripping, просто добавь флаг при запуске или настрой tsconfig.json с опцией erasableSyntaxOnly: true. Вот что примерно должно быть в конфиге:

• "noEmit": true - TypeScript не будет генерировать JS (это делает Node)
• "target": "esnext" - не опускай синтаксис на старые версии
• "module": "nodenext" - используй современные модули
• "rewriteRelativeImportExtensions": true - Node.js переписывает расширения импортов
• "verbatimModuleSyntax": true - точная запись того, что ты импортируешь

Преимущество очевидно: нет source maps, нет дополнительного процесса сборки, быстрее старт приложения. Идеально для скриптов, CLI-утилит и быстрого прототипирования.

ESLint 10: плоский конфиг и наконец-то JSX

ESLint долгое время был болезненной точкой в экосистеме JavaScript. Конфигурация через .eslintrc.json или .eslintrc.js была запутанной, перегруженной вложенностью и магией. ESLint 10 переписал всё с нуля.

Главное изменение: старый формат конфига больше не поддерживается. Теперь всё идет через eslint.config.js (или eslint.config.mjs для ESM). Конфиг теперь - это просто массив объектов конфигурации. Звучит просто, и это действительно просто.

Второе большое изменение касается JSX. Раньше ESLint не трекил JSX-идентификаторы как полноценные ссылки в scope. Это приводило к странным false positives: линтер говорил, что переменная не используется, хотя ты явно используешь её в JSX-элементе. Теперь это работает корректно, и анализ scope соответствует тому, что разработчик ожидает.

Переход на новый конфиг требует времени, но оно того стоит:

• Плоский формат - легче читать и поддерживать
• ESM-native - используются import, а не require
• Явное указание файлов - для каждого set конфигов ты точно знаешь, какие файлы попадают под правила
• Встроенные type definitions - Espree и ESLint Scope теперь поставляются с TypeScript-дефинициями (вместо Definitely Typed)

Вот пример минимального конфига для TypeScript-проекта:

import js from "@eslint/js";
import typescript from "typescript-eslint";
import globals from "globals";

export default typescript.config(
  js.configs.recommended,
  ...typescript.configs.recommendedTypeChecked,
  {
    languageOptions: {
      globals: globals.node,
      parserOptions: {
        projectService: true,
        tsconfigRootDir: import.meta.dirname,
      },
    },
  },
  {
    files: ["**/*.js", "**/*.mjs"],
    ...typescript.configs.disableTypeChecked,
  },
  {
    ignores: ["dist/**", "node_modules/**"],
  }
);

Видишь? Нет магии, всё понятно. Для React + Next.js будет чуть больше конфигов, но логика та же - ты явно указываешь, что гдетится.

TypeScript-aware линтинг без боли

Это килллер-фича для тех, кто работает с типами. typescript-eslint теперь неразрывно связана с ESLint 10, и type-aware правила работают наконец нормально.

Типизированный линтинг - это когда ESLint не просто смотрит на синтаксис, а понимает семантику: какого типа переменная, безопасна ли операция, может ли быть undefined. Например, правило no-unsafe-member-access или strict-void-return работают корректно только если ESLint понимает типы.

Прежде это было медленно и требовало костылей. Теперь с typescript-eslint 8.44+ и выше интеграция гладкая:

• projectService: true - автоматически подхватывает tsconfig.json
• type-aware rules включаются просто через спред конфига
• Performance - оптимизирована кеширование типов

Что даёт type-aware линтинг:

• Ловит ошибки, которые статический анализ просто не видит
• Помогает с refactoring - если ты поменял тип, линтер скажет, где это сломалось
• Предотвращает гвозди наподобие any в критичных местах
• Работает с дженериками, conditional types, mapped types

Это особенно важно, если ты работаешь с большим кодбейсом. TypeScript ловит compile-time ошибки, линтер ловит runtime ошибки и код-смели - вместе они делают разработку предсказуемой.

ESM везде: модули как надо

Node.js 24 делает ESM полноценным гражданином платформы. Раньше CommonJS и ESM сосуществовали в напряженном мире: нужно было помнить о расширениях файлов, о полях в package.json, о совместимости либ.

Теперь достаточно добавить "type": "module" в package.json - и весь проект работает с ESM. Или используй расширение .mjs для явного обозначения.

Преимущества ESM в Node.js 24:

• Tree-shaking - bundler лучше понимает, что используется, убирает мёртвый код
• Статическая структура - импорты в топе файла, что проще для анализа и оптимизации
• Стандарт браузера - тот же синтаксис, что в браузере, меньше путаницы
• Асинхронная загрузка - модули грузятся параллельно, потенциально быстрее

Единое предупреждение: если ты используешь ESM с TypeScript и встроенной поддержкой Node.js, убедись, что в конфиге module: "nodenext" и rewriteRelativeImportExtensions: true. Это нужно, чтобы импорты содержали расширения файлов (.js вместо просто имени модуля).

На что обратить внимание при миграции

Обновление Node.js и ESLint - это не просто скачал новую версию и забыл. Есть нюансы, которые сломают сборку или CI/CD.

Сначала про Node.js 24 и TypeScript:

• Если в коде используются enum или декораторы - встроенная поддержка не поможет, нужен tsc
• Type-stripping работает только для erasable-синтаксиса - обычных типов и интерфейсов
• import.meta.dirname - новое API для получения текущей директории (аналог __dirname из CommonJS)
• Убедись, что tsconfig.json содержит правильные опции для type-stripping

Далее про ESLint 10:

• Старые .eslintrc.* файлы больше не работают - нужно переписать в eslint.config.js
• Требуется Node.js 20.19+ (версии ниже просто не запустятся)
• JSX-правила теперь более строгие - может появиться больше ошибок в коде с JSX
• Плагины (react, vue, angular и т.д.) должны быть обновлены до версий, которые поддерживают ESLint 10

Таблица совместимости основных либ:

Либа	Требуемая версия	Примечание
typescript-eslint	8.0+	Type-aware линтинг
eslint-plugin-react	7.32+	Поддержка flat config
eslint-plugin-next	15+	Для Next.js проектов
eslint-plugin-vue	9+	Для Vue проектов
Node.js	20.19+ или 24+	Обязательное требование

Что осталось за кадром

Эти три фичи - TypeScript в Node.js, ESLint 10 с плоским конфигом и полноценный ESM - это фундамент современной разработки на JavaScript. Они делают экосистему более когерентной и убирают боль-точки, которые раздражали лет пять.

Есть ещё мелочи: например, в ESLint 10.1.0 добавлена поддержка bulk suppressions через API (не только CLI), что полезно для IDE и LSP-сервисов. Или новые правила в typescript-eslint, которые ловят ещё более тонкие проблемы с типами. Но главное - стандартизация и упрощение. Та база, на которой разработчик теперь может строить без лишних конфигурационных танцев.