I was just thinking it would be nice to target all subtasks like build:foo build:bar and run them in parallel... is this something you've considered/a use case you're interested in?

What do you think about having an option that will exit with a non zero code when one of the subtasks exits with an error when running with -P?

One use case I'm thinking of is running tests of different sub-projects in parallel. e.g. npm test runs npm-run-all -P test:project1 test:project2

We want the entire process to exit > 0 if one of those fail, but we want each one to finish because each generates a report for CI.

Right now, without -c it would exit too early, but with -c the exit code of the entire thing is 0.

run-s "run-server -- --port {0:=8080}"            # --> run-s "run-server -- --port 8080"
run-s "run-server -- --port {0:=8080}" -- 3000    # --> run-s "run-server -- --port 3000"

If the default value of a placeholder is nothing and the argument for the placeholder is nothing, the placeholder will be removed.

run-s "run-server -- --port {0}"            # --> run-s "run-server -- --port "
run-s "run-server -- --port {0}" -- 3000    # --> run-s "run-server -- --port 3000"

Hello,

I am trying to slim down my build script with npm-run-all. What I really want to use is the pattern matching for running tasks which saves a lot of repeating npm runs.

The thing I am having trouble with is the following scenario:

"copy": "npm-run-all copy:*",
  "copy:images": "copyfiles -u 1 app/images/**/*.* build",
  "copy:fonts": "copyfiles -u 1 app/fonts/**/*.* build",
"lint": "eslint app/scripts/**/*.js",
"browserify": "browserify app/scripts/main.js -o build/scripts/bundle.js  -d -t [ babelify ] -p [minifyify ]",
"build": "npm-run-all copy build:*",
  "build:styles": "pleeease-compile",
  "build:scripts": "npm-run-all lint browserify"

When I run 'npm run copy' everything works okay but trying to run 'npm run build' and the execution hangs on the copy task.

Is it just me, or do I have to manually include the start script in order for npm-run-all to pick it up?

"scripts": {
  "watch": "...",
  "dev": "npm-run-all --parallel watch start"
}

Issuing:

$ npm run dev

Did not perform default node server.js command. No errors, just not running my server.

However when I manually add start script:

"scripts": {
  "start": "node server.js",
  "watch": "...",
  "dev": "npm-run-all --parallel watch start"
}

all is well. this is on Windows.

When I run tasks in parallel, I will see a mix of stdout of those tasks.
So labels would be useful to indicate that each line has outputted from which tasks.

$ npm-run-all --labeled-output --parallel task1 task2

[task1] hello
[task1] world
[task2] hey
[task1] !!
[task2] everyone.

This feature should be an option since it modifies the outputs of tasks.

output without --print-label:

output with --print-label:

When I do npm test it outputs colored log.
When I do it with your tool there's no color.

I'd really love to use this functionality in p-s. Any chance you'd be willing to open source that bit as a separate module (or would you be ok with me doing it)?

Also, I totally love this module. Like a ton. Thank you!

It would appear that I am losing all the pretty colors from various CLI's that I run with this tool.

Will try digging in to see if there is a sane way to keep to colors.

https://github.com/nodejs/LTS#readme

I will drop supports for both 0.10 and 0.12 at the end of 2016.

Awesome. Lovin npm-run-all and the consolidated efforts!

I would like to pass in arguments such as:

    "compile:ts:cjs": "tsc --p tsconfig.commonjs.json $*",
    "watch:compile:ts": "npm-run-all -p compile:ts:* -- -w",
    "watch:compile:ts:cjs": "npm run compile:ts:cjs -- -w"

$ npm run compile:ts:cjs -- -w works as expected and tsc invokes with the watch flag, as does $ npm run watch:compile:ts:cjs"

$ npm run watch:comile:ts does not work as desired, tsc does not watch. npm-debug.log

Ultimately I want to be able to "watch": "npm-run-all -p watch:* " and to snag several different watchers and not just tsc -w.

Is there an existing option of accomplishing the same or is this an enhancement?

Hey! I'm setting up a node server with TypeScript, and I'd like to spawn tsc -w (compile + watch .ts files) in parallel with nodemon (watch compiled .js files + restart server).
The problem is that I need to delay the spawning of nodemon until tsc is done compiling.

I think it would be very useful if we could tell npm-run-all to wait for a message to appear on stdout before continuing to spawn tasks.

What do you think? If you guys think it's a good idea I can try to put together a PR. Of course I could use some pointers in that case.

When running multiple tasks simultaneously, if one task crashes, the others continue running, with no easy way to kill them. For example:

"scripts": {
    "runall": "npm-run-all --parallel watch webserver",
    "watch": "gulp watch",
    "webserver": "node server.js"
}

