11–20 of 54 posts
Genuine question out of curiosity. Why do I want parallel and sequential when I can just write a simple bash script to accomplish the same thing? Is there some additional complexity I’m missing?
1. Minor speed boost from not needing bun multiple times (or extract the build/test/lint commands from package.json).
2. You can query/filter commands. E.g. run all my tests (both unit and integration).
3.You avoid needing a separate Bash install (for Windows).
Genuine question out of curiosity. Why do I want parallel and sequential when I can just write a simple bash script to accomplish the same thing? Is there some additional complexity I’m missing?
It lets developers on Windows also build and test your package in parallel mode. If you make your build scripts bash, they're Linux-only.
Git bash exists on windows and is perfectly usable.
Earlier quoted context omitted.
It lets developers on Windows also build and test your package in parallel mode. If you make your build scripts bash, they're Linux-only.
> if you make your build scripts bash, they’re Linux only Git bash exists on windows and is perfectly usable.
Genuine question out of curiosity. Why do I want parallel and sequential when I can just write a simple bash script to accomplish the same thing? Is there some additional complexity I’m missing?
At this point you don't need most things...
Genuine question out of curiosity. Why do I want parallel and sequential when I can just write a simple bash script to accomplish the same thing? Is there some additional complexity I’m missing?
Genuine question out of curiosity. Why do I want parallel and sequential when I can just write a simple bash script to accomplish the same thing? Is there some additional complexity I’m missing?
(trap 'kill 0' INT TERM; cmd1 & cmd2 & cmd3 & wait)
(trap 'kill 0' INT TERM;
(cmd1 && cmd2) &
(cmd3 && cmd4) &
wait
)
There are other reasons one might not want to depend on bash, but it's not something to be afraid of!
What you really want is a way for scripts to describe their dependencies, and then the runner figures out what order to run them in, and cache scripts that don't need to be run because their inputs didn't change.
Wireit[1] is an npm script runner that adds that incrementally on top of package.json. I can't manage an npm monorepo without it now.
Deno started integrating the idea directly into their built-in script runner. I think this is an important enough feature that more runtimes should follow Deno's lead.
Genuine question out of curiosity. Why do I want parallel and sequential when I can just write a simple bash script to accomplish the same thing? Is there some additional complexity I’m missing?
> when I can just write a simple bash script to accomplish the same thing At this point you don't need most things...
Parallel and sequential, especially at the command level, are really the wrong abstractions for running scripts. If you have multiple packages, each with builds, there's a high chance you have dependencies and multiple packages depending on common ones. What you really want is a way for scripts to describe their dependencies, and then the runner figures out what order to run them in, and cache scripts that don't need…
But now we would need each script to independently do their own caching, which isn’t all bad. At least you have more cross runner compatibility and resilience