concurrently vs npm-run-all vs npm-run vs parallelshell
NPM Script Management Tools
concurrentlynpm-run-allnpm-runparallelshellSimilar Packages:

NPM Script Management Tools

NPM script management tools are utilities that help developers run multiple npm scripts concurrently or sequentially. These tools are particularly useful in complex projects where tasks like building, testing, and deploying need to be automated efficiently. They provide features like running scripts in parallel, handling dependencies between tasks, and improving the overall workflow in a development environment. These tools help streamline the execution of multiple scripts, making the development process more efficient and organized. concurrently is a tool that allows you to run multiple commands concurrently, displaying their output in a single terminal. It is simple to use and is ideal for running tasks like starting a server and a client simultaneously. npm-run is a lightweight utility for running npm scripts programmatically. It is useful for automating tasks within Node.js applications but does not provide features for running multiple scripts concurrently. npm-run-all is a CLI tool that allows you to run multiple npm scripts sequentially or concurrently. It provides more control over the execution order of scripts and is useful for complex workflows that require running tasks in a specific sequence or in parallel. parallelshell is a tool for running multiple shell commands in parallel. It is similar to concurrently but focuses on running shell commands rather than npm scripts. It is useful for tasks that require running multiple commands simultaneously, such as building multiple projects or running tests in parallel.

Npm Package Weekly Downloads Trend

3 Years

Github Stars Ranking

Stat Detail

Package
Downloads
Stars
Size
Issues
Publish
License
concurrently11,612,2497,703422 kB657 months agoMIT
npm-run-all3,531,2075,843-1137 years agoMIT
npm-run105,904187-78 years agoMIT
parallelshell8,810499-208 years agoMIT

Feature Comparison: concurrently vs npm-run-all vs npm-run vs parallelshell

Concurrency

  • concurrently:

    concurrently allows you to run multiple commands or scripts at the same time, displaying their output in a single terminal. It is designed specifically for running tasks concurrently and provides features like color-coded output to distinguish between commands.

  • npm-run-all:

    npm-run-all supports running multiple npm scripts either sequentially or concurrently. It provides more flexibility in how scripts are executed, allowing you to choose the mode that best fits your workflow.

  • npm-run:

    npm-run does not support running multiple scripts concurrently. It is designed for running a single npm script programmatically.

  • parallelshell:

    parallelshell allows you to run multiple shell commands in parallel. It is similar to concurrently but focuses on shell commands rather than npm scripts.

Script Management

  • concurrently:

    concurrently is focused on running multiple commands or scripts concurrently but does not provide features for managing the execution order or dependencies between scripts.

  • npm-run-all:

    npm-run-all provides features for managing the execution order of multiple npm scripts. You can run scripts sequentially, concurrently, or a combination of both, making it ideal for complex workflows.

  • npm-run:

    npm-run is a simple tool for running a single npm script programmatically. It does not provide features for managing multiple scripts or their execution order.

  • parallelshell:

    parallelshell does not provide features for managing the execution order of commands. It simply runs all specified commands in parallel.

Output Handling

  • concurrently:

    concurrently provides color-coded output for each command, making it easy to distinguish between the outputs of different scripts. This is particularly useful when running multiple tasks simultaneously.

  • npm-run-all:

    npm-run-all does not provide specialized output handling for concurrent scripts. The output from all scripts is combined, which can make it harder to distinguish between them when running scripts concurrently.

  • npm-run:

    npm-run does not provide any special output handling. It simply runs the specified npm script and outputs the result to the console.

  • parallelshell:

    parallelshell does not provide any special output handling. The output from all commands is combined, which can make it difficult to distinguish between them.

Ease of Use

  • concurrently:

    concurrently is easy to use and requires minimal configuration. You can run multiple commands with a single command, and the color-coded output makes it easy to understand what is happening.

  • npm-run-all:

    npm-run-all is easy to use for running multiple scripts, but it may require some configuration to set up complex workflows. The documentation is clear, and it provides examples for common use cases.

  • npm-run:

    npm-run is simple to use for running a single npm script programmatically. It is lightweight and does not require much setup.

  • parallelshell:

    parallelshell is straightforward to use for running multiple shell commands in parallel. It requires minimal setup and is easy to integrate into existing workflows.

