Lifecycle scripts are commands a package declares that npm runs automatically at set points, such as preinstall, install and postinstall. That means installing a dependency can execute code on your machine before you ever import it. New developers should know this, because it is how an install can do more than copy files.
Which scripts run when
The npm scripts documentation includes a table of lifecycle operations. For npm ci and npm install, the order includes preinstall, install, postinstall, then prepublish, preprepare, prepare and postprepare. The docs say these run after the actual installation of modules into node_modules, in order. The page also notes that if a binding.gyp file exists in a package and no install script is defined, npm has default behavior for native builds, which is why some packages compile code during install.
The key point: these scripts belong to the packages being installed, not only to your project. Your direct dependencies and their transitive dependencies can all declare them.
Why it matters
Running a script on install gives code the same access you have: your files, your environment variables, your credentials in the shell. Most scripts are harmless build steps. A malicious one gets a head start before any review of the library code, because install happens first.
That is why the practice of reviewing a new dependency should include the question: does it run anything at install time?
What you can do
- Check before adding. Open the package's package.json and look for a scripts block with install-related keys.
- Prefer fewer packages that run scripts. When two options are equal, choose the one that does not need them.
- Know the switch. npm has an ignore-scripts configuration option, listed among the options for commands such as npm prune. Ask your team whether it is set in CI or in the project .npmrc, and what breaks when it is on, since some packages need their build step.
- Do development in a place with fewer secrets. Do not keep long-lived cloud credentials in your default shell if you can avoid it.
- Review lockfile changes. A new package in the lockfile is a new place scripts can come from.
Be honest about the limit: turning scripts off does not make a package safe, since malicious code can also run at import time. Our post on import-time malware and ignore-scripts explains why.
A short team rule
Write a one-line rule in your onboarding doc, such as: new dependencies that declare install scripts get a second reviewer. It is cheap, and it puts the question in front of the right person at the right time.
Where Safeguard fits
Safeguard can do the inventory and watching for you. Its SBOM and dependency scanning lists what a repository actually pulls in, reachability analysis helps separate reachable findings from noise, and policies can gate a pull request. You can try a free scan on a repository to see the output.
Quick check
Do devDependencies run install scripts too?
Packages installed as dev dependencies are installed too, so their scripts can run on developer machines and in CI. Treat them with the same care.
Is it enough to read the package's README?
No. The README describes intent. Read the package.json scripts and, for sensitive cases, the script files they call.
Sources
Last reviewed: 19 October 2026.
