Package manager commands

Every common package-manager task side by side across npm, Yarn, pnpm and Bun, with your package name filled in. Marks where Yarn 1 differs and where there is no equivalent.

Runs in your browser

Package name

Script name

Task	npm	yarn	pnpm	bun
Install everything in the lockfile
Install for CI, failing if the lockfile would change		Yarn 1 (Classic):
Add a dependency
Add a dev dependency
Add without a version range
Install globally		no equivalent Yarn 1 (Classic):
Remove a dependency
Update within the declared ranges		Yarn 1 (Classic):
List packages behind their latest		Yarn 1 (Classic):
Run a script from package.json
Run a package binary without installing it
Start a new package
Explain why a package is installed
Check dependencies for advisories		Yarn 1 (Classic):
Add a dependency to one workspace

Yarn columns are Yarn 2+ (Berry). Where Yarn 1 differs, it is shown underneath.

Four managers, one job, four spellings

Nothing here is hard to remember. It is hard to remember four times, which is what happens when you work on a project that uses pnpm, contribute to one on Yarn, and read a README written for npm.

Type a package name in the box and every command in the table fills in. Click any of them to copy it.

Two places the usual cheat sheet is wrong

`yarn` means two different tools

Yarn 1 (Classic) and Yarn 2+ (Berry) are not the same program, and they differ on exactly the commands people look up:

Task	Yarn 1	Yarn 2+
CI install	`yarn install --frozen-lockfile`	`yarn install --immutable`
Upgrade	`yarn upgrade`	`yarn up`
See what is behind	`yarn outdated`	`yarn upgrade-interactive`
Audit	`yarn audit`	`yarn npm audit`
Run without installing	no equivalent	`yarn dlx`

The table above shows Berry, because that is what corepack enable gives you and what a packageManager field in package.json will pin. Where Yarn 1 differs, it is shown underneath.

Sometimes there is no equivalent

Yarn 2+ has no global install. yarn global add was removed and deliberately not replaced; the maintainers’ position is that a global install is a project’s dependency escaping its project. yarn dlx is not a substitute — it downloads, runs once and throws away.

The table says “no equivalent” rather than showing the nearest-looking command. A cheat sheet that guesses is worse than one that admits a gap.

The ones that actually differ in behaviour

Most rows are the same operation spelled differently. Three are not:

npm ci deletes node_modules first. The others do not. pnpm install --frozen-lockfile and yarn install --immutable fail if the lockfile would change, which is the property CI wants, but they reuse what is already there.
npm run <script> needs the run. yarn build and pnpm build work directly, and so does npm build — except npm build is a different, deprecated command, not your script. bun run <script> needs the run too, because bun <file> executes a file.
npx will install from the registry if it has to. So will pnpm dlx and bunx. In Yarn 1, yarn <bin> only reaches binaries already in node_modules, which is why the row has no Classic entry.

Lockfiles do not convert

Switching a project is not a matter of translating commands. Each manager writes its own lockfile — package-lock.json, yarn.lock, pnpm-lock.yaml, bun.lock — and none of them reads another’s. A migration means deleting the old lockfile, installing fresh, and checking that the resolved versions are the ones you expected.

Commit exactly one lockfile. Two in a repository is how a project ends up with two different dependency trees depending on who ran which command.

If you only need one pair, npm to Yarn and npm to pnpm show the same table with two columns.

Nothing you type goes anywhere. The table is in the page, and the substitution runs in your browser.