Master efficient dependency management with pnpm through hands-on guides covering global content-addressable storage, strict non-hoisted node_modules, workspace monorepos, script execution, and migration strategies.
Every JavaScript package manager before pnpm solved the same problem in the same way: download packages, copy them into a node_modules folder, and repeat for every project. pnpm discards the copying entirely. It stores every file of every package exactly once on your disk in a global content-addressable store, then constructs a node_modules directory out…
The conventional wisdom around pnpm installation has shifted significantly. Corepack, once the recommended path, is now considered outdated by the pnpm maintainers themselves, with the standalone script emerging as the preferred method. This chapter covers both approaches, the reasons for the shift, and the version-pinning mechanism that makes pnpm installations reproducible across machines and CI…
The pnpm init command is the entry point for every new project, but its behavior has evolved significantly in pnpm 10. The default module system is now ESM (“type”: “module”), a –bare flag strips the manifest down to only required fields, and version pinning is handled through the devEngines.packageManager field rather than the older packageManager…
The previous chapter established that pnpm stores packages once and links them into your project. This chapter explains the mechanism: the .pnpm virtual store and the two types of links that connect it to the rest of the filesystem. An understanding of this architecture is not academic. It explains why pnpm installs are fast, why…
The daily rhythm of package management is a three-command cycle: add what you need, update what has changed, and remove what is no longer used. pnpm’s commands for these operations follow a consistent pattern: they modify package.json, resolve the change into pnpm-lock.yaml, and update the virtual store and symlinks in node_modules. The critical difference from…