The Problem With npm install (And How to Work Around It)

Node.js and npm turned 15 years old and are more dominant than ever. They're also carrying 15 years of accumulated design decisions, some of which cause regular frustration. Understanding the pain points lets you work around them rather than running into them repeatedly.

The Security Audit Issue

npm audit reports vulnerabilities in your dependencies. The problem: it reports all vulnerabilities, including ones that don't affect your usage. A cryptographic vulnerability in a module that your app uses only for formatting strings is not a meaningful risk. A dependency that has 47 vulnerabilities but is only used as a test framework doesn't need immediate production action. Read the audit output; don't just run npm audit fix blindly.

Lock Files and Reproducibility

package-lock.json exists so that npm install produces the same result every time. Without it, package versions drift over time as dependencies release new versions. Delete your lock file, run npm install, and you might get a different set of packages than your colleague installed a month ago. Always commit lock files, always run npm ci (not npm install) in CI/CD pipelines — ci respects the lock file exactly.

Checking What You Actually Installed

npm ls shows the full dependency tree. npm why [package] tells you why a package was installed (which other package depends on it). These are useful when you're auditing what's in your node_modules and trying to understand where something came from. For large projects, running npx cost-of-modules shows you the disk footprint of each dependency.

When to Consider pnpm

pnpm stores packages in a central location and uses hard links instead of copying files into each project's node_modules. The result: dramatically less disk usage, faster installs, and strict dependency resolution that prevents using packages that aren't explicitly declared. For monorepos or developers who work on many Node.js projects, the disk savings alone make pnpm worthwhile.