SCRIPTS(7)

🎀 SCRIPTS(7) 🎀

okay bestie, welcome to scripts(7) — the page all about how npm handles the "scripts" field. this is the one you keep half-reading at 2am, so let's make it actually make sense 💅

✨ NAME ✨

Scripts — literally "How npm handles the "scripts" field". that's the whole vibe. 🦋

---

🌸 Description 🌸

k so the "scripts" property in your package.json file is like the main character of your package 💖. it supports a bunch of built-in scripts and their preset life cycle events, plus arbitrary scripts you just make up yourself. all of them can be executed by running npm run <stage>.

and the pre/post thing? iconic. commands with matching names get run for those too — like premyscript, myscript, postmyscript. 🫶

you can also run scripts that live in your dependencies with:

npm explore <pkg> -- npm run <stage>

🎀 Pre & Post Scripts 🎀

to make a "pre" or "post" script for anything you've defined in the "scripts" section of your package.json, you just... make another script with a matching name and slap "pre" or "post" at the front. that's it. no cap. ✨

{
  "scripts": {
    "precompress": "{{ executes BEFORE the `compress` script }}",
    "compress": "{{ run command to compress files }}",
    "postcompress": "{{ executes AFTER `compress` script }}"
  }
}

so in this example, npm run compress would execute these scripts exactly as described. slay. 💅

🦋 Life Cycle Scripts 🦋

there are some special life cycle scripts that only happen in certain situations 👀. these happen in addition to the pre<event>, post<event>, and <event> scripts.

• prepare, prepublish, prepublishOnly, prepack, postpack, dependencies

💖 prepare (since npm@4.0.0) 💖

• runs BEFORE the package is packed, i.e. during npm publish and npm pack
• runs on local npm install without package arguments (runs with flags like --production or --omit=dev, but does not run when installing specific packages like npm install express)
• runs AFTER prepublishOnly and prepack, but BEFORE postpack
• runs for a package if it's being installed as a link through npm install <folder>
• NOTE: if a package being installed through git contains a prepare script, its dependencies and devDependencies will be installed, and the prepare script will be run, before the package is packaged and installed.
• as of npm@7 these scripts run in the background. to see the output, run with: --foreground-scripts.
• in workspaces, prepare scripts run concurrently across all packages. if you have interdependent packages where one must build before another, consider using --foreground-scripts (which can be set in .npmrc with foreground-scripts=true) to run scripts sequentially, or structure your build differently.

🙈 prepublish (DEPRECATED) 🙈

• does not run during npm publish, but does run during npm ci and npm install. see below for more info.

bestie this one is deprecated, ok? like, don't build your whole life around it. 😭

⭐ prepublishOnly ⭐

• runs BEFORE the package is prepared and packed, ONLY on npm publish.

🔥 prepack 🔥

• runs BEFORE a tarball is packed (on "npm pack", "npm publish", and when installing a git dependency).
• NOTE: "npm run pack" is NOT the same as "npm pack". "npm run pack" is an arbitrary user defined script name, whereas "npm pack" is a CLI defined command. do not confuse them, i'm begging 🫶

💜 postpack 💜

• runs AFTER the tarball has been generated but before it is moved to its final destination (if at all — publish does not save the tarball locally).

👑 dependencies 👑

• runs AFTER any operations that modify the node_modules directory IF changes occurred.
• does NOT run in global mode.

---

🌈 Prepare and Prepublish 🌈

🎀 Deprecation Note: prepublish 🎀

since npm@1.1.71, the npm CLI has run the prepublish script for both npm publish and npm install, because it's a convenient way to prepare a package for use (some common use cases are described in the section below). it has also turned out to be, in practice, very confusing. https://github.com/npm/npm/issues/10074 😭

