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.

There is a desire to simply write "packageManager" : "[email protected]" 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.

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 🤔

I don't precisely know how corepack works so I don't want to speculate too much but from what I know, node also doesn't ship yarn. However, corepack can detect if yarn is being used and inform a user to do so if it is set as the packageManager. The same would be nice for bun. In our project, we don't use bun as a runtime very much but we do rely on its performance as a package manager to speed up our pipelines.

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 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 see. That makes sense to me.

Also to be clear, my commentary is just me trying to make sense of what the ask here is. Im not speaking on behalf of the project, nor blocking these changes from happening.

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

Actually, this is exactly what we would like, what we are looking for and the only reason why I am using corepack.

Your assumption on what users are looking for in corepack is wrong. Forcing a package manager on a per-project basis by specifying it in package.json is exactly what I am looking for as a corepack user (aka, failing when trying to use a different one).

Sorry, you are misquoting me here. The comma before only was there for exactly that reason. To rephrase my statement without a subordinate clause:
I really don't think anybody wants node to ship bun. I think they only want to enable corepack to check if it's being used if it is specified as the packageManager.

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