Is it possible to set bun.sh as javascript runtime for building and package management?
3 Likes
I’d too really like this. I got as far as setting the build command to run a script:
#!/bin/bash
# Stops the execution of the script if any command has an error.
set -e
# Install Bun
curl -fsSL https://bun.sh/install | bash
export BUN_INSTALL=$HOME/.bun
export PATH=$BUN_INSTALL/bin:$PATH
echo "bun --version"
bun --version
# Install deps
bun install --frozen-lockfile
echo "Build"
bun --bun x astro build
However, I get the following error when trying to build for an Astro.js project:
`astro sync` command failed to generate content collection types: Function yaml.safeLoad is removed in js-yaml 4. Use yaml.load instead, which is now safe by default
No idea how to fix it 
Not possible and no plans to do that anytime soon (if at all).
@will-stone, we can’t provide troubleshooting advice with your custom script.
That’s okay @hrishikesh, I was asking for official support, I thought I’d just post it in case there were any other people out there trying to use Bun and had figured it out.
Thank you for answering. Is there any technical reasoning on this matter or just deliberation from commercial interests?
Just for clarification, I don’t intend to create any conflict of any kind, but I believe more details on decisions like this have impact on many teams, not only mine, makes their own decisions regarding their stack and products. That said, I’ll respect if you decide not to discuss this any further, but i hope to have more enlightenment about it.
There are several reasons:
- Bun is a new technology - I won’t consider it mature yet. Just because something new hit the market, doesn’t mean everyone needs to switch to it. Node.js still gets the job done. Deno has been out for some time and was considered Node.js killer in its days, yet Node.js still exists and Deno is not being talked as much anymore. People know it exists, but the glitter that it brought in its first few days of introduction, is all gone. There’s a very high chance, same would happen with Bun.
- You’re the first one to request it. Unless there’s enough demand and motivation to make this switch, there’s no incentive for us to invest in making this change.
- More importantly… why? Node.js is working fine and serving the needs of all the users. It’s mature, stable, gets the task done. Just because some new shiny thing came along and advertised itself as “better” than the old one? Maybe it is indeed better - I haven’t tried it, but it doesn’t necessarily mean Node.js needs to be replaced now. Maybe that would be the case in a few years, which is when we can revisit this? But it’s been what… a week or two since its first stable release? Sorry, too soon to switch.
- Changes like these would require careful planning, engineering efforts and testing. We have more important things to work on at the moment. Those more important things are intended to solve real problems and system bugs. In an ideal world where money and time is not an issue, we could possibly add support for this soon, but this isn’t that world.
I could go on, but I think you get the point.
@hrishikesh I don’t think anybody is talking about “switching” (other than you), I believe @SkyaTura was simply asking for support for the runtime, as well as node. Having Bun/deno in the image would be a start. As I showed, we can run a script to install it each time.
Okay, switch or not, most of the above statements hold true.
Point 1 and 3 are half-valid, in the sense adding that at the moment is not providing any significant value.
Point 2 and 4 are fully valid.
If there’s a very strong reason to add Bun support, let us know.
I must say I find your responses weirdly mildly hostile. Vercel are supporting Bun. I wonder if they have added support because they don’t “have more important things to work on at the moment”, or because they just think it’s fun to support more of the JS ecosystem. @hrishikesh if it’s not your cup of tea, no worries, we were just wondering if it was possible. At least we know it’s not on Netlify’s radar now, obviously quite a long way off the radar; if you’re looking for Bun support, look elsewhere 
1 Like
I understand your reasoning, it seems to me this is more a commercial decision than technical one, which is 100% fine, for me, actually.
As pointed out by @will-stone, I was looking for an option to use Bun as package-manager, as it is already possible with yarn and pnpm in Netlify today. As for the runtime binary, it was for using it’s bundling capabilities as well.
I don’t fully understand how this can be so challenging since Netlify already supports not only other js package managers, but also has other languages built-in such as Go, for instance.
About the hype argument, Bun is no quite the same as Deno, because it’s goals is not to break with well established patterns on Node, but being capable of drop-in replacement for the RUNTIME with full (or almost) backwards compatibility and less overhead. Not to mention DRASTIC performance improvements in build/bundle time.
Also, it’s important to notice that Bun’s evolution in the JS community has also a different growth and projection than Deno in a sense that it’s not selling itself as the “Node killer”, and it’s creators has a very grounded positioning about the current state of the project.
Last, but not least, I made some research and in the current state it is possible to support Bun on Netlify Build by workarounds like the script @will-stone provided or using plugins. I’ve created a successful proof of concept will be publishing as netlify-plugin-bun later this week.
I hoped that this could be built-in out of the box in order to provide a better experience to other users overall, but I won’t insist.
My tests can be found at GitHub - SkyaTura/test-bun-netlify
Hi, @SkyaTura and @will-stone. I have some good news.
I work more closely with the developers responsible for our build system than @hrishikesh does. It seems our developers also feel bun is an exciting technology and want people to be able to use it here too. I do believe that we most likely will support bun “sometime fairly soon”.
Unfortunately, I cannot be specific about what “sometime fairly soon” means as far as a firm or official ETA. However, I can say it is definitely on our roadmap for planning so, unless something changes (which is possible but unlikely), this should be a matter of “when” we will support using bun (and not “if” we will).
There will likely be blog posts or a similar type of announcement when this occurs as well.