Run multiple npm scripts in parallel

Use a process runner such as concurrently when one development command needs to start several long-running scripts. Decide what should happen when one process exits; simply starting them together does not establish that either service is ready.

Use concurrently

Install it in the project:

npm install --save-dev concurrently

For a project that already has its server and CSS tooling installed, a package.json scripts section can look like this:

{
  "scripts": {
    "start": "node server.js",
    "watch:css": "postcss src/styles.css --watch --output dist/styles.css",
    "dev": "concurrently --kill-others --names server,css \"npm:start\" \"npm:watch:css\""
  }
}

npm run dev

npm:start and npm:watch:css are concurrently's shortcuts for npm scripts. Named prefixes help distinguish output. --raw suppresses the runner's normal output formatting when unmodified output is useful.

--kill-others terminates the other commands when one exits, including a successful exit. If only failure should stop siblings, use --kill-others-on-fail. Check the runner's success policy for CI, and verify that your processes handle termination and close their own resources.

Use npm-run-all for mixed ordering

For a project using npm-run-all:

npm install --save-dev npm-run-all

{
  "scripts": {
    "dev": "npm-run-all --parallel start watch:css",
    "build": "npm-run-all --sequential clean compile",
    "dev:built": "npm-run-all -s build -p start watch:css"
  }
}

These entries assume start, watch:css, clean, and compile are defined elsewhere in the same scripts object. The final command completes build before starting the two development processes in parallel. Wildcards such as "watch:*" can select a group of scripts.

A completed build is different from a running server becoming ready. If a test depends on an HTTP endpoint, add a bounded readiness check before launching that test.

Avoid relying on shell-specific backgrounding

In a POSIX shell, npm run start & npm run watch:css backgrounds the first command. Exit-status propagation, output, and cleanup then become your responsibility. In Windows cmd.exe, & has different sequencing behavior; PowerShell has its own rules. An npm script using that syntax is not a portable process supervisor.

Running a script across npm workspaces is also not inherently parallel: npm runs selected workspace scripts in workspace order. Node's version does not change that into concurrent orchestration. For a larger repository, a task runner can additionally model dependencies and caching; choose it when that extra coordination is useful.

Keep development runners separate from your production service-management decision. In production, use the deployment platform's process and restart model, and test failure handling rather than assuming one local wrapper covers every case.

References

• concurrently documentation
• npm-run-all documentation
• npm workspaces