Я понимаю ваше недоумение и не агитирую переписать все на bun shell :)
С оверхедом тут сложнее. Это стало частью Bun, соответственно если где-то вы начали использовать bun вместо node.js, то встроенный shell вы получаете автоматом.
Вы посмотрите во второй части статьи есть примеры, когда вывод из shell можно перенаправлять сразу в js-переменные. Это действительно более приятная интеграция, чем можно получить обычными путями.
Мне по прежнему в Gitlab CI будет хватать bash и может немного node.js, но иной раз начну думать, что есть и вот такие альтернативы.
Относительно rmSync Вы всё правильно говорите - такую строчку кода заменять на какой-то shell вообще смысла нет.
Но скрипты бывают сложнее (пример из статьи c ls *.js действительно более выразительный, чем readdir + filter и тд). И в этом случае смысла в таком шелл больше.
Опять таки, в коде приложения вряд ли каша-мала из shell + js уместна, но во всяких сопутствующих скриптах или CI/CD может быть крайне удобной и наглядной.
Можно отказаться от бинарника node, а запускать скрипты через bun index.js.
Можно отказаться от транспиляции через tsc / babel, в bun встроена поддержка и .ts, и .jsx
Можно отказаться он npm / yarn, а использовать bun как пакетный менеджер (интерфейс заимсвованный).
Можно запускать скрипты из package.json через bun run.
Все описанное выше НЕ предполагает отказ от webpack, TypeScript, jest и тд. Оно обещает бесплатно для вас все это ускорить.
А дальше наступает следующий как бы уровень, в котором можно начать использовать специфические штуки bun - сборщик (здесь они поддержали плагины esbuild), раннер тестов (здесь совместимы с jest) и встроенный http/https/websocket сервер уже непосредственно в коде приложения.
В этом и прикол, что никакие npm пакеты переписывать не нужно.
Bun внутри себя реализует почти полное стандартное Node.js API, а именно встроенные модули fs, path и тд. Соответсвенно Bun может запускать "любой" скрипт, который изначально был написан под Node.js. Поэтому jest и все последующие его обновления работают из коробки.
Это нужно потребителю ваших библиотек, чтобы у всех разработчиков локально и при сборке проекта для прода все зависимости были идентичными. Чтобы всякие неведомые баги не всплывали.
Lock-файлы позволяют контролировать установленные версии непрямых зависимости. И создатели пакетных менеджеров в других экосистемах отлично это знают и используют, например, в Python или Rust.
А вот для новеньких безнес-аккаунтов уже не бесплатно. От 159 рублей в месяц.
Я понимаю ваше недоумение и не агитирую переписать все на bun shell :)
С оверхедом тут сложнее. Это стало частью Bun, соответственно если где-то вы начали использовать bun вместо node.js, то встроенный shell вы получаете автоматом.
Вы посмотрите во второй части статьи есть примеры, когда вывод из shell можно перенаправлять сразу в js-переменные. Это действительно более приятная интеграция, чем можно получить обычными путями.
Мне по прежнему в Gitlab CI будет хватать bash и может немного node.js, но иной раз начну думать, что есть и вот такие альтернативы.
Относительно
rmSyncВы всё правильно говорите - такую строчку кода заменять на какой-то shell вообще смысла нет.Но скрипты бывают сложнее (пример из статьи c
ls *.jsдействительно более выразительный, чемreaddir + filterи тд). И в этом случае смысла в таком шелл больше.Опять таки, в коде приложения вряд ли каша-мала из shell + js уместна, но во всяких сопутствующих скриптах или CI/CD может быть крайне удобной и наглядной.
Спасибо, это действительно важный момент в контексте кроссплатформенного шелл.
Удалено
Спасибо, за подробную сводку. Даешь Tarantool vs Dragonfly!
А вот из свеженьких тулзов очень напоминает https://orm.drizzle.team/. Очень интересно послушать мнение тех, кто успел попробовать вот это все.
У меня разница небольшая, но все-таки есть)
Круто было бы с
jestпересесть наbun test, но сетап сложноват у нас, чтобы оно сразу завелось.Что-то у вас вообще мощное)
У меня через brew без проблем встало.
Там все-таки 2 команды:
Что же у вас там такое под капотом? Есть какая-то экзотика?
Кажется, что если его реально начнут использовать хотя бы как более быстрый пакетный менеджер и, например, тест-раннер, то Bun уже закрепится надолго.
Ну давайте по пунктам)
Можно отказаться от бинарника node, а запускать скрипты через bun index.js.
Можно отказаться от транспиляции через tsc / babel, в bun встроена поддержка и .ts, и .jsx
Можно отказаться он npm / yarn, а использовать bun как пакетный менеджер (интерфейс заимсвованный).
Можно запускать скрипты из package.json через bun run.
Все описанное выше НЕ предполагает отказ от webpack, TypeScript, jest и тд. Оно обещает бесплатно для вас все это ускорить.
А дальше наступает следующий как бы уровень, в котором можно начать использовать специфические штуки bun - сборщик (здесь они поддержали плагины esbuild), раннер тестов (здесь совместимы с jest) и встроенный http/https/websocket сервер уже непосредственно в коде приложения.
Как-то так стало понятнее?
В этом и прикол, что никакие npm пакеты переписывать не нужно.
Bun внутри себя реализует почти полное стандартное Node.js API, а именно встроенные модули fs, path и тд. Соответсвенно Bun может запускать "любой" скрипт, который изначально был написан под Node.js. Поэтому jest и все последующие его обновления работают из коробки.
Имеется ввиду, что в питоне хоть и динамическая, но строгая типизация. Сложить строку с числом не получится и все в таком роде.
Это нужно потребителю ваших библиотек, чтобы у всех разработчиков локально и при сборке проекта для прода все зависимости были идентичными. Чтобы всякие неведомые баги не всплывали.
Lock-файлы позволяют контролировать установленные версии непрямых зависимости. И создатели пакетных менеджеров в других экосистемах отлично это знают и используют, например, в Python или Rust.
Спасибо, важный момент.
Мне кажется, тут зрелость самой node.js играет на руку. Поломки обратной совместимости во встроенных модулях - большая редкость.
У меня скрипты из package.json действительно немного быстрее работают. Установка зависимостей вроде ощутимо быстрее.
Тут легко проверить, с очень высокой вероятностью все просто запустится через bun run.