New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can we add support for Bun? #1465
Comments
Yeah I also think that would be an excellent idea, and I need it :) |
Hi @westtrade, that's definitely an interesting idea! If bun truly works as a drop-in replacement for Node, that could work well. We've avoided supporting Deno in the past since it doesn't fit the same use-cases as Node. We likely will need an RFC to work out the design, since a lot of the assumptions in the code right now are around Node being the base of the platform. |
It's not quite mature enough imo. Needs a bit more api compliance and issues checked off. |
That sure seems promising & I was disappointed to see the lack of support. Then I realized bun doesn't support windows... |
@DerekZiemba Bun should have Windows support very soon according to its creator on X. |
Bun hit 1.0 - it's time :) |
@HazAT not quite. We're still waiting on this to merge. |
Why would Volta supporting Bun require Windows support? |
To be consistent, imo. Volta is marketed as cross-platform and should behave similarly on each platform that it is available on. If someone were to pin Bun@1 on MacOS, and a developer on Windows tried to use that repository - it wouldn't work. I'm on Mac, and definitely want Bun support, but only if Volta remains seemlessly uncomplicated and non problematic across operating systems for what it supports. That's what users have come to expect today. |
Bun has shipped with Windows Experimental support |
now it's merged |
As @charlespierce notes: this is not a straightforward “just do x” kind of design. I would love to see it implemented, but it probably needs an RFC, to answer questions like:
I think all of those are answerable, but they are also not obvious! Additionally, even an answer like “supports pinning Bun only as a package manager (at least for now)” needs to make sure it makes sure not to close off adding support for it as a runtime later—or explicitly chooses to permanently close off that support barring a significant breaking change! We would welcome that RFC, but hopefully that clarifies why this one needs some design work! |
I am sorry if I am being naive, but If I can pin Bun as a package manager, the runtime would be automatically available through the Am I wrong? |
That would almost work, and likely could be made to work! (I’ll elaborate on the gap even there below.) The first and most important problem, though, is not that feature itself, but how it interacts with what it means to support pinning Bun as a package manager without pinning it as a runtime. If we just add support for pinning it as a package manager now, and then want to add support for it as a runtime later, if we are not careful about the design up front we could easily find ourselves backed into a corner and have to make a breaking change, which we would very much prefer to avoid. The “almost” part is this: right now Volta assumes a fair number of things about how everything works and uses Node explicitly. We were not thinking about alternative runtimes when we built it! As a result, you actually cannot pin a version of npm, Yarn, or pnpm today unless you pin a Node version. That could be changed, but it is not “trivial”. |
Bun has release version 1.1, with windows support. So now it could be integrated to Volta? |
Bun is a drop in replacement for nodejs and it have dramatically reducing startup times and memory usage
https://bun.sh/
The text was updated successfully, but these errors were encountered: