Bun Version Manager (BVM)

[RodrigoTomeES]

What is the problem this feature would solve?

It would be amazing to have a BVM like NVM for node. This utility will solve the same problems that NVM.

What is the feature you are proposing to solve the problem?

A version manager for bun, designed to be installed per-user, and invoked per-shell. This will solve the problem of switching between versions of Bun.

What alternatives have you considered?

I saw this repo https://github.com/swz-git/bvm but it is outdated

[vjpr]

Would be very nice (and very Bun-like!) to have it built-in. Every "version manager" I have worked with for other languages is complete hell.

Something as simple as:

BUN_VERSION=0.7.0 bun or bun --version=0.7.0

And bun --version would print the location of the exe, and why it's being used...e.g. because ENV var is set in shell.

[drewbitt]

FYI, there is proto for this which is more up to date than bvm. In pnpm for node we have the pnpm env use --global lts syntax

[tomByrer]

FYI, there is proto for this which is more up to date than bvm. In pnpm for node we have the pnpm env use --global lts syntax

Supported languages

• Bun
• Deno
• Go
• Node.js (and npm, pnpm, yarn)
• Rust
• ... and more via plugins!

I would rather learn 1 API/tool for many of the things I want to run, vs 7 different tools.

[drewbitt]

I would rather learn 1 API/tool for many of the things I want to run, vs 7 different tools.

If proto is maintained that's fine, but it may be in a tool's best interest to maintain a solution on their own.

[yus-ham]

there is asdf plugin for bun https://github.com/asdf-vm/asdf https://github.com/cometkim/asdf-bun

[wesharper]

I second that this would be a killer feature if it did the following:

1. Reads .bunrc file
2. Automatically downloads and uses the right version similar to nvm's Deeper Shell Integration.
3. Supports aliasing and default bun version for shells without .bunrc file.
4. Uses aliases for common versions like stable or lts.
5. First party support for cleanup. I'm not sure if this is still the case, but in the early days of nvm, if one already had node installed, it was a giant pain to clean up the pre-existing node version and avoid conflicts with nvm. It would be great if opting in to bvm automatically avoids conflicts with installed versions of bun.

If other runtimes did this, there would be no need for 3rd party tools like asdf or proto.

[nmccready]

FYI, there is proto for this which is more up to date than bvm. In pnpm for node we have the pnpm env use --global lts syntax

Has anyone got this to work behind a corp proxy?

$ proto install go 1.20
Error: plugin::http

  × Failed to make HTTP request.
  ├─▶ error sending request for url (https://github.com/moonrepo/go-plugin/releases/latest/download/go_plugin.wasm): error trying to connect: invalid peer certificate: UnknownIssuer

[drewbitt]

FYI, there is proto for this which is more up to date than bvm. In pnpm for node we have the pnpm env use --global lts syntax

Has anyone got this to work behind a corp proxy?

$ proto install go 1.20

Error: plugin::http

  × Failed to make HTTP request.

  ├─▶ error sending request for url (https://github.com/moonrepo/go-plugin/releases/latest/download/go_plugin.wasm): error trying to connect: invalid peer certificate: UnknownIssuer

I would recommend posting in that repo and not here :)

[kevinwolfcr]

What about specifying the bun version in bunfig.toml?

[mikeseese]

While bunfig.toml seems like a totally valid place to specify the version, I'd argue it should be specified under package.json's engines attribute, which is already built for this kind of purpose.