Bun support

Hi there,

I have no relation to the bun team at all (and, am a bit daft on web stuff). I'm looking to change to bun from pnpm for performance reasons, but there's no way to do this through the corepack system today (which has been very kind to me, for what it's worth).

It would be very nice if I could use the corepack mechanism to change to bun, similar to how (p)npm are implemented today from yarn.

https://github.com/oven-sh/bun
https://bun.sh/

It looks like they have a 1.0 mark coming on September 7th 2023.

bun is a replacement runtime for node, it's not a standalone package manager.

bun is a replacement runtime for node, it's not a standalone package manager.

I'm under the impression it is a package manager per https://bun.sh/docs/cli/install

I understand it may compete in areas, but the once corepack installs it, it (bun) runs the same way for a project that pnpm does.

it contains one, but there's no standalone "bun package manager" - it can't run inside node, so to use it you'd have to install the entirety of bun.

it contains one, but there's no standalone "bun package manager" - it can't run inside node, so to use it you'd have to install the entirety of bun.

I think it's just a single statically linked binary, no? I think what I'm looking for is for corepack to install the binary for me (similar to (p)npm) and that's it.

EDIT: I just read their docs, looks like it's installable through npm as well: npm install -g bun

Any update on this? 1.0 just came out the other day.

For reference, the meta-npm package managers (ni and ni.zsh) recognise bun as a package manager.
I think bun is an npm package manager because it has commands similar to most package managers and can handle npm packages.

Command Table

npm	yarn	yarn-berry	pnpm	bun
`npm install`	`yarn install`	`yarn install`	`pnpm install`	`bun install`
`npm install`	`yarn add`	`yarn add`	`pnpm add`	`bun add`
`npm uninstall`	`yarn remove`	`yarn remove`	`pnpm remove`	`bun remove`
`npm run`	`yarn run`	`yarn run`	`pnpm run`	`bun run`
`npm run test`	`yarn run test`	`yarn run test`	`pnpm run test`	`bun run test`
`npm upgrade`	`yarn upgrade`	`yarn up`	`pnpm update`	`bun update`
--	`yarn upgrade-interactive`	`yarn up -i`	`pnpm update -i`	--
`npm exec`	`yarn <command>`	`yarn exec`	`pnpm exec`	`bunx`
`npx`	--	`yarn dlx`	`pnpm dlx`	`bunx`

There is a desire to simply write "packageManager" : "bun@1.0.0" on package.json.

For a new package manager to be added, someone needs to open a PR adding it to the config.json, optionally update the automation so the config is updated automatically when new versions are released, and make sure all the tests pass.

[build-utils] Add zero config detection for bun package manager (#10486)

Looking forward to this, I'll try to do it myself next month (if not out yet)

We are using bun in several repos and it would be awesome to be able to specify it as the packageManager (and have that actually do something :) ).

Hey, you're that one SourceMod guy!

On topic, bun's website is littered with references to it being usable solely as a package manager:

https://bun.sh/package-manager

Compatibility with Node.js or Bun.
Bun's package manager is intended for use as a standalone tool, regardless of whether you're using the Bun runtime. It'll work in any project with a package.json, and it supports workspaces, git/http/tarball dependencies, custom registries, and more.

Out of curiosity, what is "adding bun" to Corepack supposed to mean? 🤔

Bun is a JavaScript runtime that also bundles itself a package manager but the package manager doesn't seem to be available standalone without the rest of the Bun runtime.

Apparently, Bun maintainers also explicitly asked to not have their binaries added to Corepack.

I assume this means we should not proceed with this.

(It would feel at the very least weird for Node.js as a JavaScript runtime to ship another runtime inside itself)

Yes, bun is a full runtime but it can be used as “just a package manager” while still running things on Node. It’s faster than npm, faster than yarn and faster than pnpm.

Corepack warns users that are trying to install dependencies with a different package manager that they are doing something wrong. For example, if I set pnpm through corepack, I can make it throw an error to users who try to install dependencies with yarn.

This won’t work when using bun as a package manager, because it’s not supported by corepack.

I genuinely don't think Bun should be part of Corepack. Unfortunately Corepack's own documentation doesn't have a concrete process or what "is a package manager"; albeit is also not up to me to decide what it is or not as I am not a Corepack contributor; Having that said, having Bun as a package manager within Node feels somewhat a conflict of interest, or at least so it does to me. But that's just my interpretation and it doesn't really matter.

What matters is that Bun maintainers opted on not wanting Bun yo be shipped by Node through Corepack and that's within their right to do, and pretty much within their rights of LICENSE; (We are having the same discussion regarding npm at the moment)

I definitely appreciate and believe Corepack should support more package managers, but I believe it should go with the caveats that the authors of such piece of software should agree with having their software binaries being shipped by a third party software.

This is just my interpretation of things, but genuinely I believe some sort of governance or requirements should be set in place of what should be allowed or not to be added within Corepack 🤔

The local project doesn't define a 'packageManager' field. Corepack will now add one

Except whatever it suggests is wrong : I'm using Bun. What to do now ?

The local project doesn't define a 'packageManager' field. Corepack will now add one

Except whatever it suggests is wrong : I'm using Bun. What to do now ?

Who exactly are you quoting here?

I really don't think anybody wants node to ship bun, only to enable corepack to check if it's being used if it is specified as the packageManager.

I think there is some utility in supporting bun install, due to it's speed compared to alternatives, and combine it with node runtime, such as where bun lacks compatibility. Examples are use of node:crypto or vitest, which bun doesn't fully support, so the fastest setup would here be bun install && node --run test

hi now that 1.3 is released, is there any discussion around adding bun solely as package manager?
https://github.com/nodejs/corepack/pull/307/files was closed as the person working priorities were changed.

If a testimonial is helpful, I've used bun only as a package manager with node as the runtime for a number of projects for over a year now. It is significantly faster than npm. It's definitely useful when used only as a package manager.

hi so i just decided to go all in and found some stuff and got this working till now
key issues i found and i dont know how to apporach:
bun binaries are relased based on system architecture + os
https://registry.npmjs.org/@oven/bun-linux-x64/latest
like this for macos windows exe etc
current corepack codebase expects all to be under a single npm registry with versions as diffrentiators
so the entire logic to add bun support shifts
as discussed in last pr to add it, the npmjs /bun is just a script that actually fetches the real binary all sha checksum matchs and then install.

i with help of copilot and all got it to work till here
all my code is at https://github.com/HimanshuKumarDutt094/corepack
i honestly dont know what to do from here, had to hack the entire package flow

fix: remove packageManager field from package.json

so the entire logic to add bun support shifts

Out of curiosity, why can't bun make the changes, instead of having to make changes on the corepack side? bun has chosen an operation that no other package manager uses.

Corepack was written with assumption that package managers would be implemented in JS (and more specifically, to run on Node.js), which was the case back then, which simplifies a lot the distribution (the same JS file can be distributed to every platform Corepack can run, Corepack itself being written in JS). Bun took a radical approach of start from scratch and use the native layer, and while it's much harder to distribute, the performance results are arguably much better; it's tradeoff they have chosen, we can agree or disagree with it, but that's the way it is.

FWIW, Yarn team has recently announced Yarn v6 would also be a rewrite to the native layer, but they mentioned in the blog post that they intend to keep it usable from Corepack (from mainstream platforms)¹, so I guess Bun could make some changes on their end to be somewhat Corepack-compatible; I'm not sure they want though (unless things have changed since #307 (comment)).

https://yarn6.netlify.app/blog/2026-01-28-yarn-6-preview/#yarn-switch ↩

Bun could make some changes on their end to be somewhat Corepack-compatible

Given the good argument Jarred from Bun made in the linked comment, I'd rather Corepack makes some changes here.

I indeed would not like having a performance loss when using Bun through Corepack.

It seems our opinion is quite clear: corepack needs to be refactored to fit bun.

i with help of copilot and all got it to work till here

Does your branch created by github copilot still exist? If not, we'll need github copilot or a human to create another PR.

I indeed would not like having a performance loss when using Bun through Corepack.

It’s likely unavoidable, spawning a process to spawn another is always going to be slower than spawning the other process directly. For JS-based ones, we don’t need to spawn another process, we can reuse the same underlying node process, that can’t work for bun. But besides the startup time, performance should be the same.

spawning a process to spawn another is always going to be slower than spawning the other process directly

For example, there's still a significant difference in startup time between bun run and npm run. I don't want the same to happen between bun install without Corepack and bun install with Corepack.

It seems our opinion is quite clear: corepack needs to be refactored to fit bun.

i with help of copilot and all got it to work till here

Does your branch created by github copilot still exist? If not, we'll need github copilot or a human to create another PR.

It's on main of my fork,
https://github.com/HimanshuKumarDutt094/corepack

will need syncing and cherry picking to move it to a new branch. I have other priorities, but you can check the commit diff and pass it to opus / 5.2

It's on main of my fork,
https://github.com/HimanshuKumarDutt094/corepack
will need syncing and cherry picking to move it to a new branch. I have other priorities, but you can check the commit diff and pass it to opus / 5.2

From my perspective, adding new features that the bun maintainers don't care about to the corepack that's about to enter maintenance seems pointless. Currently, yarn primarily promotes Yarn Switch, and pnpm primarily promotes installation via npx or npm. See https://yarn6.netlify.app/concepts/switch/ and https://pnpm.io/installation#using-npm .

Navigation Menu

Repository navigation

Bun support #295

5 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Bun support #295

Description

Activity

ljharb commented on Aug 24, 2023

KyleSanderson commented on Aug 24, 2023

ljharb commented on Aug 24, 2023

KyleSanderson commented on Aug 24, 2023

uncenter commented on Sep 10, 2023

azu commented on Sep 11, 2023

aduh95 commented on Sep 11, 2023

TheDanielMoli commented on Feb 7, 2024

SilverLinings89 commented on Feb 26, 2024

strafe commented on Feb 27, 2024

ovflowd commented on Apr 1, 2024

TheDanielMoli commented on Apr 1, 2024

ovflowd commented on Apr 1, 2024

5 remaining items

KaKi87 commented on May 10, 2024

ovflowd commented on May 11, 2024

birkskyum commented on Dec 3, 2024

HimanshuKumarDutt094 commented on Oct 12, 2025

nathggns commented on Oct 13, 2025

HimanshuKumarDutt094 commented on Oct 15, 2025

linghengqian commented on Jan 31, 2026

aduh95 commented on Jan 31, 2026

Footnotes

KaKi87 commented on Jan 31, 2026

linghengqian commented on Jan 31, 2026

aduh95 commented on Jan 31, 2026

KaKi87 commented on Jan 31, 2026

HimanshuKumarDutt094 commented on Jan 31, 2026

linghengqian commented on Feb 10, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions