The new buildNpmPackage in nixpkgs is IMO the best thing that happened to Javascript Nix packaging in a while.
https://nixos.org/manual/nixpkgs/unstable/#javascript-buildNpmPackage
It trades off "declaratively listing all dependencies in a Nix source expression" for "actually being usable by normal humans". Slight loss in auditability but OTOH people were just packaging pre-built Javascript before because node2nix was such an unusable mess.
@delroth What was roughly the reason for node2nix being a mess?
@robryk try it and report back :)
Stuff I remember from the last time I tried using it:
- Requires vendoring parts of the projects being packaged into nixpkgs (package.json, package-lock.json)
- Requires running a code generator on updates
- node2nix itself needs updating for every new nodejs version, and that doesn't happen necessarily in sync with nodejs bumps in nixpkgs
- It's super slow.
> - Requires vendoring parts of the projects being packaged into nixpkgs (package.json, package-lock.json)
Oh :/ Yes, that's terrible.
> - Requires running a code generator on updates
_code_? Do you mean something that updates whatever-the-nix-expression-reads-to-find-hashes-of-all-deps or something else?
> - node2nix itself needs updating for every new nodejs version, and that doesn't happen necessarily in sync with nodejs bumps in nixpkgs
That makes me wonder if the new setup is going to require cache hash updates when npm-the-binary is updated.
> Do you mean something that updates whatever-the-nix-expression-reads-to-find-hashes-of-all-deps or something else?
node2nix transforms package.json + package-lock.json into a Nix expression equivalent. With IFD you could generate this at eval time but nixpkgs doesn't allow that, so you have to commit the output of node2nix into nixpkgs.
See https://github.com/NixOS/nixpkgs/tree/master/pkgs/servers/monitoring/uptime-kuma for a good example of the amount of wasted bytes :)
