Комментарии 11
Т.е. оно просто из TS кода вырезает все части отвечающие собственно за типы давая на выходе JS код, я правильно понял? А для чего всё это?
Нет никакого "на выходе", оно буквально запускает ts как js без необходимости транспиляции (что предварительной, что рантайм).
Звучит странно. Мы писали-писали, выводили типы, классы, дженерики и прочие юнионы, а теперь давайте без всей этой фигни попробуем взлететь! запустим это как обычный JS. Разве что для тестирования какого, иначе я не могу представить зачем то что подразумевается запускать как результат трансляции запускать без неё.
Так пишите на здоровье. Типы, дженерики и прочие юнионы всё равно отсутствуют в рантайме, они статически проверяются. Если вам всё ещё нужно их проверять — tsc умеет их проверять без эмита файлов. А классы остаются классами что в ts, что в js.
Если раньше для проверки типов вы физически транспилировали файлы ts->js, то теперь можно делать это ещё быстрее, без эмита файлов, с флагом --noEmit. Вин.
Если раньше для запуска вам нужен был этап транспиляции, то теперь он вам будет не нужен, приложение можно запускать быстрее и без лишней папки. Вин.
Если раньше для запуска ts-кода вы использовали сторонние пакеты tsx или ts-node, то теперь можно делать это из коробки, без лишних инструментов, и быстрее. Вин.
запустим это как обычный JS
Сказано же, что для того, чтобы от source maps избавиться. Скорее не для тестирования, а для продакшена. Для тестирования вам как раз неплохо бы иметь source map на реальные исходники. А в продакшене уже не так важно и если есть возможность пару килобайт на страничке сэкономить, то уже неплохо. Разумеется это для сборке фронтэнда. Для серверных приложений неактуально
Оно не стирает указания типов, а забивает их пробелами. Поэтому, наоборот: размер исходника не меняется (следовательно экономии нет), все значимые вещи остаются в точности на своих местах (следовательно source maps не нужны), и все это нужно сугубо для удобства быстрого запуска локально. Для сборки на прод по-прежнему нужен полноценный TS с проверками, минификатор и т.д.
В новости речь о node. То есть о бекэнде. На бекэнде минимизация не нужна, так как код не грузится по сети, а с диска, да и то один раз при запуске приложения. Так что теперь можно деплоить ts код в прод.
Но вот прогон тайпчекером в каком нибудь CI/CD всё равно нужен.
Можно провести аналогию с Python, где аннотации типов ни на что не влияют в рантайме, но IDE и специальные утилиты способны их проверять. Первые повышают удобство разработчика, вторые гоняют в CI/CD для недопущения мерджа/деплоя кода с ошибками типов.
вообще после таких новостей невольно задаешься вопросом - почему nodejs до сих пор самый популярный рантайм JS, если например bun уже как полгода точно стабилен и на винде и на линуксе, и перфоманс у него лучше, и апишка, да и все либы популярные поддерживает
Никто текущий продакшен переписывать на bun не будет, bun все еще молодой, никто не будет брать на себя риски и делать крупные проект на bun.
К тому же, он очень быстрый и классный исключительной на голых и сухих тестах, нету нормального тестирования с большим приложением.
У Виктора Хомякова на HollyJS есть классный доклад с разбором Bun vs Node, очень советую глянуть.
Реальный прирост производительности в условные 10% не стоит ни каких рисков, проще еще поднять машинку с nodejs. Nodejs сам по себе просто возьмет все лучшее у других рантаймов и добавит фичи к себе, как это например случилось с ts.
И не-перформанс фичи и у Bun и у Deno все еще сильно нишевые; и потому не несут достаточной для перехода на них ценности для среднего проекта (типа другой движек, области безопасности, нативная линковка, ...).
И согласен с вами - как только будет фича стоящая перехода - сразу Node будет делать ее тоже. Bun/Deno для Node выходят как бы разведчиками "куда идти".
Функция Type Stripping в Node.js теперь доступна по умолчанию