pnpm
Approving build scripts, running one-off tools, and pinning the version so everyone installs the same way.
"Ignored build scripts"
Since pnpm 10, dependencies can't run postinstall scripts unless you allow
them. A fresh install can stop with:
[ERR_PNPM_IGNORED_BUILDS] Ignored build scripts: esbuild@0.28.2
Run "pnpm approve-builds" to pick which dependencies should be allowed to run scripts.This is a security feature: a compromised package can't run code on your
machine just by being installed. But some packages need their script.
esbuild and sharp download a native binary for your platform, and without
it they fail later with a much less clear error.
Allow them by name in pnpm-workspace.yaml:
allowBuilds:
esbuild: true
sharp: trueThen run pnpm install again. pnpm approve-builds does the same thing
interactively.
Only allow what you recognise
Approve a package because you know why it needs a build step (native binaries, mostly), not just to make the error go away.
Pin the version
{
"packageManager": "pnpm@11.18.0"
}With Corepack, everyone on the project (and Vercel) uses exactly this version. Different pnpm versions can write different lockfiles, which shows up as a noisy diff in every pull request.
One-off tools with pnpm dlx
pnpm dlx runs a package without adding it to the project, like npx:
pnpm dlx create-fumadocs-app@latest
pnpm dlx ultracite fixPin @latest (or a version) for scaffolders, so a cached old version doesn't
generate an outdated project.
Everyday commands
| Task | Command |
|---|---|
| Install from the lockfile | pnpm install |
| Add a dependency | pnpm add <pkg> |
| Add a dev dependency | pnpm add -D <pkg> |
| Remove a dependency | pnpm remove <pkg> |
| See what's outdated | pnpm outdated |
| Update within ranges | pnpm update |
| Why is this installed? | pnpm why <pkg> |
Last updated on