Parallel and Series makes sense to me; it's also the terminology used for electrical circuits.

When talking in terms of software parallelism, "parallel" and "sequential" are more common to describe, for example, multi-threaded vs. single-threaded implementations.

Both would be understood and are roughly interchangeable.

"Sequential" feels more appropriate to me for the task runner scenario where we wait for one task to finish before running the next.

"Series" suggests a kind of concurrency to me because of the electrical circuit context, where the outputs of one are flowing into the next, but both are running concurrently. Processes that are Unix piped into each other would be another thing that feels more like a "series" than a "sequence".

I think your average person knows what sequential means but might not remember what series means. Personally I always remember the meaning of series in “parallel vs series” because it must be the opposite of parallel. I’m not proud of the fact that I always forget and have to re-intuit the meaning every time, but the only time I ever see “series” is when people are talking about a TV show or electronics.

Electric engineering talks about parallel and series. (including the old parallel and serial ports on computers, before almost everything became serial)

Programming talks about parallelism or concurrency or threading. (single-threading, multi-threading)

Or synchronous and asynchronous.

The legal system talks about concurrent and consecutive.

Process descriptions might use "sequential" rather than consecutive or series.

"Linear" is another possibility, but it's overloaded since it's often used in reference to mathematics.

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.

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

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

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

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.

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!

If only we could make something like that

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