@delroth

> - 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.

@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

@robryk

> 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.