pnpm

What is it

pnpm is a fast, disk space efficient package manager for JavaScript. It uses a content-addressable filesystem to store all files from all package versions on disk, then uses hard links to reference them. This means you never duplicate the same file across different packages—if 50 packages depend on the same version of lodash, that version is stored once.

My Opinion

The node_modules problem has haunted the JavaScript ecosystem for over a decade. npm and yarn both tried to solve it with nested directories, leading to absurd disk usage and install times. pnpm solved it properly by understanding that files are content, not paths. It’s the package manager npm should have been.

The Hard Link Magic

Hard links are the secret sauce. When you have 50 packages that all depend on lodash@4.17.21, pnpm stores the files once in a global content-addressable store and creates 50 references to them. The disk savings are massive—often 70-80% reduction in node_modules size compared to npm.

For Astro projects like this blog, pnpm keeps the development environment lean.

The “Symlink” Myth

The biggest barrier to adoption is fear of symlinks breaking tools. In my experience, this is 2026, not 2015. Modern build tools handle symlinks just fine. Vite, webpack, esbuild—they all work perfectly with pnpm’s symlink structure.

The only real issue is with older plugins that manually traverse node_modules instead of using proper resolution. Those should be retired anyway.

The Monorepo Sweet Spot

pnpm shines brightest in monorepos. The workspace support is first-class, not an afterthought like npm’s workspaces. When you have 20+ packages sharing dependencies, the hard link architecture means your install times are basically instantaneous.

For large-scale projects with multiple Astro sites or shared component libraries, pnpm’s workspace features are essential.

The Strictness Advantage

pnpm enforces stricter dependency resolution than npm. You can’t accidentally import a package that’s only a transitive dependency—if you use it, you must declare it. This catches “phantom dependency” bugs that would otherwise only appear in production.

Some developers find this annoying. I find it correct.

The Compatibility Paradox

The only reason pnpm isn’t the market standard is npm won by default. It’s bundled with Node.js, so that’s what everyone uses. But switching to pnpm is trivial: npm install -g pnpm, then pnpm install. There’s no lockfile migration drama—pnpm can read package-lock.json files.

Conclusion

pnpm is the objectively better package manager. It’s faster, uses less disk space, handles monorepos better, and enforces stricter dependency hygiene. There is no good reason to still be using npm in 2026. The migration is painless—try it on your next project.