When I run npm run runall, it runs watch and webserver in parallel. Let's say that watch crashes for some reason (exits with a non-zero exit code). When this happens, npm-run-all also exits. But webserver is still running. If I re-run npm run runall, I now get an error because the webserver can't start because the already-running instance is blocking the port number.

It would be nice if when one of the tasks crashes, npm-run-all would kill the other tasks too.

I'm writing a ci test that needs to run two commands in parallel, one is the server, the other is the test.

Using run-p start test I can start the server and run the test. There's a notable issue with getting that working here.

https://stackoverflow.com/questions/37466757/how-do-i-run-postmans-newman-in-ci-environment

But after all is said and done, and the test process finishes I need to exit the entire run-p process. Is there away to end the process from within the process?

What I need is sort of like.

run-p start "test && kill {this}"

If i'm running multiple scripts in parallel, is there a way to aggregate the logs so they don't blend into one incomprehensible mess?

First off, awesome package! Great work. It has been very helpful so far as I am transitioning to using npm scripts instead of Gulp/Grunt. I'm just running into one issue: when I run my npm run dev script, which uses npm-run-all I get a TypeError: undefined is not a function error, which is preventing my lint:watch script from running. I have done some debugging, and everything works as expected running npm run lint:watch by itself, or npm run dev without the lint:watch command...but I don't know how to debug it. Is this a known issue with npm-run-all?

Related issue

I don't know if this is an issue with eslint-watch or npm-run-all, so I have posted the issue in both places. I do know that all of my other packages work as expected so something seems to be wrong with either eslint-watch or npm-run-all.

rizowski/eslint-watch#28

Steps to reproduce:

• Clone the project: https://github.com/trevordmiller/npm-run-all-example
• npm install
• npm run lint:watch runs as expected
• npm run dev runs npm-run-all which works for everything except for lint:watch which is outputting TypeError: undefined is not a function

From the code, I believe to understand that non-zero exit codes abort a sequential series of tasks. If true (or if different), it would be nice if that were documented.

npm command has this --silent option to avoid npm test to spit out npm errors when running npm command as a script. I found that really nice.
Would be nice for npm-run-all to have this options too.

