Node.js запускает TypeScript нативно: как это меняет привычный dev workflow

У JavaScript-инструментов есть редкая категория изменений, которые на бумаге выглядят почти скромно, а в реальной разработке оказываются культурным сдвигом. Нативный запуск TypeScript в Node.js — именно такой случай. Формально речь не о том, что Node внезапно превратился в полноценный компилятор TypeScript со всеми возможностями tsc. Речь о другом: начиная с Node.js 23.6.0 встроенный механизм type stripping включен по умолчанию, и файлы .ts можно запускать напрямую через node file.ts без дополнительного раннера. Это не “полная поддержка TypeScript”, а легковесный режим удаления типов, но даже в таком виде изменение уже заметно меняет привычный developer workflow.

Почему это так важно? Потому что долгие годы у Node-разработчика была почти автоматическая связка в голове: если код на TypeScript, значит между исходником и запуском обязательно стоит еще один инструмент — tsc, tsx, ts-node, build step, dev runner или хотя бы слой transpilation в тестовой среде. Теперь эта связка начинает распадаться. Не полностью, не для всех случаев, не без ограничений. Но сам факт уже изменился: для заметного класса задач Node умеет исполнять TypeScript напрямую, просто стирая типы и оставляя остальной JavaScript как есть. А это сразу бьет по самому сердцу повседневной рутины: скрипты, CLI, миграции, build utilities, one-off tools, локальные dev entry points и часть backend-кода можно запускать проще, чем раньше.

При этом очень важно не перепутать “проще” с “магически все решено”. Node не начинает читать tsconfig.json, не превращается в замену полноценной TypeScript-сборки, не берет на себя type checking и не поддерживает весь TS-синтаксис, который требует генерации JavaScript. Встроенный режим специально сделан легковесным: Node удаляет только стираемые конструкции, не делает типовую проверку и не поддерживает возможности, завязанные на трансформацию кода, вроде enum, parameter properties или paths из tsconfig. Это не новая вселенная, а очень прагматичный сдвиг в том, где теперь проходит граница между “нужен отдельный toolchain” и “достаточно самого Node”.

И именно поэтому тема так интересна в апреле 2025 года. Она не про то, что TypeScript suddenly победил и стал “родным языком Node” во всех смыслах. Она про то, что привычный workflow вокруг TypeScript начинает упрощаться в тех местах, где раньше toolchain был тяжелее самой задачи. А такие упрощения меняют поведение команд сильнее, чем многие громкие языковые фичи.

Главное, что нужно понять сразу: Node не “поддерживает весь TypeScript”

Самая вредная реакция на новость — услышать “Node запускает TypeScript нативно” и мысленно превратить это в “больше не нужны ни tsc, ни отдельный runtime, ни понимание границ между TS и JS”. Это было бы слишком удобно, чтобы быть правдой. Официальная документация Node довольно прямолинейна: встроенная поддержка — это lightweight type stripping. Node удаляет inline-типы, не делает type checking и не читает tsconfig.json. А значит, любые возможности, завязанные на настройку компиляции, преобразование синтаксиса или подстановку путей, в этот режим не входят.

Более того, список ограничений довольно важен для реальной архитектуры. Node прямо пишет, что синтаксис, который требует генерации JavaScript, не будет работать без отдельного флага --experimental-transform-types. В официальной документации в числе самых заметных примеров перечислены enum, namespace с runtime-кодом, parameter properties и import aliases. Также Node не поддерживает .tsx, требует явные расширения в импортах и отказывается обрабатывать TypeScript внутри node_modules. Даже decorators сейчас не трансформируются и приведут к parser error, пока сами не будут поддержаны нативно в JavaScript.

Это важно не как список “нельзя”, а как новый инженерный фильтр. Нативный запуск TS в Node — не замена всей TypeScript-экосистемы, а новый базовый режим для эрозируемого синтаксиса. И чем раньше команда это принимает, тем меньше потом будет ложных ожиданий. Это не про “все проекты теперь можно запускать голым Node”. Это про “теперь у Node появился честный lightweight режим для заметного класса сценариев”.

