concurrently vs npm-run-all vs npm-watch
NPM Task Runner Utilities Comparison
1 Year
concurrentlynpm-run-allnpm-watchSimilar Packages:
What's NPM Task Runner Utilities?

NPM task runner utilities are packages designed to streamline the execution of multiple scripts in a Node.js environment. They help developers manage and automate tasks such as building, testing, and serving applications by allowing concurrent execution of scripts, sequential execution, or monitoring file changes. These tools enhance productivity by simplifying the process of running multiple commands, which is especially useful in complex development workflows.

npm Package Downloads Trend
Github Stars Ranking
Stat Detail
Package
Downloads
Stars
Size
Issues
Publish
License
concurrently6,601,3487,239406 kB69a month agoMIT
npm-run-all3,259,7885,775-1076 years agoMIT
npm-watch169,74832514.6 kB199 months agoMIT
Feature Comparison: concurrently vs npm-run-all vs npm-watch

Execution Model

  • concurrently:

    Concurrently allows multiple npm scripts to run at the same time, displaying their outputs in a single terminal window. This is particularly useful for tasks that are independent of each other, such as running a server and a build process simultaneously.

  • npm-run-all:

    Npm-run-all provides flexibility in execution, allowing scripts to be run in parallel or sequentially based on your needs. It can run multiple scripts at once or wait for one script to finish before starting the next, giving you control over the execution flow.

  • npm-watch:

    Npm-watch focuses on monitoring file changes and automatically rerunning specified scripts when changes are detected. This makes it ideal for development environments where you want to automate tasks like testing or building whenever you save a file.

Output Management

  • concurrently:

    Concurrently merges the output of all running scripts into a single stream, making it easier to follow the logs. It prefixes each output with the script name, helping developers identify which script is producing which output in real-time.

  • npm-run-all:

    Npm-run-all does not merge outputs by default; instead, it runs scripts in a controlled manner, allowing you to see the output of each script separately. This can be beneficial for debugging and understanding the flow of execution.

  • npm-watch:

    Npm-watch outputs logs for the script being executed upon file changes, but it does not merge outputs from multiple scripts since it typically runs a single script in response to file changes.

Configuration Flexibility

  • concurrently:

    Concurrently can be configured with various options, such as prefixing output, handling exit codes, and limiting the number of concurrent processes. This flexibility allows developers to tailor its behavior to fit their specific needs.

  • npm-run-all:

    Npm-run-all offers a variety of command-line options for controlling the execution of scripts, including the ability to run scripts in parallel or sequentially, and to handle errors gracefully. This makes it adaptable to different project requirements.

  • npm-watch:

    Npm-watch is straightforward in its configuration, focusing primarily on specifying which scripts to run upon file changes. It is less flexible in terms of execution order since it typically runs a single script in response to changes.

Use Cases

  • concurrently:

    Best suited for development environments where multiple tasks need to run simultaneously, such as running a frontend server and a backend API server at the same time. It enhances productivity by allowing developers to see all outputs together.

  • npm-run-all:

    Ideal for complex build processes where tasks need to be run in a specific order or where a combination of parallel and sequential execution is required. It helps in organizing scripts logically and efficiently.

  • npm-watch:

    Perfect for scenarios where you want to automate tasks based on file changes, such as running tests or builds whenever code is modified. It reduces the manual overhead of running scripts during development.

Community and Support

  • concurrently:

    Concurrently has a strong community and is widely used in many projects, ensuring good support and frequent updates. Its popularity means that developers can find ample resources and examples online.

  • npm-run-all:

    Npm-run-all is also well-supported and has a solid user base, making it easy to find documentation and community help. It is frequently updated to address issues and improve functionality.

  • npm-watch:

    Npm-watch, while useful, has a smaller community compared to the other two. However, it is still maintained and has enough resources available for common use cases.

How to Choose: concurrently vs npm-run-all vs npm-watch
  • concurrently:

    Choose concurrently if you need to run multiple npm scripts simultaneously and want to see their outputs in real-time. It's ideal for development environments where you want to run a server alongside a build process or watch tasks without waiting for one to finish before starting the next.

  • npm-run-all:

    Choose npm-run-all if you need to run multiple npm scripts either in sequence or in parallel, with more control over the execution order. It is particularly useful for complex workflows where you want to ensure certain tasks complete before others start, or if you want to group tasks together for better organization.

  • npm-watch:

    Choose npm-watch if you want to automatically rerun scripts when files change. It's perfect for development scenarios where you want to continuously monitor your codebase and trigger builds or tests without manual intervention.

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

| | npm | Yarn | pnpm | Bun | | ----------- | ----------------------- | ------------------------------ | -------------------------- | ------------------------- | | Global | npm i -g concurrently | yarn global add concurrently | pnpm add -g concurrently | bun add -g concurrently | | Local* | npm i -D concurrently | yarn add -D concurrently | pnpm add -D concurrently | bun 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 overriden 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).
    • killOthers: an array of exitting conditions that will cause a process to kill others. Can contain any of success or failure.
    • 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 overriden 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.ZZZ
    • 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).

  • 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".