Но скрипты бывают сложнее (пример из статьи c ls *.js действительно более выразительный, чем readdir + filter и тд). И в этом случае смысла в таком шелл больше.

Опять таки, в коде приложения вряд ли каша-мала из shell + js уместна, но во всяких сопутствующих скриптах или CI/CD может быть крайне удобной и наглядной.

POPSuL Feb 27 at 12:35

Ну, пихать в js операции которые делаются на шелле -- зачем?

Хочется краткости и выразительности -- пиши на баше, хочется гибкости и "интеграции" в проект -- пиши на js. Не хватает отсутствующих cli утилит -- пиши на powershell (хотя, вообще надуманная проблема, учитывая повсеместное наличие wsl). Но цеплять зависимость на несколько десятков мегабайт чтобы не использовать node:child_process это как минимум оверхед какой-то :)

Ну и да, в скриптах для CI/CD спокойно можно всё описать на том же чистом bash/js/groovy/вставить подходящее. Да и во всяких различных пайплайн системах экшны по дефолту умеют sh-команды, и, мне кажется, что запускаются они далеко не все на win, а для win есть bat/ps =)

arusakov Feb 27 at 12:47

Я понимаю ваше недоумение и не агитирую переписать все на bun shell :)

С оверхедом тут сложнее. Это стало частью Bun, соответственно если где-то вы начали использовать bun вместо node.js, то встроенный shell вы получаете автоматом.

Вы посмотрите во второй части статьи есть примеры, когда вывод из shell можно перенаправлять сразу в js-переменные. Это действительно более приятная интеграция, чем можно получить обычными путями.

Мне по прежнему в Gitlab CI будет хватать bash и может немного node.js, но иной раз начну думать, что есть и вот такие альтернативы.

rock Feb 27 at 16:33

Если вы не понимаете зачем - вам и не надо.

В свое время, появление zx серьезно облегчило мне жизнь. Многие задачи теперь занимают в разы меньше времени, чем когда приходилось связывать вызов cli и модули на js шелл скриптами. Кодовая база проектов похудела на многие сотни строк. Одна строчка await $.. вместо реализацией того же каждый раз через child_process в десятки строк кода уж подключения такой зависимости явно стоит.

Ну а про powershell и wsl - это, надеюсь, шутка такая была?

POPSuL Feb 27 at 19:35

Ну, во первых, wsl и ps было в разных абзацах, но в целом да, относится к "кроссплатформенности".

А ещё, подскажите где тут десятки строк кода?

execSync('ls -lha | grep proj').toString()

Или же у нас какой-то разный nodejs используется?

rock Feb 27 at 20:04

А вам как часто нужно сделать из nodejs подобное и именно таким образом? Мне - уж точно не часто, задачи чуть менее, чем всегда, куда сложнее.

Постоянно нужно запустить пачку задач параллельно и дожидаться их выполнения. Синхронные версии методов уже не подходят, нужны асинхронные, при том возвращающие обещания - нужны async / await, комбинаторы и т.п. Нужно передать в cli какие-то параметры, при том экранированные, дабы ничего не сломать. Отображать вывод по мере поступления или наоборот его скрывать. Да много чего ещё.

Все можно сделать с помощью child_process - вот только в инструментах вроде zx так оно и сделано. Зачем самому писать обертку-велосипед, если она уже написана и дает какой-никакой стандарт?

Show the best of all time