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!).
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
I renamed it to elixir_bun but seems that I forgot to change it in a few places. Will do it right now.
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.
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
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.
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.
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!
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.
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).
I’ve just released bun 1.3.1 which contains more improvements for process wrapping. Now we just wrap bun build. This allows you to use bun run to call other commands (for example bun run tailwind to build your CSS without using the Elixir Tailwind package).
Thanks @Sgoettschkes for reporting this and following up with a detailed investigation.
which I used as a base.