Code Examples

  • concurrently:

    Running multiple commands concurrently with concurrently

    "scripts": {
      "start-server": "node server.js",
      "start-client": "npm start --prefix client",
      "start": "concurrently \"npm run start-server\" \"npm run start-client\""
    }
    
  • npm-run-all:

    Running multiple npm scripts sequentially or concurrently with npm-run-all

    "scripts": {
      "clean": "rimraf dist",
      "build": "webpack",
      "test": "jest",
      "build-all": "npm-run-all clean build test",
      "build-concurrent": "npm-run-all --parallel clean build test"
    }
    
  • npm-run:

    Running a single npm script programmatically with npm-run

    const npmRun = require('npm-run');
    npmRun('build', (err, stdout, stderr) => {
      if (err) {
        console.error('Error running build script:', err);
        return;
      }
      console.log('Build script output:', stdout);
    });
    
  • parallelshell:

    Running multiple shell commands in parallel with parallelshell

    "scripts": {
      "build-css": "node-sass src/styles -o dist/styles",
      "build-js": "babel src -d dist",
      "build": "parallelshell \"npm run build-css\" \"npm run build-js\""
    }
    

How to Choose: concurrently vs npm-run-all vs npm-run vs parallelshell

  • concurrently:

    Choose concurrently if you need a simple and effective way to run multiple commands or scripts at the same time, especially for tasks like running a frontend and backend server simultaneously. It is user-friendly and provides clear output for each command.

  • npm-run-all:

    Choose npm-run-all if you need to run multiple npm scripts either sequentially or concurrently with more control over the execution order. It is ideal for complex workflows that require running tasks in a specific sequence or in parallel.

  • npm-run:

    Choose npm-run if you need a programmatic way to run npm scripts within your Node.js application. It is lightweight and ideal for automating tasks without the need for running multiple scripts concurrently.

  • parallelshell:

    Choose parallelshell if you need to run multiple shell commands in parallel from the command line. It is simple and effective for running multiple commands simultaneously, but it does not provide features specific to npm scripts.

README for concurrently

concurrently

Latest Release License Weekly Downloads on NPM CI Status Coverage Status

Run multiple commands concurrently. Like npm run watch-js & npm run watch-less but better.

Demo

Table of Contents

Why

I like task automation with npm but the usual way to run multiple commands concurrently is npm run watch-js & npm run watch-css. That's fine but it's hard to keep on track of different outputs. Also if one process fails, others still keep running and you won't even notice the difference.

Another option would be to just run all commands in separate terminals. I got tired of opening terminals and made concurrently.

Features:

  • Cross platform (including Windows)
  • Output is easy to follow with prefixes
  • With --kill-others switch, all commands are killed if one dies

Installation

concurrently can be installed in the global scope (if you'd like to have it available and use it on the whole system) or locally for a specific package (for example if you'd like to use it in the scripts section of your package):

npmYarnpnpmBun
Globalnpm i -g concurrentlyyarn global add concurrentlypnpm add -g concurrentlybun add -g concurrently
Local*npm i -D concurrentlyyarn add -D concurrentlypnpm add -D concurrentlybun add -d concurrently

* It's recommended to add concurrently to devDependencies as it's usually used for developing purposes. Please adjust the command if this doesn't apply in your case.

Usage

Note The concurrently command is also available under the shorthand alias conc.

The tool is written in Node.js, but you can use it to run any commands.

Remember to surround separate commands with quotes:

concurrently 'command1 arg' 'command2 arg'

Otherwise concurrently would try to run 4 separate commands: command1, arg, command2, arg.

In package.json, escape quotes:

"start": "concurrently 'command1 arg' 'command2 arg'"

You can always check concurrently's flag list by running concurrently --help. For the version, run concurrently --version.

Check out documentation and other usage examples in the docs directory.

API

concurrently can be used programmatically by using the API documented below:

