npm, pnpm and Yarn
You open a new project and find pnpm-lock.yaml instead of package-lock.json. Another uses yarn.lock. These are not different ecosystems. They are three package managers installing from the same registry into the same kind of project, and switching between them is mostly a matter of reading which lockfile is present.
The rule
Same registry, same package.json; the lockfile tells you which manager to use.
All three read package.json, download packages from the npm registry and run the same scripts. They differ in how they store packages on disk and in a few commands.
| npm | pnpm | Yarn | |
|---|---|---|---|
| Comes with | Node.js | a separate install | a separate install |
| Lockfile | package-lock.json |
pnpm-lock.yaml |
yarn.lock |
| Install everything | npm install |
pnpm install |
yarn |
| Add a package | npm install date-fns |
pnpm add date-fns |
yarn add date-fns |
| Add a dev package | npm install -D vite |
pnpm add -D vite |
yarn add -D vite |
| Run a script | npm run dev |
pnpm dev |
yarn dev |
| Run a tool once | npx |
pnpm dlx |
yarn dlx |
npm is the default: always available wherever Node.js is, and perfectly fine for most projects.
pnpm keeps a single copy of each package version in one global store on your computer and links projects to it. Ten projects using the same library share one copy on disk, and installs are often faster. Its node_modules is also stricter: your code can only import packages you actually listed, which catches missing dependencies that npm would quietly allow.
Yarn was created when npm was slower and less predictable, and it introduced ideas npm later adopted, such as lockfiles and workspaces. Modern Yarn versions also offer a mode that skips node_modules entirely.
One project, one manager. Mixing managers in the same project creates two lockfiles that disagree, and installs stop being predictable. Many projects record their choice in package.json:
{
"packageManager": "pnpm@9.12.0"
}Node's Corepack tool can read that field and use the matching manager version automatically.
The shortcut
When you open any project, look for the lockfile first and use the manager it belongs to. Starting a brand-new project? npm is the safe default; pnpm is a good choice when you have many projects or want its stricter checks.
Look for the lockfile
The repository root contains
pnpm-lock.yaml, so this project uses pnpm.
The trap is running npm install in a pnpm project out of habit. It ignores pnpm-lock.yaml, picks versions from the ranges and writes a second lockfile, package-lock.json, that nobody else uses.
Drills
Answer fast — trust the rule.
A project contains yarn.lock. Which command installs its dependencies?
Where do npm, pnpm and Yarn download packages from by default?
What is a main idea behind pnpm's design?
A teammate runs npm install in a project that uses pnpm. What goes wrong?
Remember
- Same registry, same
package.json; the lockfile tells you which manager to use. - Look for the lockfile first; npm is the safe default for new projects.
- Trap: mixing managers creates two lockfiles and unpredictable installs.