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.