concurrently(commands[, options])

  • commands: an array of either strings (containing the commands to run) or objects with the shape { command, name, prefixColor, env, cwd, ipc }.

  • options (optional): an object containing any of the below:

    • cwd: the working directory to be used by all commands. Can be overridden per command. Default: process.cwd().
    • defaultInputTarget: the default input target when reading from inputStream. Default: 0.
    • handleInput: when true, reads input from process.stdin.
    • inputStream: a Readable stream to read the input from. Should only be used in the rare instance you would like to stream anything other than process.stdin. Overrides handleInput.
    • pauseInputStreamOnFinish: by default, pauses the input stream (process.stdin when handleInput is enabled, or inputStream if provided) when all of the processes have finished. If you need to read from the input stream after concurrently has finished, set this to false. (#252).
    • killOthersOn: once the first command exits with one of these statuses, kill other commands. Can be an array containing the strings success (status code zero) and/or failure (non-zero exit status).
    • maxProcesses: how many processes should run at once.
    • outputStream: a Writable stream to write logs to. Default: process.stdout.
    • prefix: the prefix type to use when logging processes output. Possible values: index, pid, time, command, name, none, or a template (eg [{time} process: {pid}]). Default: the name of the process, or its index if no name is set.
    • prefixColors: a list of colors or a string as supported by chalk and additional style auto for an automatically picked color. If concurrently would run more commands than there are colors, the last color is repeated, unless if the last color value is auto which means following colors are automatically picked to vary. Prefix colors specified per-command take precedence over this list.
    • prefixLength: how many characters to show when prefixing with command. Default: 10
    • raw: whether raw mode should be used, meaning strictly process output will be logged, without any prefixes, coloring or extra stuff. Can be overridden per command.
    • successCondition: the condition to consider the run was successful. If first, only the first process to exit will make up the success of the run; if last, the last process that exits will determine whether the run succeeds. Anything else means all processes should exit successfully.
    • restartTries: how many attempts to restart a process that dies will be made. Default: 0.
    • restartDelay: how many milliseconds to wait between process restarts. Default: 0.
    • timestampFormat: a Unicode format to use when prefixing with time. Default: yyyy-MM-dd HH:mm:ss.SSS
    • additionalArguments: list of additional arguments passed that will get replaced in each command. If not defined, no argument replacing will happen.

Returns: an object in the shape { result, commands }.

  • result: a Promise that resolves if the run was successful (according to successCondition option), or rejects, containing an array of CloseEvent, in the order that the commands terminated.
  • commands: an array of all spawned Commands.

Example:

const concurrently = require('concurrently');
const { result } = concurrently(
  [
    'npm:watch-*',
    { command: 'nodemon', name: 'server' },
    { command: 'deploy', name: 'deploy', env: { PUBLIC_KEY: '...' } },
    {
      command: 'watch',
      name: 'watch',
      cwd: path.resolve(__dirname, 'scripts/watchers'),
    },
  ],
  {
    prefix: 'name',
    killOthers: ['failure', 'success'],
    restartTries: 3,
    cwd: path.resolve(__dirname, 'scripts'),
  },
);
result.then(success, failure);

Command

An object that contains all information about a spawned command, and ways to interact with it.
It has the following properties:

  • index: the index of the command among all commands spawned.

  • command: the command line of the command.

  • name: the name of the command; defaults to an empty string.

  • cwd: the current working directory of the command.

  • env: an object with all the environment variables that the command will be spawned with.

  • killed: whether the command has been killed.

  • state: the command's state. Can be one of

    • stopped: if the command was never started
    • started: if the command is currently running
    • errored: if the command failed spawning
    • exited: if the command is not running anymore, e.g. it received a close event
  • pid: the command's process ID.

  • stdin: a Writable stream to the command's stdin.

  • stdout: an RxJS observable to the command's stdout.

  • stderr: an RxJS observable to the command's stderr.

  • error: an RxJS observable to the command's error events (e.g. when it fails to spawn).

  • timer: an RxJS observable to the command's timing events (e.g. starting, stopping).

  • stateChange: an RxJS observable for changes to the command's state property.

  • messages: an object with the following properties:

    • incoming: an RxJS observable for the IPC messages received from the underlying process.
    • outgoing: an RxJS observable for the IPC messages sent to the underlying process.

    Both observables emit MessageEvents.
    Note that if the command wasn't spawned with IPC support, these won't emit any values.

  • close: an RxJS observable to the command's close events. See CloseEvent for more information.

  • start(): starts the command and sets up all of the above streams

  • send(message[, handle, options]): sends a message to the underlying process via IPC channels, returning a promise that resolves once the message has been sent. See Node.js docs.

  • kill([signal]): kills the command, optionally specifying a signal (e.g. SIGTERM, SIGKILL, etc).

MessageEvent

An object that represents a message that was received from/sent to the underlying command process.
It has the following properties:

CloseEvent

An object with information about a command's closing event.
It contains the following properties:

  • command: a stripped down version of Command, including only name, command, env and cwd properties.
  • index: the index of the command among all commands spawned.
  • killed: whether the command exited because it was killed.
  • exitCode: the exit code of the command's process, or the signal which it was killed with.
  • timings: an object in the shape { startDate, endDate, durationSeconds }.

FAQ

  • Process exited with code null?

    From Node child_process documentation, exit event:

    This event is emitted after the child process ends. If the process terminated normally, code is the final exit code of the process, otherwise null. If the process terminated due to receipt of a signal, signal is the string name of the signal, otherwise null.

    So null means the process didn't terminate normally. This will make concurrently to return non-zero exit code too.

  • Does this work with the npm-replacements yarn, pnpm, or Bun?

    Yes! In all examples above, you may replace "npm" with "yarn", "pnpm", or "bun".