Bun - an installer for JavaScript Bun

Hi!

Bun is a new all-in-one toolkit for Javascript: bundler, test runner, package manager, dev. environment, etc. It can do what Esbuild does, and more.

I’ve just published a package heavily inspired in the Esbuild integration package made by Wojtek Mach and José Valim that is adapted to install and invoke Bun.

I am using it in a personal project of mine and the switch from Esbuild requires very minimal changes. Then, it allows you to install and the many node packages available without requiring NodeJS or NPM. It also supports TypeScript, JSX, CSS, WASM, and many more (even Rust!).

Anyway. If you want to check it out you can take a look at the GitHub Repo and the Hex.pm package.

Thanks again to @josevalim and @wojtekmach for creating the Esbuild packge :bowing_man: which I used as a base.

8 Likes

It seems that you have some typos in readme:

def deps do
  [
    {:bun, "~> 0.1", runtime: Mix.env() == :dev}
  ]
end

While the name of the package is elixir_bun on hex.

1 Like

Thanks for noticing this @D4no0 . I planned to name the project just bun bun when I was trying to push it to Hex.pm I found out that the name was already taken :cry:

I renamed it to elixir_bun but seems that I forgot to change it in a few places. Will do it right now.

EDIT: fixed just now. Thanks again.

I’ve just released elixir_bun 0.1.4 with the following changes:

  • A new logo
  • Updates in the README to use symlinks instead of copying the Phoenix dependencies
  • A fix for zombie Bun processes
  • An update to Bun 1.0.7 which is the latest stable version

Thanks to @pepicrft and @LostKobrakai who made their first contributions to the project :rocket:

For more information you can take a look at the Hex.pm package and the release notes.

1 Like

Hi all again!

When I created this package I wanted to publish it as bun to follow the conventions set by the esbuild and tailwind packages. Unfortunately that package name was taken so I had to publish my project as elixir_bun instead.

After getting in touch with the hex.pm team they confirmed that having an empty package that is just squatting on a name goes against the hex.pm policies so it has been removed and made available again.

Long story short: the elixir_bun package is now retired on hex.pm and replaced by the bun package. If you are updating from elixir_bun you just have to replace :elixir_bun with :bun in your project.

Since this is a breaking change I’ve used the opportunity to release version 1.0 as bun can now be considered stable.

Greetings! :hibiscus:

11 Likes

Hi all!

I’ve just released bun 1.1.0 which fixes an issue when running under elixir-slim Docker images. Thanks @Wigny for noticing and fixing the issue :bowing_man:

Additionally new installations will no use the latest bun version (1.0.26 at the moment of writing this). Remember that you can use the library configuration to pick the bun version that you want to use.

As usual you can check out the GitHub Repo and the Hex.pm package for the release notes and more information.

Happy coding! :hibiscus:

4 Likes

Hey, thanks for maintaining this nice tool.

Yesterday I was trying to achieve something similar to what the deno_ex library does, but using bun, which is providing the bun binary at runtime that later can be called with System.cmd/2 or using Port, allowing you to call JavaScript files from Elixir.

The problem I faced first was that the library by default downloads the binary in the _build/ directory and then when my project was compiled and released (mix release) the binary was not available anymore. To solve this issue I tried to imitate deno_ex and set the bun path to Application.app_dir(:bun, "priv/bin/bun"), but since this function was not meant to be used at compile time, I had to set this configuration in the runtime.exs file with config :bun, path: "..." and ensure to call mix bun.install --runtime-config in the mix assets.build task .

I know I could set the bun path to the application priv directory, but it’s an umbrella project and it doesn’t make sense for me to put the binary that will be used by a few child applications in a specific application. So for anyone reading this, any suggestions on a better approach to making bun available in the final release?

I think that each application that requires the bun executable should have bun as a dependency. This would allow you to set the required priv path per application, so each of them has its own bun executable.

Another approach that may work (but I don’t like as the first one) is to just save the bun executable in a well known path and access it directly from each application.
For example if you are using Docker for running the release you could download the bun executable in a particular path in the image and then access it directly in the applications.

Hi all!

I’ve just released bun 1.2.0 which improves the process wrapper. It now uses Bun to wrap itself in a way that automatically shuts down when the stdin closes. This removes the POSIX shell dependency on the development machine.
Thanks @hauleth for noticing and fixing this! :bowing_man:

Additionally I’ve updated the default Bun version that is downloaded to 1.0.33, which is the latest stable version released at the moment. As usual, you can override this setting in your configuration.

Check out the GitHub Repo and the Hex.pm package for the release notes and code.

Happy coding! :hibiscus:

3 Likes

Honestly, I have been using such script for some time now. I just finally decided to port my solution to bun library (I do not use this library in my project, I use my own wrapper instead).

1 Like