When a npm script exits with a non-zero exit code, npm prints a huge warning (npm/npm#8821). And when using npm or npm-run-all in another npm script, the warning appears twice if the inner script fails, making it even worse. These warnings can be suppressed by using the --silent flag, so it was nice that you added this flag to npm-run-all as well.

However, this flag also suppresses npms output of which command it is running. When only running one npm script, that doesn't matter much. But with npm-run-all you run multiple scripts, so I'd like to see which script it runs, to know how far along it is.

So it would be nice with a new option that makes npm-run-all print the task it will run right before it runs it (either the npm script name, or the npm script name and the command it expands to).

We started to use npm-run-all at pnpm and we noticed that it doesn't work when installed with pnpm. The reason is that we create a proxy bin file (this is needed to allow running deps with the --preserve-symlinks option). As a result this check in npm-run-all fails. What is the reason for that check? Can it be removed?

I filed a defect on pnpm to fix this issue pnpm/pnpm#413. However, currently I don't know how this can be fixed on pnpm side. Could this be fixed on npm-run-all side?

From #27 (comment)

I've started getting a WARN on npm install:

npm WARN deprecated [email protected]: cross-spawn no longer requires a build toolchain, use it instead!

babel-polyfill exists package.json as dependencies.
But, it is never imported from production code.

I think that it can solve by adding require('babel-polyfill') to src/bin/npm-run-all.js and index.js.
What do you think?

Refs:

• Job #119.1 - moqada/aws-sdk-config-loader - Travis CI
• Polyfill · Babel

In our scripts we are using $npm_config_xxx params.
for example:

"scripts": {
    "zip": "cd $npm_config_outdir && zip -rT $npm_config_outzip .",
    "crx": "crx pack $npm_config_outdir",
    "zip-crx": "npm run zip && npm run crx",
}

We can run such scripts via:

npm run zip-crx --outdir=dist --outzip=archive.zip

it would be great if npm-run-all support such npm params and not confuse it with own params or command own params.
Currently I get error:

ERROR: Invalid Option: --outdir=dist

Hello again,
What I currently have problem with is the following code:

"watch": "npm-run-all --parallel watch:*",
      "watch:html": "nodemon -w src/ --ext html --exec npm run copy:html",
      "watch:styles": "nodemon -w src/styles/ --ext css --exec npm run copy:css",
      "watch:scripts": "nodemon -w src/scripts/ --ext js --exec npm run browserify"

Running 'npm run watch' executes the tasks but then when I change the files tasks are not re-run. So far I have done it with parallelshell but I suppose npm-run-all --parallel should do the same thing, right?

I have updated the test project to include this build step - https://github.com/lostm1nd/WebDevolopment/tree/master/Pizzeria-ES2015

The moment I saw parallel, next option that came to my mind, was serial. On error, realized, that it should sequential.

It would be great to have serial as a synonymous option for sequential

Happy to raise a PR, if you are convinced.

Thanks!!

This is admittedly Webstorm specific, but as FYI:

This is the same issue that I reported in Issue 32, but it occurs in Webstorm's terminal on Windows. Hitting Ctrl+C produces the prompt for "Terminate batch job (Y/N)?", but answering "Y" doesn't actually get you back a usable command line. It appears to be using the native Window command line behind the scenes since this is shown when I open the Webstorm terminal:

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

The result of hitting Ctrl+C:
^C^C^CTerminate batch job (Y/N)? Terminate batch job (Y/N)? ^CTerminate batch job (Y/N)? ^^CCTerminate batch job (Y/N)? Terminate batch job (Y/N)? Terminate batch job (Y/N)? ^CTerminate
batch job (Y/N)? Terminate batch job (Y/N)? Y

It becomes frozen after answering Y.

Hi @mysticatea and @k88hudson! Thanks for your hard work with npm-run-all!

I maintain a similar library - the functionality is slightly different but it shares a lot of common functionality with npm-run-all. My library is called parallelshell - which I maintain with @paulpflug. I am also aware of a few other libraries that attempt to solve the problem of properly parallelising npm (or shell) tasks:

• concurrently which is written by @kimmobrunfeldt and has had contributions from @luv2code.
• shell-executor which is written by @royriojas.
• npm-parallel which is written by @spion
• pkgrun which is written by @reggi

We're all trying to reach the same goal - run npm tasks quickly and easily in parallel (and sometimes serially), and have them log & exit in ways you'd expect. For the most part, each of us (I presume) has convergently developed these solutions. While it's great that we're all solving this problem, its bad that we're all solving it...

The point

I think we should combine forces, to make one canonical parallelisation tool. Personally, I see no point in continuing development of both parallelshell and npm-run-all - we may as well just have one. Having said that, I'm still using parallelshell because it solves particular bugs that I (and @paulpflug) have solved (with great pain) which npm-run-all is yet to solve.

The way I see it - I'm happy (as long as @paulpflug is) to port the fixes we have developed in parallelshell, over to npm-run-all rather than expend effort developing the features I want from npm-run-all inside of parallelshell. I dont want to speak for all other developers (@paulpflug, @kimmobrunfeldt, @luv2code, @royriojas, @spion, and @reggi) - but I for one would certainly like for all of these projects to consolidate under one label. If and when these projects converge, I'd like everyone of the original authors/contributors to be a contributor of the new project - to ensure that it remains well maintained. How does this sound to you?

FYI, I chose to file this issue here - rather than any of the other projects - because I think this project has the best name. By and large they are pretty much all interchangeable (or certainly could be with a bit of development).

Summary

• npm-run-all and parallelshell are very similar (as are other projects)
• We should develop one
• (IMO) All of the maintainers of the other projects should all be core contributors of this project, and deprecate their respective projects.
• Everyone is happy and users have one well developed tool to chose from.

Example

[22:12:42] Starting [lint:stylelint]
[lint:stylelint] Some output
[22:12:45] Finished [lint:stylelint] after 3.07 s

That would be amazing.

Hi

I bumped into a problem that npm-run-all does not propagate overwritten configuration parameters (via command line) when running tasks.
To be more precise:
when i run a package script from command line and overwrite configuration parameters (via --<project.name>:<configuraton_param_name>=<configuration_param_value> ) than everything is fine, ie. my script command would be run against overwritten parameters.

But if my package script command executes npm-run-all than any of "run-all" tasks are not handed overwritten parameters.
I did create a small test case https://github.com/jmilkiewicz/npm-run-all-bug
which uncovers that issue. The case is based on specifying custom matcher for mocha via configuration parameters.

Hi,

Can I pass an argument into an npm-run-all script from the command line?

I have defined these scripts:

"css": "grunt watch:css",
"mm": "bundle exec middleman",
"serve": "npm-run-all --parallel css mm",

I can pass an argument directly to the mm script, i.e. npm run mm -- --port=4567. Can I pass this argument in to the serve script from the command line and have it forwarded on to the mm script?

My script is

npm-run-all delay delay delay development-web-server

"delay": "node ./code/delay 3000"

But it only delays for 3 seconds and then runs development-web-server.

> [email protected] development-web-server-delayed G:\work\webapp
> npm-run-all delay delay delay development-web-server


> [email protected] delay G:\work\webapp
> node ./code/delay 3000


> [email protected] development-web-server G:\work\webapp
> nodemon ./code/web-server/entry.js

While investigating kentcdodds/webpack-validator#7, I've been looking into this project and it's claim of supporting windows.

I've cloned the project and run the tests and have noticed a few of things in relation to windows support.

• Using Appveyor builds. This is essential for supporting windows as it allows tests to be run in a windows environment.
• Code coverage. There is a high percentage of code coverage, but I noticed that spawn-win32.js isn't in the coverage report.

The actual issue I have discovered is that which-npm.js is returning a path like the following

• C:\Program Files\nodejs\npm.CMD

In windows paths are typically normalized to

• C:\\Program Files\\nodejs\\npm.CMD

This results in npm complaining with

'C:\Program' is not recognized as an internal or external command,
operable program or batch file.

I thought this might be an issue in which, but it appears npm is using this package with no apparent issues...

I'm happy to create pull requests in an attempt to resolve any of these issues

{
"start": "chokidar ./lib -c 'npm run tasks:dev' --initial",
"tasks:all": "npm-run-all build:* dev:*",
"tasks:dev": "npm-run-all dev:*",
"build:lint:eslint": "eslint --parser babel-eslint ./lib",
"build:lint:standard": "standard --parser babel-eslint ./lib/**/*",
"dev:scripts:babel": "babel --presets es2015 ./lib -d ./"
}

It'd be neat if I could chain : together.

I could have build:* tasks, dev:* tasks, dev:styles:* tasks, etc.

how about adding a --waterfall command line option?

Hitting Ctrl+C in Windows produces the prompt for "Terminate batch job (Y/N)?", but answering "Y" doesn't actually get you back a usable command line.

For an example of this behavior:

1. Clone React Slingshot
2. npm install
3. Run npm start in Git Bash for WIndows
4. Note that hitting Ctrl+C fails to return a usable command line.

Is there a particularly good watcher for npm-run-all?

Out of the ones I've tried (watch, nodemon, chokidar-cli) I think I like chokidar-cli the best.

It kind of stinks it has to re-run the processes from scratch though.

Ideally there would be a watcher that could watch files that don't come equipped with their own watcher and update them without having to completely re-run their npm task.

See? I'm watching ./lib for changes, and when there are changes, I do the compilation step on the npm run scripts I have. Unfortunately it doesn't just compile these lightning fast, but has to restart the process.

I don't know if there's some super clever/cool way to watch, or if this is just something each CLI has to build into their own product, but if there is some super cool way to watch, please let me know. 👍

Does any of this make any sense or am I just rambling?

I love this feature in better-npm-run. I'd like a way to define env vars before run a command and also it is cross platform.

Is it possible to compile serial and parallel tasks? Ex:

run-s lint run-p build

In this example, I'm assuming that build will run after lint completes

Hey, it's possible to alias npm=yarn, but it would be nice if it was at all possible to make it use choose yarn when it's available.

This issue is for tracking that.

See https://www.npmjs.com/package/npm-run-all
Our scripts are growing and we can use a simpler solution like npm-run-all.

Like it says on the tin. npm-run-all restart throws an error if you haven't explicitly defined a restart task. There's a built-in npm task for restart. I can just add a task that does the same thing, but maybe npm-run-all should recognize the built-in task.

I'm trying to use the Node API to keep some tasks running in the background, while other tasks are performed. Once the other tasks are finished, I'd like to abort all promises which did not finish.

It looks like there is the abortTasks function, but it's not exposed as a public API.

It would be nice if that could be changed. :)

I was wondering how can we define watch patterns, and can a single watch dispatch to multiple scritps ?

An ideal world we could in a single folder watch dispatch different tasks depending on the file type change:

1. setup a folder to be watched
2. based on the files that have changed on that folder execute some npm run scripts in parallalel

example for a pacakge.json with test, compile:

• watch folder src/
• when *test.js changes, run tests
• when *.ts changes compile then run tests

Currently, tests for parallel features are relying on timer, so those are slippery.
I want to improve those tests.

Hi,

My project's package.json is

  "config": {
    "DEST": "build",
    "PORT": "3000"
  },
  "scripts": {
    ...
    "build:before": "mkdir -p $npm_package_config_DEST",
    ...
  }

build:before task is just making directory.

$ npm run build:before
...
$ echo $?
0
$ npm-run-all build:before
...
ERROR: build:before: None-Zero Exit(7);
...
npm ERR! node v5.0.0
npm ERR! npm  v3.3.9

v1.2.13 works fine but v1.3.0 has been broken :(

Any suggestions?

Thanks

How do you feel about testing against/supporting node 0.10.x @mysticatea?