Почему это особенно сильно меняет скрипты и служебный код

Если искать место, где нововведение меняет workflow почти мгновенно, это всевозможные служебные скрипты. Build scripts, миграции, генераторы, codemods, локальные утилиты, dev-only CLI, release automation, data fix scripts — весь этот слой исторически очень часто жил в TypeScript, но почти всегда требовал отдельного запуска через tsx, ts-node или промежуточную сборку. Для таких задач фулл-компиляторный цикл часто казался избыточным, но без него жить было неудобно. Теперь для многих из них достаточно просто написать node script.ts, если код укладывается в ограничения type stripping.

Это очень практический сдвиг. Потому что служебный код в командах обычно не страдает от недостатка типовой дисциплины, а страдает от трения запуска. Чем тяжелее исполнение такого кода, тем чаще люди либо пишут его на голом JavaScript “ради скорости”, либо тащат в проект еще один runner, либо вообще откладывают автоматизацию. Когда Node сам умеет запускать TypeScript-скрипт без дополнительной прослойки, барьер заметно падает. И это как раз тот случай, когда изменение влияет не на идеальную архитектуру, а на повседневные привычки команды.

Особенно это чувствуется в монорепах и инфраструктурных репозиториях, где вокруг основного приложения живет большое количество маленьких TS-утилит. Раньше каждая такая штука как будто требовала оправдания: еще один runner, еще одна конфигурация, еще одна зависимость. Теперь часть этих решений можно сделать почти “как обычный Node-скрипт”, только с типами в исходнике. Это незаметно, но очень сильно меняет культуру мелкой автоматизации.

Сборка и запуск наконец начинают расходиться честнее

Одна из самых интересных долгосрочных последствий — изменение отношения к самому слову “сборка”. В TypeScript-мире слишком долго смешивались две задачи: “мне нужно выполнить этот код” и “мне нужно качественно скомпилировать, проверить и подготовить этот код”. На практике это не всегда одно и то же. Когда вы запускаете локальный скрипт для миграции, генерации файлов или одноразовой админской операции, вам часто не нужен полный build pipeline. Вам нужно просто выполнить TS-исходник как можно ближе к его естественной форме. Нативный запуск в Node как раз разводит эти режимы честнее.

Это не делает сборку менее важной. Наоборот, она становится понятнее по роли. Полный tsc или другой build step нужен там, где вы действительно хотите type checking, declaration emit, совместимость с tsconfig-настройками, трансформацию синтаксиса, package output и контроль production-артефактов. А вот простой запуск lightweight-TS-сценария перестает автоматически требовать участия всего этого механизма. Такой разрыв очень полезен для DX: меньше ложной тяжести там, где она не нужна, и более ясная ценность сборки там, где она действительно обязательна.

И в этом смысле Node меняет не только технику запуска, но и мышление. TypeScript-код больше не обязан восприниматься как нечто, что всегда сначала нужно “протащить через сложный ритуал”, прежде чем можно будет просто выполнить. Для части сценариев он становится ближе к обычному исполняемому исходнику. Это очень сильное культурное изменение.

Но tsconfig.json никуда не делся — просто его роль меняется

Встроенная поддержка Node нарочно не читает tsconfig.json. Документация говорит об этом без двусмысленности: возможности, которые зависят от tsconfig, такие как paths или преобразование нового синтаксиса в старые стандарты, в lightweight-режим не входят. Это означает, что tsconfig.json не исчезает, а просто перестает быть обязательным участником каждого запуска.

Для workflow это очень важное различие. Раньше tsconfig часто воспринимался как почти центральный дирижер любой жизни TypeScript-кода. Теперь для части сценариев он скорее превращается в инструмент quality gate и build-time дисциплины, а не в обязательную runtime-прослойку. Это освобождает простые dev-задачи, но одновременно требует большей аккуратности: команда должна понимать, какой режим она использует. Если код опирается на paths, decorators, старые безрасширительные импорты или другой синтаксис, требующий участия компилятора, “голый Node” уже не подойдет.

