`floco' beta: yet another JS+Nix framework

Announcements
1

I’ve been working on this for ~10 months, and while I jest that this is “yet another” - I think you’ll find it’s a more robust toolkit than you’ll find anywhere else. floco has emerged from its alpha phase ( as at-node-nix ) and is now ready for folks to try out in beta.

https://github.com/aakropotkin/floco.git

floco implements a collections of Nixpkgs Modules ( unlike NixOS modules, these can be used “anywhere” ) to convert various types of JavaScript and Node.js package definitions to Nix modules. These can be used to create Nix builds for JavaScript work at scale. I designed this system for use in a monorepo with over a hundred projects and 7,000+ external dependencies.

I’m still migrating a few features over from the alpha project ( at-node-nix ), and need to flesh out more guides ( in particular how to handle node-gyp and combine multiple projects ). But the contents of the README, and the doc/* directory have a ton of useful examples to experiment with as a preview.

I want to avoid copying and pasting the contents of the project README and guides here; but as a hook I’ll show this off: no modules in this snippet but I hope it shows why this project is worth looking into. This dynamically generates a package-lock.json from read-only paths without ever touching the filesystem. With a few extra lines we can turn this lock into a build ( an exercise for the reader ).

nix run github:aakropotkin/floco#floco-nix -- eval --impure --expr 'let
  url   = builtins.npmResolve "pacote@latest";
  src   = builtins.fetchTree { type = "tarball"; inherit url; };
  plock = builtins.npmLock src;
in plock';

This leverages a Nix plugin to provide a few new builtins that improve UX when generating new package definitions. Ultimately we emit definitions that are usable by plain nix without plugins; but I think you’ll find that some limited npm interop is a useful tool in the toolkit.

The module system, builders, and utilities were all designed to be extensible, and you’ll find that they’re extensively documented. Check out the doc/* dir and the “wiki” tab on GitHub.
I also want to highlight that the underlying installers and drivers used in derivations are implemented purely in bash, coreutils, jq, and findutils - and these routines are usable outside of derivations as replacements for things like npm run or pacote extract.
I encourage folks to try these our in their own derivations or scripts even if you don’t want to fool around with the floco module system.

10 Likes