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"
  }
}

But if i use yarn?

@strobox That's why I use $npm_execpath rather than npm or jest, whatever binary you're invoked will be run then.

"prebuild": "$npm_execpath run clean"

@strobox That's why I use $npm_execpath rather than npm or jest, whatever binary you're invoked will be run then.

Dude that's genius

@strobox That's why I use $npm_execpath rather than npm or jest, whatever binary you're invoked will be run then.

OMG thank you sir. So good.

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

Another option that supports npm, pnpm, yarn is yarpm.

Beware when using any of these options that package manager might have subtly different behaviors when running scripts, make sure you know what your scripts do in all package managers if you want to make it package manager independent like this. Common cases like the above should be fine, but i think yarn does different things with "script:foo" type scripts.

dum is also an interesting take - a standalone package.json scripts runner, independent of the package manager.

See also a discussion about whether this functionality should be added to node itself (through the new experimental corepack feature) and associated problems/challenges. I also learned on that issue that yarn supports running another script through just a "run" command, so example above would be "run build-dev && run build-prod". Strange I can't find that anywhere in yarn's docs, it does not a seem well-advertised feature.

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.