Именно поэтому новая реальность не отменяет проектную дисциплину, а делает ее более явной. Появляется новый вопрос: этот кусок TypeScript-кода мы хотим писать как erasable TS, который может жить почти как исполняемый исходник, или как полноценный TS-проект, которому нужен весь build-time контур? От ответа зависит и выбор синтаксиса, и настройка tooling, и ожидания команды.

TypeScript 5.8 неожиданно становится ближе к Node, чем раньше

На этом фоне особенно показательно, что TypeScript 5.8 вводит флаг --erasableSyntaxOnly. Официальный блог TypeScript объясняет его очень прямо: этот режим разрешает только конструкции, которые можно просто стереть из файла, и выдает ошибку на синтаксис, требующий реального JavaScript-преобразования. В качестве примера блог приводит parameter properties как неподходящий синтаксис в таком режиме. Это очень явный знак того, что экосистема уже реагирует на новый Node-сценарий и начинает подстраивать сам TypeScript под реальность lightweight type stripping.

В документации Node эта связка тоже отражена. Node прямо рекомендует использовать TypeScript 5.8 или новее вместе с набором настроек вроде module: "nodenext", rewriteRelativeImportExtensions, erasableSyntaxOnly и verbatimModuleSyntax. Это очень важная практическая деталь: “нативный TypeScript в Node” оказывается не изолированной фичей Node, а началом новой договоренности между Node и самим TypeScript как инструментом.

И вот это уже по-настоящему влияет на workflow. У команды появляется шанс не просто “запускать .ts напрямую”, а выстроить вокруг этого новый, более тонкий режим работы: писать часть кода сразу в erasable-style, ловить несовместимые конструкции на этапе type checking и заранее понимать, что такой код будет честно исполняться в Node без отдельного transpiler-слоя. Это заметно взрослее, чем просто новый флаг на рантайме.

Импорты и расширения внезапно становятся важнее, чем раньше

Еще один практический эффект, который многие почувствуют довольно быстро, — усиление дисциплины вокруг импортов. Встроенный режим Node требует явных расширений в импортируемых путях, как и обычные JavaScript-модули. Документация отдельно подчеркивает: писать нужно import './file.ts', а не import './file'. То же касается и CommonJS-режима с require(). Плюс для type-only импортов нужен именно import type, иначе Node воспримет импорт как value import и это закончится runtime-ошибкой.

С точки зрения DX это, возможно, сначала раздражает. Многие проекты и команды привыкли жить в более “мягком” мире, где bundler, tsconfig или transpiler сглаживали такие детали. Но на длинной дистанции это делает среду честнее. Код, который выполняется Node напрямую, начинает больше походить на настоящий runtime-контракт, а не на соглашение “сборщик потом догадается, что мы имели в виду”. Для части команд это будет неприятным культурным сдвигом. Для других — полезной нормализацией.

Особенно важно это в mixed projects, где одна часть кода живет как runtime TypeScript под Node, а другая все еще проходит через bundler или отдельную сборку. Там внезапно становится очень заметно, где у вас импортная дисциплина реальная, а где держалась на доброй воле toolchain.

Часть старых dev-зависимостей теперь выглядит менее обязательной

Нативный запуск TypeScript не означает, что tsx, ts-node и похожие инструменты внезапно стали ненужными. Официальная документация Node прямо говорит: если вам нужна полная поддержка всех возможностей TypeScript, включая использование любой версии TS и уважение к tsconfig, используйте сторонний пакет; в документации в качестве примера приводится tsx.

Но сама логика выбора теперь меняется. Раньше такие инструменты выглядели почти обязательной базой для любого TypeScript-рантайма в Node. Теперь они все чаще становятся инструментами “для полного режима”, а не просто для базового факта исполнения TS-файла. Это довольно сильный сдвиг в ощущении стека. Если проекту не нужны трансформации, tsconfig-paths и другой расширенный функционал, отдельный раннер уже не всегда нужен. Его использование должно быть оправдано конкретной потребностью, а не просто исторической привычкой.

