Use Bun

I’d won. After months of evangelizing, teams were finally using pnpm. No more npm’s bloated node_modules. No more phantom dependencies. Just clean, efficient package management with a global store and symlinks.

I was satisfied. All in on the pnpm train.

Then a friend glanced at my terminal during a screen share and said: “lol… use bun”

I rolled my eyes. Another JavaScript tool. Another migration headache. I’d just fought this battle.

Then I tried it. Within three days, I’d converted every single project I maintain.

The pnpm Honeymoon Was Over

Don’t get me wrong: pnpm was better than npm. 70% less disk space. Proper dependency isolation. Monorepo support that actually worked.

But there was friction. Constant, low-grade friction:

• Corepack confusion: Is it enabled? Which version? Did CI pick it up? Why does this work locally but not in GitHub Actions?
• Approve builds: That delightful moment when your build hangs waiting for approval to install a package.
• CI surprises: Random failures in environments where pnpm’s symlink strategy collided with Docker or deployment scripts.
• Verbose lockfile: pnpm-lock.yaml is technically reviewable, but good luck parsing thousands of lines of YAML in PR diffs.

None of it was dealbreaking. But it added up. I’d convinced myself this was just the cost of better tooling.

It’s fine. It’s just a little friction. It’s better than npm.

— Every pnpm user, probably

The Three-Day Conversion

I installed Bun expecting to kick the tires and move on. Instead, I found myself rage-converting every project.

Project 1 (this blog):

rm -rf node_modules pnpm-lock.yaml
bun install

Done. 3.4 seconds. No configuration. No corepack. No surprises.

Projects 2-10: Same story. Remove pnpm artifacts, run bun install, commit the text-based bun.lock. Every single one just worked.

No compatibility issues. No build failures. No “well actually” moments where I had to debug why a package expected npm’s structure.

What Bun Actually Gets Right

It’s boring in the best way:

• No setup complexity. curl -fsSL https://bun.sh/install | bash and you’re done.
• No corepack configuration. No version management dance.
• Text-based lockfile you can actually review in PRs.
• Works identically in local, CI, and production environments.

It’s more than a package manager:

• Runtime, bundler, test runner, and package manager in one binary.
• Written in Zig, not JavaScript. Fast at the system level, not through clever optimizations.
• Unified toolchain means fewer dependencies, fewer version conflicts, fewer moving parts.

It just works:

• Zero CI issues across multiple GitHub Actions workflows.
• No symlink surprises in Docker builds.
• No “this works on my machine” debugging sessions.

The Conventional Wisdom Is Wrong

Every comparison article positions it the same way:

• pnpm: Safe, mature, battle-tested. Choose this for production.
• Bun: Fast but risky. Watch out for edge cases and compatibility issues.

My experience has been the exact opposite.

Bun is the boring, reliable tool. pnpm was death by a thousand paper cuts.

The “battle-tested” narrative assumes that age equals stability. But pnpm’s design (symlinks + global store + verbose lockfile) creates friction. Bun’s design (just do the obvious thing, but fast) avoids it.

What I’d Tell Past Me

Don’t fight the pnpm battle. It’s not worth it.

Not because pnpm is bad. It’s genuinely better than npm. But you’re advocating for a tool that still has rough edges, and you’re going to spend months dealing with them.

Wait six months. Let Bun mature. Then skip straight to the tool that actually delivers on the promise: fast, simple, reliable package management that just works.

Lessons Learned

• “Battle-tested” can mean “accumulated complexity”: Maturity isn’t always an advantage. Sometimes it means legacy design decisions you inherit.
• Settling is expensive: I thought I’d found the right tool. I’d actually found the least-bad option given the alternatives. Bun changed the alternatives.
• Speed is a proxy for simplicity: Bun isn’t just faster because it’s written in Zig. It’s faster because it does less unnecessary work. That simplicity cascades into reliability.
• Listen to your friends: Even when they’re being flippant. “lol use bun” was the best technical advice I got all year.

Try It Yourself

If you’re on pnpm and hitting friction, try Bun for a week:

1. Pick a non-critical project
2. rm -rf node_modules pnpm-lock.yaml
3. bun install
4. Run your tests, your build, your deploy

If it breaks, you’ve lost an hour. If it works, you’ve found a better tool.

I’m betting it works.