pnpm's three load-bearing concepts are the content-addressable store, the strict nested node_modules, and first-class workspaces. Together they justify the migration from npm.
Content-addressable store. Every package version, identified by SHA256, lives once at ~/.pnpm-store/. When pnpm installs a package into a project's node_modules, it creates a hard link from the project to the store — not a copy. Hard links share inode-level disk; the file is physically the same on disk but reachable from many paths. The result: 50-70% less disk used overall, plus dramatically faster installs because the bytes are already there.
Strict nested node_modules. Each package's dependencies are nested under its own node_modules subfolder, and only packages explicitly declared in package.json are hoisted to the project root. That means your code can only import packages you've declared — no phantom deps. If your code says import x from 'lodash' but you haven't pnpm add lodash'd it, it fails immediately. The strictness is a feature.
Workspaces. pnpm has best-in-class monorepo support. pnpm-workspace.yaml at the repo root declares which sub-packages exist. pnpm install at the root installs deps for all of them, sharing common deps via the store. pnpm -r build runs a script across every workspace package; pnpm --filter web dev runs only in the named package. Combined with the store, large monorepos install dramatically faster than with npm.