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?
> - 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 :)
@delroth Do you know why this would require IFD? Naively I'd expect that you could generate whatever is in node-packages.nix using fromJson on package-lock.json and logic written in Nix. We wouldn't then be importing any files created by build rules, so that shouldn't require IFD.
@delroth Ah, it _doesn't_ fetch them using `npm`: https://github.com/NixOS/nixpkgs/blob/60762c6576cc8b9e2d615ea9bd8c59ffe34174a1/pkgs/build-support/node/fetch-npm-deps/default.nix