Bun 2.0 Ships With Native Package Manager, Breaks Module Resolution

Bun 2.0 is out, and the headline change is structural: the runtime now ships a native package manager intended to replace npm in day-to-day workflows, paired with a revised module resolution algorithm that introduces breaking changes for existing projects.

The package manager has lived inside Bun since early releases as bun install, but 2.0 positions it as the primary dependency tool rather than a faster drop-in for npm. The pitch is the same one Bun has made since launch: a single binary that handles installing, running, bundling, and testing, removing the need to stitch together npm, a bundler, and a test runner. With 2.0, the install path is no longer treated as an optional accelerator sitting on top of the npm ecosystem. It is the default the rest of the toolchain assumes.

The breaking change

The migration cost lands in module resolution. Bun 2.0 changes how it walks the dependency tree and resolves imports, which means projects that relied on resolution quirks of earlier versions, or on Node's exact resolution behavior, can break in ways that are not always obvious at install time. Symptoms tend to surface at runtime: an import that previously resolved to one copy of a package now resolves to another, or a conditional export that worked under the old algorithm no longer matches.

The class of bug this produces is familiar to anyone who has migrated a monorepo between package managers. Hoisting behavior, peer dependency resolution, and the handling of exports and imports fields in package.json are exactly the surfaces where tools diverge, and exactly where a resolution change shows up as a phantom dependency or a duplicated module in the graph.

For teams running Bun in CI but Node in production, or the reverse, the resolution divergence matters more than for teams that have standardized on Bun end to end. A dependency tree that resolves cleanly under Bun 2.0 but differently under node --experimental or under a Node-based build step is the kind of mismatch that passes local checks and fails somewhere downstream.

What the migration looks like

The practical path for most projects is to delete the existing lockfile and node_modules, reinstall under 2.0, and diff what the new resolution produces against what was running before. Projects with a flat dependency surface and few peer dependency constraints will likely see no behavioral change. Monorepos with workspaces, packages that ship conditional exports, and anything depending on a specific hoisting layout are where the work concentrates.

The trade-off Bun is making is the standard one for a tool that wants to own its ecosystem rather than mirror an incumbent. Strict adherence to Node's resolution semantics constrains what a runtime can optimize; diverging lets Bun control the install layout and resolution path end to end, which is where its install-speed claims come from. The cost is that compatibility with Node is no longer a guarantee at the resolution layer, it is a best-effort target.

Adoption context

Bun's value proposition has always been throughput on the parts of the workflow developers hit constantly: cold install, test startup, and script execution. Those are the places where a faster runtime translates into shorter CI times and faster local iteration, and they are the reason Bun has picked up usage in teams that started new projects rather than migrating existing Node services.

The 2.0 framing as a package-manager-first toolchain is a bet that those teams want to leave npm behind entirely rather than keep it as a fallback. For projects already running Bun as their runtime, consolidating onto its native installer removes a moving part. For projects using Bun only as a faster npm install, the resolution changes are a reason to test carefully before upgrading, because the thing that made Bun a safe drop-in, behaving like the tool it replaced, is precisely what 2.0 relaxes.

The upgrade is low-risk for greenfield work and worth staging for anything with a non-trivial dependency graph. The resolution change is the part to validate, not the package manager itself.