npm vs pnpm vs yarn — which package manager to pick as a beginner

npm, pnpm, yarn — three tools, and a beginner thinks they're choosing between three different package stores. They're not.

Here's the surprise: all three install the same packages from the same registry. Your react will be byte-for-byte identical whichever you pick. The difference isn't what they install, but how they store it on your disk — and that's where pnpm saves you gigabytes.

The main thing: all three install the same stuff

All three are package managers for Node.js. They read your package.json, download dependencies from the public npm registry, and lay them out in a node_modules folder.

The registry is one and the same. So "which one installs packages better" is the wrong question — they install identically. The right one is "how do they do it, and what's convenient for you."

The honest table: npm, pnpm, yarn

| criterion | npm | pnpm | yarn | |-----------|-----|------|------| | Install separately | No, ships with Node | Yes (or corepack) | Yes (or corepack) | | Speed | Fine | Usually fastest | Fast | | Disk space | A copy per project | One shared store | A copy (classic) | | Strictness | Loose | Only declared packages | Loose (classic) | | Who for | Default, "just works" | Save space, monorepos | Projects already on it |

npm — the default you already have

npm arrives with Node.js — nothing to install. There's a separate piece on it — what npm is. The commands you already know: npm install, npm run.

Plus: it's already here, all the documentation in the world defaults to it, zero setup.

Minus: each project keeps its own full copy of node_modules. Ten projects with React — ten copies of React on disk. npm used to be noticeably slower too, but recent versions have caught up.

pnpm — saves space and is stricter

pnpm's trick is one word: store. It keeps each version of a package once in a shared store on disk, and puts not copies into projects but hard links to that store.

The result: ten projects with React share one physical copy. On a disk full of projects that's real gigabytes saved. And it's usually faster — nothing to copy, just link.

The second plus is strictness. pnpm won't let your code use a package you didn't list in package.json, even if it happened to end up in node_modules. That catches bugs npm only surfaces in production.

Minus: you have to install it (or enable it via corepack), and the strictness sometimes complains about sloppily built old packages.

yarn — the historical speed-up, now a niche

yarn appeared in 2016, when npm was slow and unpredictable. yarn fixed that and was a clear upgrade. Since then npm caught up, and pnpm passed it on saving space.

Classic yarn (v1) today is "it works, fine" on old projects. New yarn (v2+) went off into its own storage scheme — powerful, but with a learning curve that's overkill for a beginner. There's no particular reason to pick yarn from scratch now, other than "this project is already on it."

Who should pick what

No hedging:

• Just starting, one project — take npm. It's already installed, all the docs are for it, nothing to think about.
• Several projects or a monorepo, disk space hurts — install pnpm. The shared store and strictness pay off fast. (KODiQ's admin is built on it, by the way.)
• Joined a project already on yarn — stay on yarn. Switching managers mid-project is risk for zero gain.

The main rule: one manager per project. Don't mix.

Can I use different managers in one project?

No, pick one. Each has its own lockfile (package-lock.json, pnpm-lock.yaml, yarn.lock) that pins exact versions. Two managers means two conflicting locks and the classic "works on mine, not on yours." One project — one manager and one lockfile in the repo.

Do I have to switch from npm to pnpm?

No. npm works great, and for a single project the difference is barely noticeable. The switch makes sense when you have many projects and space or speed start to annoy you, or when you set up a monorepo. No pain — no reason to change.