Maintained successor: npm-run-all-next (retries, balancer, summary table, etc.)

[alecmestroni]

Hi everyone,

First of all: huge thanks for npm-run-all. This tool has been essential to a ton of build/test/watch workflows across JS projects for years.

Because npm-run-all hasn’t shipped a new release in years, I’ve been maintaining and publishing an actively updated continuation called npm-run-all-next. The goal is: same mental model, same CLI ergonomics, modern behavior.

I’m opening this issue just to share it with people who still depend on npm-run-all today.

Compatibility / Migration

# install
npm install --save-dev npm-run-all-next
# or
yarn add --dev npm-run-all-next

All the executables are there under node_modules/.bin:

• npm-run-all
• run-s (sequential, same semantics as before)
• run-p (parallel, same semantics as before)

What’s new / why “next”

npm-run-all-next keeps the core features from npm-run-all on top of that, npm-run-all-next adds functionality that’s aimed at CI stability and developer feedback:

1. Automatic retries for flaky steps
   --retries <n> will rerun a task up to N times if it fails, instead of immediately marking the whole run red. This is super helpful for tests/integration steps that are mostly stable but sometimes fail due to timing or network.

2. Smarter parallel scheduling / balancer
   -b, --balancer uses historical run times to balance work across workers instead of just blasting everything at once. This helps avoid all the “slow” tasks piling up on the same worker while other workers sit idle.

3. Configurable concurrency with modern naming
   -j, --jobs <n> limits how many tasks run in parallel at once.
   (npm-run-all had --max-parallel; npm-run-all-next exposes this as --jobs/-j, which is a familiar convention in a lot of build tools.)

4. Explicit failure/teardown behavior
   -k, --kill-others-on-fail lets you opt into “if one task dies, kill the rest immediately.”
   In the original tool, killing siblings on first failure in parallel mode was basically the default. In npm-run-all-next this behavior is controllable — nicer for long-running watch/dev setups where you want other tasks to keep going.

5. End-of-run summary table for CI logs
   -t, --print-summary-table prints a compact table at the end with each task, exit status, and runtime. That makes it way easier to skim a CI log and see what actually failed instead of scrolling through 500 lines of mixed output.

6. Taskfile support (optional)
   In addition to reading scripts from "scripts" in package.json, you can also point the CLI at an external task file and treat that as your script catalog.
   This means you can keep complex build/test/watch command graphs in a dedicated taskfile instead of stuffing everything into package.json, and still run them via the same interface (npm-run-all-next, run-s, run-p) both locally and in CI.

7. Ongoing maintenance / modern Node support
   npm-run-all-next targets current Node versions (Node 12+ and up) instead of legacy Node 4-era assumptions, updates the internal deps (chalk, cross-spawn, pidtree/tree-kill, etc.), and continues to publish new releases.
   In practice, that means fewer “this flag crashes on recent Node” surprises and fewer outdated transitive deps in your audit/supply-chain dashboards.

8. Quality-of-life for humans reading logs

   • --print-summary-table at the end, instead of having to scroll back up.
   • --aggregate-output still available, but now paired with better labeling and summary so parallel runs are actually readable.
   • Balancer + --jobs makes the output less chaotic because it reduces extreme overlap between very noisy long-running tasks.

Why am I posting this here?

A lot of repos still depend on npm-run-all because it solved a real problem that neither plain npm run nor most OS shells solve cleanly in a cross-platform way (especially on Windows). I don’t want teams to feel “stuck on an unmaintained CLI from years ago” just to keep their run-s / run-p workflows.

If npm-run-all is effectively frozen, npm-run-all-next is meant to be the maintained continuation: same mental model, safer defaults, extra capabilities for modern CI and monorepo-style builds.

If this is useful to other users of npm-run-all, feel free to try it, open issues, or suggest improvements.