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 :)

[kvnwolf]

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.

[KPCOFGS]

I created a separate repository for bun version manager in python, if anybody is interested: https://github.com/KPCOFGS/Bun_Version_Manager

[aklinker1]

I wanted to move one of my open source projects to Bun, but felt blocked by this - I want to make sure anyone who contributes has the same environment, and is using the same version of bun that I am.

If I were to add a solution to bun, I would follow corepack's pattern of selecting the correct version of bun per-project automatically, instead of building out a complete version management tool, like ASDF or NVM. This is what I'm thinking:

• When using the bun CLI...
  • If you're outside a project, just run the command like it does today, using $BUN_INSTALL/bin/bun
  • If you're inside a project that doesn't have a package.json or a packageManager, just run the command like it does today, using $BUN_INSTALL/bin/bun, same as if you're outside a project
  • If you're inside a project whose package.json has a packageManager field, ensure the version specified is downloaded to $BUN_INSTALL/versions/{version}/bin/bun before "forwarding" the command to that binary instead
• When running bun upgrade
  • If you're outside a project, just upgrade $BUN_INSTALL/bin/bun, as it works today
  • If you're inside a project, also change the packageManager field to use the new version
• If we need support for version management commands, we could add a bun vm command, similar to bun pm

  bun vm use 1.1.28   # When inside a project, update it's `packageManager` field to a specific version
  bun vm rm 1.1.26    # Delete the install of a specific version
  bun vm list         # List all versions available locally
  

Goal here is a non-breaking change - bun should keep functioning as it does today for those who don't want to opt-in to version management. If you do want to opt-in, just specify a packageManager field in the package.json, and bun will handle the rest!

I'd be willing to contribute something like this... So I began work by creating an external tool, Bunv, written in Zig to learn the ropes and get an idea of what an implementation might look like.

https://github.com/aklinker1/bunv

Goal was to implement the behavior I described above. Since it's an external tool, it also provides a third executable, bunv, that works as bun vm would. Right now, it's MVP can only read a package.json, detect packageManager, check that verison is installed, install it if missing, and run the bun command using that version's executable.

https://github.com/user-attachments/assets/2e6213e6-0f39-4c7c-9bf6-4ffa5faaff15

This is enough to benchmark the overhead of discovering the version to use and spinning it up. On my computer, bun --version went from 1.5ms to 2.0ms. A 0.5ms overhead seems reasonable to me, though it is a slowdown.

---

So that's where I'm at. Before doing anymore work or contributing to Bun directly, I'd like some feedback from maintainers - if this is something you're onboard with? If so, thoughts on the implementation I described above?

[ebramanti]

Any update on this? It would be great to see version management integrated directly into the bun CLI, rather than relying on third-party tools. I've been using bunv for this, and it feels like a feature that could fit naturally into the core executable.

[mags-sully]

As more teams adopt Bun in production environments, this feature becomes increasingly essential

[simnalamburt]

You can now easily try out @aklinker1's bunv using Homebrew!

# Uninstall any pre-existing bun installation
brew uninstall oven-sh/bun/bun

# Install bunv
brew install simnalamburt/x/bunv

bun

bunv is basically corepack for bun—and it's super convenient. You can start using it instead of bun right away, starting today!

[syhol]

If bun is the only tool you need to version manage then bunv may be the tool for you.

I've found that I often need to manage multiple tools versions: mostly bun, python, uv, go, jq, kubectl, and terraform. But also for legacy projects: node, yarn, pnpm, deno, ruby, so on...

<shill> So I've been using the multi tool version manager mise that has 1st class bun support + over 800 other tools. It originally started out using asdf plugins, but now over 80% of tools are pulled directly from official sources or github releases WITHOUT any 3rd party shell scripts. It also has a great task runner and envvar manager built in.

I contributed a little bit in winter last year but I'm too busy to continue. It has a fantastic (helpful and low drama) community and maintainer though. </shill>

Regardless of which, I do feel that a multi tool version manager is the answer. Other multi tool version managers are available:

• aqua
• vfox
• pkgx
• Nix based solutions:
  • devbox
  • devenv
  • flakes

[ckhatton-pvfscaffolding]

There is also:

Bum - Bun Version Manager

https://github.com/owenizedd/bum

[rjawaji1]

My favourite tool in general is asdf if anyone is interested. You can use it to manage the version of other tools as well if you want.

[cameronapak]

bun wen?

[sanathusk]

+1 on this. Does the bun team agree this is a good to have and open to PR to implement the same?

[PixsaOJ]

I like how PNPM does this, and I would like to have the same without third party.

[cameronapak]

mise is GETMO (good enough to move on) for me

[RodrigoTomeES]

Hi @nektro,

I think that even though this issue is a duplicate, #2943 should be the one that is closed. This one has much more information and is also much easier to find.

Neither collaborators/contributors nor I could find the issue you mentioned. I believe it would be better for everyone to keep this issue open.

Best regards,

[ckhatton-pvfscaffolding]

I guess, chronologically, #2943 came first. I see someone has added a summary of alternatives - that will save people scrolling this one. A more tidy issue title would be preferred though 😅