Комментарии 10
Нужно добавить оговорку, что bun для windows все ещё не зарелижен (но можно скачать nightly-сборку).
Удалено
Эмн, вместо
fs.rmSync(dir, { recursive: true, force: true });
Теперь нужно цеплять специальную библиотеку для выполнения того же самого?
Относительно rmSync
Вы всё правильно говорите - такую строчку кода заменять на какой-то shell вообще смысла нет.
Но скрипты бывают сложнее (пример из статьи c ls *.js
действительно более выразительный, чем readdir + filter
и тд). И в этом случае смысла в таком шелл больше.
Опять таки, в коде приложения вряд ли каша-мала из shell + js уместна, но во всяких сопутствующих скриптах или CI/CD может быть крайне удобной и наглядной.
Ну, пихать в js операции которые делаются на шелле -- зачем?
Хочется краткости и выразительности -- пиши на баше, хочется гибкости и "интеграции" в проект -- пиши на js. Не хватает отсутствующих cli утилит -- пиши на powershell (хотя, вообще надуманная проблема, учитывая повсеместное наличие wsl). Но цеплять зависимость на несколько десятков мегабайт чтобы не использовать node:child_process это как минимум оверхед какой-то :)
Ну и да, в скриптах для CI/CD спокойно можно всё описать на том же чистом bash/js/groovy/вставить подходящее. Да и во всяких различных пайплайн системах экшны по дефолту умеют sh-команды, и, мне кажется, что запускаются они далеко не все на win, а для win есть bat/ps =)
Я понимаю ваше недоумение и не агитирую переписать все на bun shell :)
С оверхедом тут сложнее. Это стало частью Bun, соответственно если где-то вы начали использовать bun вместо node.js, то встроенный shell вы получаете автоматом.
Вы посмотрите во второй части статьи есть примеры, когда вывод из shell можно перенаправлять сразу в js-переменные. Это действительно более приятная интеграция, чем можно получить обычными путями.
Мне по прежнему в Gitlab CI будет хватать bash и может немного node.js, но иной раз начну думать, что есть и вот такие альтернативы.
Если вы не понимаете зачем - вам и не надо.
В свое время, появление zx
серьезно облегчило мне жизнь. Многие задачи теперь занимают в разы меньше времени, чем когда приходилось связывать вызов cli и модули на js шелл скриптами. Кодовая база проектов похудела на многие сотни строк. Одна строчка await $..
вместо реализацией того же каждый раз через child_process
в десятки строк кода уж подключения такой зависимости явно стоит.
Ну а про powershell и wsl - это, надеюсь, шутка такая была?
Ну, во первых, wsl и ps было в разных абзацах, но в целом да, относится к "кроссплатформенности".
А ещё, подскажите где тут десятки строк кода?
execSync('ls -lha | grep proj').toString()
Или же у нас какой-то разный nodejs используется?
А вам как часто нужно сделать из nodejs подобное и именно таким образом? Мне - уж точно не часто, задачи чуть менее, чем всегда, куда сложнее.
Постоянно нужно запустить пачку задач параллельно и дожидаться их выполнения. Синхронные версии методов уже не подходят, нужны асинхронные, при том возвращающие обещания - нужны async
/ await
, комбинаторы и т.п. Нужно передать в cli какие-то параметры, при том экранированные, дабы ничего не сломать. Отображать вывод по мере поступления или наоборот его скрывать. Да много чего ещё.
Все можно сделать с помощью child_process
- вот только в инструментах вроде zx
так оно и сделано. Зачем самому писать обертку-велосипед, если она уже написана и дает какой-никакой стандарт?
Релиз Bun Shell (новый shell для JavaScript)