Package manager
PAK-ij MAN-uh-jer
A tool that automates installing, updating, and removing software dependencies for a project.
A package manager handles the logistics of dependencies. You tell it what you need, and it downloads the right version, resolves conflicts between packages, and puts everything in the right place. npm does this for JavaScript. pip for Python. Cargo for Rust. Maven for Java. Without a package manager, you would be downloading zip files from websites and copying them into your project manually.
The package manager does more than just download files. It resolves the dependency graph. If package A needs package B version 2.x, and package C needs package B version 3.x, the package manager figures out what to do. Sometimes it installs both versions. Sometimes it tells you there is a conflict. This resolution is the hard part, and it is why package managers exist.
The JavaScript ecosystem has three major package managers: npm (the default, comes with Node.js), Yarn (created by Facebook to fix npm's speed and reliability issues), and pnpm (which saves disk space by linking to a shared store). All three read package.json and produce a lockfile. For most projects, npm works fine. Teams with large monorepos often prefer pnpm or Yarn for performance.
Examples
A developer sets up a new project.
The developer runs 'npm init' to create a package.json, then 'npm install next react react-dom typescript' to add the core dependencies. npm downloads the packages, creates node_modules with 287 packages (including transitive dependencies), and generates package-lock.json. The developer commits package.json and package-lock.json to Git. Another developer clones the repo and runs 'npm install' to get the exact same dependency tree.
A team migrates from npm to pnpm for performance.
The monorepo has 12 packages. Running 'npm install' takes 4 minutes and uses 2.3 GB of disk space because node_modules is duplicated in each package. The team switches to pnpm, which uses a content-addressable store: each version of each package exists once on disk, and packages are hard-linked. Install time drops to 40 seconds. Disk usage drops to 800 MB. CI build times improve by 3 minutes per run.
A dependency conflict causes a build failure.
The project depends on library A (which needs React 17) and library B (which needs React 18). npm installs React 18 because it is newer, but library A breaks at runtime because of incompatible API changes in React 18. The developer checks library A's release page, finds a new version that supports React 18, upgrades, and the conflict is resolved. The lockfile is updated to reflect the resolution.
In practice
Read more on the blog
Frequently asked questions
Should I use npm, Yarn, or pnpm?
For most projects, npm is fine. It comes with Node.js, has the largest ecosystem, and has improved significantly in speed and reliability since version 7. Use pnpm if you have a monorepo or care about disk space and install speed. Use Yarn if your team already uses it or you need Yarn-specific features like Plug'n'Play. The most important thing is to pick one and use it consistently across the team. Mixing package managers in one project causes lockfile conflicts and inconsistent installs.
What is the difference between package.json and the lockfile?
package.json lists your direct dependencies with version ranges ('react': '^18.2.0'). The lockfile (package-lock.json, yarn.lock, pnpm-lock.yaml) records the exact version of every direct and transitive dependency that was actually installed. package.json says 'I need React 18.2 or higher.' The lockfile says 'I installed React 18.2.0 specifically, along with these 200 other packages at these exact versions.' Always commit the lockfile. It ensures everyone gets the same versions.
Related terms
An external library or package that your project requires to function.
A versioning scheme using MAJOR.MINOR.PATCH numbers to communicate the type of changes in each release.
A single repository that contains multiple projects, packages, or services managed together.
The process of compiling source code into a runnable application or deployable artifact.
Software whose source code is publicly available for anyone to view, use, modify, and distribute.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.