Announcing bun2nix - Build bun based projects with nix

Links
1

Hi everyone, recently I have gotten my tool bun2nix into a polished enough state where I’m happy enough to have other people use it.

I built it partially as a learning opportunity to better understand how the various lang2nix tools work, and I think it worked out fairly well and has a nice enough interface although I am open to feedback.

Being written in rust adding it as a postinstall script with bun install is very feasible as even for a medium sized repository (~2k packages) install times were more than reasonable (~50ms), making it ideal for running bun install in something like a shell hook.

12 Likes
2

We still need something like this in nixpkgs to package bun apps is that possible?

3

While it would be possible to put this in nixpkgs as it is (and likely fairly easily too), there are a couple reasons why I haven’t attempted this yet.

First off, there is this mostly implemented pr by someone else already in nixpkgs with a different approach, but blocked on a bun install --offline flag in the package manager itself.

Secondly, while it does technically work as intended for the most part, I do believe with some major refactoring and also the inclusion of a jsonc/json5 parser in nixpkgs lib, bun projects could be packaged without the binary provided by bun2nix altogether, which I would like to have done before upstreaming this.

I do eventually plan to attempt something like this but I’ve been quite busy for past while so it would probably be a couple of months unless someone else wishes to create something along the lines of lib.fromJSONC.

4

This is possible, but I wouldn’t really recommend it in the context of Nixpkgs. Vendoring lockfiles bloats the size of the tarball and can have massive effects on evaluation time even with a relatively small number of packages

It’d probably be better to look at the lessons we learned with Rust’s cargo and its lockfiles, and the eventual implementation of fetchCargoVendor, which parses the remote lockfile to create a nice FOD that Nix and cargo are both happy with. This would probably be even better than an --offline flag for bun install too, as it would let us handle any differences between versions of Bun and its output format; some of bun2nix could even likely be reused for it

I could see a proper parser being great for upstream Flakes though (similar to importCargoLock), since it would avoid the need to constantly update a hash and the lockfile will be vendored anyways

(BTW I hadn’t seen this project before today. Super nice work!)

5 Likes
5

How hard would it be to add a unit test target?

6

unit test target

Hi, sorry, it’s not really clear to me what you mean by this but here are the two options I could think of:

If by “unit test target” you mean some kind of test dependencies only build it would require reading from the workspace field (i.e. devDependencies, etc) and figuring out the type of dependency in the CLI before filtering out irrelevant packages based on matching the version selector, which should be doable.

If by “unit test target” you mean some kind of unit test runner version of mkBunDerivation, you can already do this by adding a checkPhase to your existing package build and bun test should work as expected - i.e:

{mkBunDerivation, ...}:
mkBunDerivation {
  packageJson = ./package.json;
  src = ./.;
  bunNix = ./bun.nix;

  checkPhase = ''
    bun test
  '';

  doCheck = true;
}