Package Manager Detection: Why I Lock It Down in My Projects

I spent two hours debugging a CI pipeline last week because someone ran npm install on a pnpm project. Two hours. The lockfile was corrupted, builds failed, and nobody knew why until we checked git history.

This isn't rare. It happens constantly, especially in teams or open source where contributors use whatever they're comfortable with.

The Real Problem

Yarn, pnpm, npm, Yarn Berry—they all claim to be compatible, but they're not. Not really. A package-lock.json and a pnpm-lock.yaml are fundamentally different beasts. Mix them, and you get mysterious failures that have nothing to do with your actual code.

I used to rely on checking for lockfile presence. Does pnpm-lock.yaml exist? Use pnpm. Simple, right? Wrong. People commit .npmrc files but not lockfiles. They use pnpm locally but CI runs npm. It's chaos.

What I Do Now

I explicitly define it. In every project—Seven CMS, Seven Suite, Seven Shop—I lock it down in package.json:

"packageManager": "[email protected]"

Node 16.13+ respects this. If someone runs npm install, they get a hard error. Not a warning. An error. They have to use pnpm.

For the Seven Suite (NestJS backend), this saved us during onboarding. New developers couldn't accidentally break the workspace. The constraint was clear from day one.

The Fallback

Not everyone is on Node 16+. Some legacy projects I maintain still run on older versions. For those, I add a pre-install hook that explicitly checks and fails if the wrong manager is used. It's not elegant, but it works.

if [ "${npm_execpath#*pnpm}" != "${npm_execpath}" ]; then
  exit 0
else
  echo "Use pnpm, not npm"
  exit 1
fi

Why This Matters

I care about two things: consistency and friction. A lockfile mismatch introduces exactly zero value but infinite debugging. By making the choice explicit and enforced, I remove a whole class of bugs before they start.

For open source especially, this matters. Contributors shouldn't have to guess. The tool should tell them what to do.

Stop being permissive about package managers. It's not friendly—it's confusing.