As a note here, there are a lot of resources that make bash seem incredibly arcane, with custom functions often recommended. But a simple interruptible script to run things in parallel can be as simple as:

    (trap 'kill 0' INT TERM; cmd1 & cmd2 & cmd3 & wait)

Or, for 1+2 sequentially, in parallel with 3+4 sequentially:

    (trap 'kill 0' INT TERM;
      (cmd1 && cmd2) &
      (cmd3 && cmd4) &
      wait
    )

(To oversimplify: The trap propagates the signal (with 'kill') to the process group 0 made by the () parens; this only needs to be set at the top level. & means run in background, && means run and continue only on success.)

There are other reasons one might not want to depend on bash, but it's not something to be afraid of!

I get where you're coming from and if this was a package I'd agree - but having this built in/part of the tooling is nice - one less dependency - bash isn't as ubiquitous as you assume.

This is cleaner and you don't have to write a bash script. It's one (well, several: the script, bash, and it's dependencies) less thing, which is important in containers and for scale.

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.

> when I can just write a simple bash script to accomplish the same thing

At this point you don't need most things...

A few reasons.

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).