as of npm@4.0.0, a new event has been introduced, prepare, that preserves this existing behavior. a new event, prepublishOnly, has been added as a transitional strategy to allow users to avoid the confusing behavior of existing npm versions and only run on npm publish (for instance, running the tests one last time to ensure they're in good shape).

see https://github.com/npm/npm/issues/10074 for a much lengthier justification, with further reading, for this change. iykyk 📚

🧚 Use Cases 🧚

use a prepare script to perform build tasks that are platform-independent and need to run before your package is used. this includes tasks such as:

• compiling TypeScript or other source code into JavaScript.
• creating minified versions of JavaScript source code.
• fetching remote resources that your package will use.

running these build tasks in the prepare script ensures they happen once, in a single place, reducing complexity and variability. additionally, this means that:

• you can depend on build tools as devDependencies, and thus your users don't need to have them installed.
• you don't need to include minifiers in your package, reducing the size for your users.
• you don't need to rely on your users having curl or wget or other system tools on the target machines.

literally so clean. no notes. ✨

---

🍓 Dependencies 🍓

the dependencies script is run any time an npm command causes changes to the node_modules directory. it is run AFTER the changes have been applied and the package.json and package-lock.json files have been updated. 🌸

---

💅 Life Cycle Operation Order 💅

this is the part where the ordering actually matters, so pay attention bestie 👑

🛠 npm help

• prepare

🛠 npm help ci

• preinstall
• install
• postinstall
• prepublish
• preprepare
• prepare
• postprepare

these all run after the actual installation of modules into node_modules, in order, with no internal actions happening in between. 🫶

🛠 npm help diff

• prepare

🛠 npm help install

these also run when you run npm install -g <pkg-name>

• preinstall
• install
• postinstall
• prepublish
• preprepare
• prepare
• postprepare

if there is a binding.gyp file in the root of your package and you haven't defined your own install or preinstall scripts, npm will default the install command to compile using node-gyp via node-gyp rebuild.

these are run from the scripts of <pkg-name>. 👈

🛠 npm help pack

• prepack
• prepare
• postpack

🛠 npm help publish

• prepublishOnly
• prepack
• prepare
• postpack
• publish
• postpublish

🛠 npm help rebuild

• preinstall
• install
• postinstall
• prepare

prepare is only run if the current directory is a symlink (e.g. with linked packages). 🌀

🛠 npm help restart

if there is a restart script defined, these events are run; otherwise, stop and start are both run if present, including their pre and post iterations.

• prerestart
• restart
• postrestart

🛠 npm run <user defined>

• pre<user-defined>
• <user-defined>
• post<user-defined>

🛠 npm help start

• prestart
• start
• poststart

if there is a server.js file in the root of your package, then npm will default the start command to node server.js. prestart and poststart will still run in this case. 🔥

🛠 npm help stop

• prestop
• stop
• poststop

🛠 npm help test

• pretest
• test
• posttest

🛠 npm help version

• preversion
• version
• postversion

💀 A Note on a lack of npm help uninstall scripts 💀

while npm v6 had uninstall lifecycle scripts, npm v7 does not. removal of a package can happen for a wide variety of reasons, and there's no clear way to currently give the script enough context to be useful.

reasons for a package removal include:

• a user directly uninstalled this package
• a user uninstalled a dependent package and so this dependency is being uninstalled
• a user uninstalled a dependent package but another package also depends on this version
• this version has been merged as a duplicate with another version
• etc.

due to the lack of necessary context, uninstall lifecycle scripts are not implemented and will not function. that's just how it is. 🙈

---

🌟 Working Directory for Scripts 🌟

scripts are always run from the root of the package folder, regardless of what the current working directory is when npm is invoked. this means your scripts can reliably assume they are running in the package root. periodt. 💅

if you want your script to behave differently based on the directory you were in when you ran npm, you can use the INIT_CWD environment variable, which holds the full path you were in when you ran npm run. 🎀

🦋 Historical Behavior in Older npm Versions 🦋

for npm v6 and earlier, scripts were generally run from the root of the package, but there were rare cases and bugs in older versions where this was not guaranteed. if your package must support very old npm versions, you may wish to add a safeguard in your scripts (for example, by checking process.cwd()). 🧚

for more details, see:

• npm v7 release notes — https://github.com/npm/cli/releases/tag/v7.0.0
• discussion about script working directory reliability in npm v6 and earlier — https://github.com/npm/npm/issues/12356

---

💜 Environment 💜

package scripts run in an environment where many pieces of information are made available regarding the setup of npm and the current state of the process. so much lore. 📚

🌸 path 🌸

if you depend on modules that define executable scripts, like test suites, then those executables will be added to the PATH for executing the scripts. so, if your package.json has this:

{
  "name" : "foo",
  "dependencies" : {
    "bar" : "0.1.x"
  },
  "scripts": {
    "start" : "bar ./test"
  }
}

then you could run npm start to execute the bar script, which is exported into the node_modules/.bin directory on npm install. ✨

🌈 package.json vars 🌈

npm sets the following environment variables from the package.json:

• npm_package_name — The package name
• npm_package_version — The package version
• npm_package_bin_* — Each executable defined in the bin field
• npm_package_engines_* — Each engine defined in the engines field
• npm_package_config_* — Each config value defined in the config field
• npm_package_json — The full path to the package.json file

additionally, for install scripts (preinstall, install, postinstall), npm sets these environment variables:

• npm_package_resolved — The resolved URL for the package
• npm_package_integrity — The integrity hash for the package
• npm_package_optional — Set to "true" if the package is optional
• npm_package_dev — Set to "true" if the package is a dev dependency
• npm_package_peer — gets set to "true" when the package is a peer dependency ✨
• npm_package_dev_optional — gets set to "true" when the package is both dev and optional 🫶

Okay so like, real example time: if you had {"name":"foo", "version":"1.2.5"} sitting in your package.json, then your package scripts would have the npm_package_name environment variable set to "foo", and npm_package_version set to "1.2.5". You grab those bad boys in your code with process.env.npm_package_name and process.env.npm_package_version. iykyk 💅

⚠️ bestie pls read this one: In npm 7 and later, most package.json fields are no longer provided as environment variables. Scripts that need access to other package.json fields should read the package.json file directly. The npm_package_json environment variable provides the path to the file for this purpose. no cap, this trips people up constantly 😭

See package.json ⟨/configuring-npm/package-json⟩ for more on package configs. 📄

---

🎀 versioning variables 🎀

For versioning scripts (preversion, version, postversion), npm sets these environment variables for you:

• npm_old_version — the version before being bumped 🕰️
• npm_new_version — the version after being bumped ✨

---

🦋 current lifecycle event 🦋

Lastly, the npm_lifecycle_event environment variable is set to whichever stage of the cycle is being executed. So you could have a single script used for different parts of the process which switches based on what's currently happening — one script, many moods, main character energy fr fr 👑

Objects are flattened following this format, so if you had {"scripts":{"install":"foo.js"}} in your package.json, then you'd see this in the script:

process.env.npm_package_scripts_install === "foo.js"

---

🌸 Examples 🌸

For example, if your package.json contains this:

{
  "scripts" : {
    "prepare" : "scripts/build.js",
    "test" : "scripts/test.js"
  }
}

then scripts/build.js will be called for the prepare stage of the lifecycle, and you can check the npm_lifecycle_event environment variable if your script needs to behave differently in different contexts. obsessed with a script that knows what's going on tbh 💖

If you want to run build commands, you can do so. This works just fine:

{
  "scripts" : {
    "prepare" : "npm run build",
    "build" : "tsc",
    "test" : "jest"
  }
}

---

🔥 Exiting 🔥

Scripts are run by passing the line as a script argument to /bin/sh on POSIX systems or cmd.exe on Windows. You can control which shell is used by setting the script-shell ⟨/using-npm/config#script-shell⟩ configuration option. pick your fighter 🐚

If the script exits with a code other than 0, then this will abort the process. like, hard stop, no survivors 💀

Note that these script files don't have to be Node.js or even JavaScript programs. They just have to be some kind of executable file. go off, bash script, we love a versatile icon 🌈

---

👑 Best Practices 👑

• Don't exit with a non-zero error code unless you really mean it. If the failure is minor or only will prevent some optional features, then it's better to just print a warning and exit successfully. be dramatic in your logs, not your exit codes 😌
• Try not to use scripts to do what npm can do for you. Read through package.json ⟨/configuring-npm/package-json⟩ to see all the things that you can specify and enable by simply describing your package appropriately. In general, this will lead to a more robust and consistent state. let npm cook 🍓
• Inspect the env to determine where to put things. For instance, if the NPM_CONFIG_BINROOT environment variable is set to /home/user/bin, then don't try to install executables into /usr/local/bin. The user probably set it up that way for a reason. respect the user's choices fr fr 🫶
• Don't prefix your script commands with "sudo". If root permissions are required for some reason, then it'll fail with that error, and the user will sudo the npm command in question. that's their moment, not yours 💅
• Don't use install. Use a .gyp file for compilation, and prepare for anything else. You should almost never have to explicitly set a preinstall or install script. If you are doing this, please consider if there is another option. The only valid use of install or preinstall scripts is for compilation which must be done on the target architecture. like genuinely, that's the only one 🙈

---

💜 See Also 💜

• npm help run
• package.json ⟨/configuring-npm/package-json⟩
• npm help developers
• npm help install

---

aaaand that's the whole page bestie, you made it 🎉 go forth and script responsibly. this chaotic little masterpiece is from npm 11.17.0, dated June 2026, section SCRIPTS(7) — slay, bye! 💖✨🎀