На уровне практики это означает, что часть package.json-скриптов станет проще, часть инфраструктурных утилит исчезнет, а некоторые проекты смогут сократить набор dev-зависимостей. Не потому, что экосистема резко обеднела, а потому что базовый runtime-сценарий стал шире, чем раньше.

Где это особенно полезно уже сейчас

Если приземлить разговор до конкретики, то strongest impact сейчас виден в нескольких категориях задач. Во-первых, это локальные скрипты и automation tooling — то, о чем уже говорилось выше. Во-вторых, это backend utility layer: миграции, сиды, административные команды, build-time генераторы, простые internal CLIs. В-третьих, это репозитории, где TypeScript используется не только для production-кода, но и как язык инфраструктуры разработки. Для таких проектов возможность писать utility-code в TS и исполнять его сразу через Node снижает friction почти немедленно.

Кроме того, изменение хорошо ложится на monorepo-сценарии. В больших репозиториях обычно живет много мелких TS-entrypoints, которые не хочется каждый раз тащить через один и тот же heavyweight runner. Когда сам Node умеет выполнять хотя бы легковесный подмножество TS, внутренняя автоматизация становится менее ceremony-driven. А это, как ни странно, часто важнее самых красивых архитектурных улучшений. Маленькие скрипты начинают появляться охотнее, потому что их запуск перестает быть отдельной инженерной историей.

Но production workflow все равно не становится “без сборки вообще”

Здесь стоит быть особенно честным. Новость очень легко романтизировать до тезиса “TypeScript-компиляция больше не нужна”. Для production-систем это почти никогда не так. Node сам подчеркивает: встроенный режим не делает type checking, не читает tsconfig, не поддерживает path aliases, не трансформирует features, требующие code generation, и не предназначен для TypeScript-кода внутри зависимостей в node_modules. Если вы публикуете JavaScript-артефакты, собираете библиотеку, ориентируетесь на declaration files или используете богатый TS-синтаксис, обычная сборка никуда не исчезает.

То есть новая реальность не в том, что build pipeline отменяется, а в том, что он перестает быть обязательным участником вообще любого TS-сценария. Это очень важное различие. Для production workflow чаще меняется не сам факт сборки, а то, где именно вы решаете ее включать. Отдельные скрипты, dev-only entrypoints и часть служебного кода могут уйти из “обязательного transpile before run”, в то время как основное приложение по-прежнему проходит через полноценный контроль качества и сборки.

По сути Node помогает командам честнее развести runtime convenience и production correctness. И это, пожалуй, самое здоровое изменение во всей истории.

Итог

Нативный запуск TypeScript в Node.js меняет dev workflow не потому, что внезапно делает весь TypeScript “просто JavaScript с типами”, а потому что убирает лишнюю тяжесть из тех мест, где раньше toolchain был больше самой задачи. После Node.js 23.6.0 built-in type stripping включен по умолчанию в Current-линии, и для заметного класса сценариев можно запускать .ts напрямую. Но это lightweight-режим: без type checking, без чтения tsconfig.json, без поддержки синтаксиса, который требует преобразования, и с довольно строгой дисциплиной вокруг импортов и расширений.

Именно поэтому сильнее всего меняется не production build как таковой, а повседневная рутина вокруг скриптов, служебного кода, внутренних CLI и мелких TS-entrypoints. Сборка и запуск начинают расходиться честнее: не каждый исполняемый TypeScript-файл обязан проходить через большой компиляторный ритуал, но там, где нужны полная типовая дисциплина, tsconfig-зависимые возможности и publishable артефакты, полноценный build pipeline все равно остается на месте. Дополнительный слой зрелости здесь добавляет и TypeScript 5.8 с --erasableSyntaxOnly, который делает такой Node-friendly стиль кода явной, проверяемой стратегией.

Если сформулировать главный практический вывод совсем прямо, он будет таким: Node.js не отменяет TypeScript-toolchain, но впервые делает возможным очень важный новый режим — писать часть TS-кода как почти исполняемый исходник, а не как обязательную заготовку под будущую компиляцию. И вот это уже действительно меняет привычный workflow. Не громко, не революционно на слайде, но очень заметно в ежедневной жизни команды.