If you've been living under a rock, the JavaScript package manager ecosystem is no longer "npm or nothing". Yarn hit 1.0 in 2016. pnpm launched in 2016 and quietly out-engineered everyone. Bun's package manager arrived in 2023 and made noise about being 2–3× faster. The question isn't "which one is best" anymore—it's "which one fits YOUR deploy target, your disk budget, and your tolerance for ecosystem risk".
Velocity X uses pnpm. Not because it's the newest shiny. Because it solves three concrete problems that matter at scale: disk space, phantom dependencies, and Netlify support.
The Package Manager Hierarchy
npm came first (2010). It's synchronous, duplicates dependencies in nested folders, wastes disk space, but works everywhere. You have 100 projects? Each has its own node_modules/ copy of react, lodash, zod. Disk cost adds up fast.
Yarn (2016) fixed duplication with a flat node_modules layout and a lockfile (yarn.lock) that actually worked. Good. But it's still copying packages, not linking them.
pnpm (2016) went further: content-addressable store. Every version of every package lives once. Hard links in node_modules/ point back to that store. Same package across 50 projects? Counted once. A monorepo with 10 apps all using React 19? 1 disk read, 10 hard links. That's the difference between a 200GB and 40GB home directory.
Bun (2023) says: "We'll do package management in Rust, skip npm's entire architecture, and make install 2–3× faster." True. But it also says: "We'll build our own ecosystem", which is code for "you're now on a fork".
pnpm Wins: Three Reasons Velocity X Chose It
1. Disk Space (Content-Addressable Store)
Velocity X has 180+ dependencies (react, next.js, zustand, zod, supabase, shadcn/ui, etc.). An npm node_modules/ folder for a typical Velocity clone hits 800MB. A monorepo with 3 apps? 2.4GB. On a MacBook with 256GB SSD, that's painful.
pnpm's store solves this. Every package version is stored once globally. node_modules/ is just a set of hard links pointing to the store. Same 180 dependencies? 250MB, maybe 300MB with the store overhead. For developers spinning up 5–10 Velocity forks (each a potential client brand), that's the difference between manageable and "my drive is full, I can't work".
2. Stricter Dependency Resolution (Catches Phantom Deps)
npm's flattening algorithm has a weakness: you can accidentally import a transitive dependency that isn't listed in YOUR package.json. Your code does import axios from 'axios', but axios isn't YOUR dependency—it's a transitive from something else. npm flattens it into the top level anyway, and your code works locally. Then your CI server has a different node_modules structure, and it breaks at deploy.
pnpm uses strict isolation. A package can only import what it explicitly lists. Transitive dependencies stay in their own trees. Your code will error if you're sneaking in a phantom dependency. That's annoying during development. It's saved during deploy.
3. Native Netlify Support
Netlify's build image (Ubuntu, Node 20+) ships with npm and pnpm pre-installed. No custom build setup required. Bun? You'd need to install it in the build step, adding 30–60 seconds to every deploy. With 20+ deploys a week per project, that adds up. pnpm: pnpm install && pnpm build, that's it.
npm: Still Acceptable (Just Not Ideal)
npm 10 (2024) added some of pnpm's ideas: better lockfile stability, faster resolver. If you're on npm 10+, it's acceptable. Not great for disk space. Not strict about phantom deps. But it works, and everyone knows it.
Use npm if: you're on a team where half the devs have no idea what "content-addressable store" means and you need zero friction. It's the path of least resistance, and sometimes that's worth the disk cost.
Bun's Package Manager: The Hype Check
Bun's pm is fast. bun install on a cold cache can be 30–50% faster than pnpm in real-world projects. If you're installing 200+ dependencies from scratch every single day (you're not), that matters. If you're doing one bun install per project per week, you'll never notice the difference.
The catch: Bun's ecosystem is younger. If a package has a post-install script that assumes npm, you're debugging. If a build tool has a Bun quirk, you're on GitHub Issues instead of shipping. For Velocity clients who are paying for a working product, not a beta testing environment, Bun is still risky.
Use Bun's package manager if: you're running a monorepo with 500+ dependencies across 20 apps where cold-cache installs happen daily, and you have someone on the team who understands Bun internals. That's not most teams.
The Trade-Off Matrix
Disk usage: npm (bad) > yarn (ok) > pnpm (best) > bun (best, but risky). Speed: bun > pnpm > yarn > npm. Ecosystem maturity: npm > yarn > pnpm > bun. Netlify native support: pnpm + npm > bun > yarn.
For Velocity X in 2026, pnpm hits the sweet spot: disk-efficient, stable, Netlify-native, mature ecosystem, and strict enough to catch mistakes before deploy. Bun is still the "interesting runtime choice", not the "boring, reliable package manager choice".
How to Switch (If You're Still on npm)
1. Install: npm install -g pnpm
2. In your project: pnpm import (converts package-lock.json to pnpm-lock.yaml)
3. Delete node_modules/ and package-lock.json: rm -rf node_modules && rm package-lock.json
4. Install: pnpm install
If a package breaks, you've probably hit a phantom dep. Check your imports, remove the ghost dependency from code, and you're done. Annoying? Yes. But better to find it now than in production.
The Bottom Line
Velocity X uses pnpm because disk matters, strict resolution matters, and Netlify maturity matters. Bun is fun; pnpm is pragmatic. If you're managing multiple client brands, a MacBook with a finite SSD, and a CI pipeline that needs to be bulletproof, pnpm is the answer. npm is fine if you don't care about wasting 500MB per project. Bun is the future—once AWS and the major package hosts have fully tested it against the whole ecosystem. Today? pnpm wins.
Want to explore more about making pragmatic tech choices for production? Check out the Velocity X pricing page to see how these choices scale. And if you're curious about runtime choices (not just package managers), read our deep dive on Bun vs Node in 2026—same pragmatism, different layer.