concurrently vs np vs npm-run vs npm-run-all
Script Execution and Package Publishing Workflows
concurrentlynpnpm-runnpm-run-allSimilar Packages:

Script Execution and Package Publishing Workflows

concurrently, npm-run, and npm-run-all are utilities designed to run multiple npm scripts or shell commands efficiently, supporting parallel or sequential execution. np, on the other hand, is a specialized CLI tool focused on the package publishing lifecycle, handling versioning, changelog generation, and git tagging. While the first three optimize local development and build processes, np streamlines the release workflow to the npm registry.

Npm Package Weekly Downloads Trend

3 Years

Github Stars Ranking

Stat Detail

Package
Downloads
Stars
Size
Issues
Publish
License
concurrently07,781411 kB5910 days agoMIT
np07,699107 kB6a month agoMIT
npm-run0187-68 years agoMIT
npm-run-all05,838-1148 years agoMIT

Script Execution and Publishing: concurrently vs np vs npm-run vs npm-run-all

In modern JavaScript development, managing build scripts and release workflows is critical. concurrently, npm-run, and npm-run-all focus on running commands efficiently, while np solves a different problem β€” publishing packages safely. Let's break down how they fit into your toolchain.

πŸƒ Running Commands: Parallel vs Sequential

concurrently runs any number of commands at the same time.

  • It treats each command as a separate process.
  • Great for mixing npm scripts with other tools like nodemon.
// package.json
{
  "scripts": {
    "dev": "concurrently \"npm run server\" \"npm run client\""
  }
}

npm-run-all runs npm scripts in parallel or series using specific flags.

  • You must explicitly state --parallel or --serial.
  • Best for chaining build steps that depend on each other.
// package.json
{
  "scripts": {
    "build": "npm-run-all --serial clean:* --parallel build:*"
  }
}

npm-run runs scripts by name without extra flags for basic cases.

  • Simpler syntax but fewer features for complex flows.
  • Often used in older projects or simple setups.
// package.json
{
  "scripts": {
    "test": "npm-run lint test:unit"
  }
}

np does not run build scripts.

  • It triggers the publishing workflow.
  • You run it directly in the terminal, not inside package.json scripts.
# Terminal
np major
# Bumps version, tags git, and publishes

πŸ“’ Output Management: Colors and Prefixes

concurrently colors output by default.

  • Each process gets a unique color.
  • Prefixes show which command produced the log.
# Output example
[server] Server running on port 3000
[client] webpack compiled successfully

npm-run-all passes output through directly.

  • No built-in coloring for different scripts.
  • Logs appear as they come from the underlying npm scripts.
# Output example
> project@1.0.0 build:css
> postcss ...

> project@1.0.0 build:js
> webpack ...

npm-run behaves similarly to standard npm.

  • Minimal output decoration.
  • Relies on the underlying script for formatting.
# Output example
> project@1.0.0 lint
> eslint ...

np provides an interactive UI.

  • Shows a checklist of tasks (git, npm, version).
  • Clear success or failure messages for each step.
# Output example
βœ” Git
βœ” npm
βœ” Bump version 1.0.0 β†’ 2.0.0

πŸ”— Script Composition: Patterns and Globbing

concurrently does not support glob patterns for scripts.

  • You must list every command explicitly.
  • More verbose for large sets of similar tasks.
// concurrently: List each one
"dev": "concurrently \"npm run watch:css\" \"npm run watch:js\" \"npm run watch:html\""

npm-run-all supports glob patterns for script names.

  • You can run all scripts starting with build: easily.
  • Reduces repetition in package.json.
// npm-run-all: Use patterns
"build": "npm-run-all build:*"
// Runs build:css, build:js, etc.

npm-run has limited pattern support.

  • Mostly focuses on exact script names.
  • Less flexible for scaling build pipelines.
// npm-run: Exact names
"test": "npm-run lint check-types test-unit"

np does not compose scripts.

  • It hooks into the npm publish lifecycle.
  • You can configure it via a .np-config.json file instead.
// .np-config.json
{
  "yarn": true,
  "contents": "dist"
}

