Example of calling one script from another

package.json

{
  "name": "npm-scripts-example",
  "version": "1.0.0",
  "description": "npm scripts example",
  "scripts": {
    "clean": "rimraf ./dist && mkdir dist",
    "prebuild": "npm run clean",
    "build": "cross-env NODE_ENV=production webpack"
  }
}

Note that $npm_execpath is not cross-platform (Windows requires %npm_execpath%).

Just force everyone to use unix... ¯\_(ツ)_/¯

If you are happy to force everyone to use a specific setup, its probably easier to force everyone to use a specific package manager: npm (it is already installed), or your package manager of choice (it is only a npm -g i away).

I think the best option is: if you are the primary developer/maintainer, just hard-code your package manager of choice rather than using $npm_execpath. And set the packageManager field in package.json to support usage with corepack, which is now included in Node.

If your team/organization really can't decide on a package manager, I think its worth using yarpm/ni/dum/npm-run-all rather than forcing everyone to use a Posix shell. Most npm packages are targeting NodeJS or the browser, which are cross-platform environments, so it does not make much sense to rely on OS-specific features.

I should note if you are using corepack, you should use corepack enable, not npm -g install .... See the docs

If you are happy to force everyone to use a specific setup

Joke aside: it's not bad practice to write your package.json (or any source for that matter) as it'll be used by your CI and stop there.

Anyone wants anything fancier/newer/better/more-comfy they may do it on their machine but it's up to them.

Joke back on: not my fault if (close to) all CIs are on unix ¯\_(ツ)_/¯

&& assumes a POSIX sh environment. This likely breaks on various and sundry Windows environments, it may break the default (Free)BSD csh. It may break fish, Plan 9's rc, ion, and more.

A Gruntfile or makefile are more portable than NPM's awful built-in task runner.