πŸ›‘οΈ Safety and Publishing Workflows

concurrently, npm-run, and npm-run-all do not handle publishing.

  • They are for local development and CI build steps.
  • You still need npm publish manually.
# Manual publish after build
npm run build
npm publish

np automates safety checks before publishing.

  • Ensures tests pass, linting is clean, and git is ready.
  • Prevents accidental publishes of broken code.
# np runs checks automatically
np
# 1. Runs tests
# 2. Checks lint
# 3. Bumps version
# 4. Publishes

⚠️ Maintenance and Future-Proofing

npm-run is less actively maintained than npm-run-all.

  • Many teams have migrated to npm-run-all for better features.
  • Avoid starting new projects with npm-run unless you have a specific legacy constraint.

npm-run-all is the standard for script composition.

  • Widely adopted and stable.
  • Safe choice for long-term build pipelines.

concurrently is the standard for local dev servers.

  • Actively maintained and very popular.
  • Best for running frontend and backend together.

np is the standard for module publishing.

  • Regularly updated to support new npm features.
  • Essential for teams publishing libraries.

πŸ“Š Summary: Key Differences

Featureconcurrentlynpm-run-allnpm-runnp
Primary UseRun any commandsCompose npm scriptsRun npm scriptsPublish packages
Parallel Executionβœ… Defaultβœ… Via --parallel❌ Limited❌ N/A
Output Coloringβœ… Auto❌ Pass-through❌ Pass-throughβœ… Interactive UI
Glob Patterns❌ Noβœ… Yes❌ Limited❌ N/A
Publishing❌ No❌ No❌ Noβœ… Yes

πŸ’‘ The Big Picture

concurrently is your go-to for local development β€” running your API, frontend, and database watchers side by side with clear logs.

npm-run-all is your build pipeline manager β€” chaining tasks like clean, build, and test with precision and pattern support.

npm-run is a legacy option β€” functional but generally outclassed by npm-run-all in modern ecosystems.

np is your release manager β€” ensuring you never publish a broken package by automating the boring and risky parts of versioning.

Final Thought: You will likely use concurrently for development, npm-run-all for CI builds, and np when it's time to ship. They solve different problems and often work best together.

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

  • concurrently:

    Choose concurrently when you need to run arbitrary shell commands or mix npm scripts with other binaries like watch or nodemon. It excels at managing output streams with color-coded prefixes, making it ideal for local development servers where you need to see logs from multiple processes at once.

  • np:

    Choose np if you want to automate and standardize your package publishing process. It handles version bumping, git tagging, pushing commits, and publishing to npm in a single interactive workflow, reducing the risk of human error during releases.

  • npm-run:

    Choose npm-run only for simple, legacy projects that require basic script execution without complex patterns. For most modern setups, this package is less maintained than npm-run-all, so evaluate if upgrading to a more robust alternative is feasible before adopting it.

  • npm-run-all:

    Choose npm-run-all when you need to compose npm scripts using glob patterns or require strict control over parallel and sequential execution within your package.json. It is the standard choice for build pipelines where script dependencies and order matter.

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.

[!IMPORTANT] Windows only supports double quotes:

concurrently "command1 arg" "command2 arg"

Remember to escape the double quotes in your package.json when using Windows:

"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().
    • shell: shell executable used to run command strings. When unset, uses npm_config_script_shell if present (for example when run via npm run), otherwise cmd.exe on Windows or /bin/sh elsewhere. See shell resolution.
    • 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. Templates can wrap any portion of the prefix with {color} and {/color} to restrict coloring to that region (eg [{color}{name}{/color}] colors only the name, leaving the brackets uncolored). If either marker is omitted the missing side is implicit, so a template with no markers is colored in full.
    • prefixColors: a list of colors or a string as supported by Chalk and additional style auto for an automatically picked color. Supports all Chalk color functions: #RRGGBB, bg#RRGGBB, hex(), bgHex(), rgb(), bgRgb(), ansi256(), bgAnsi256(). Functions and modifiers can be chained (e.g., rgb(255,136,0).bold, black.bgHex(#00FF00).dim). 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',
    killOthersOn: ['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".