I admit this is somehow the first time I’ve heard of the npm cache add command. For buildNpmPackage (the new npm builder within Nixpkgs), we construct the cache ourselves in a reproducible manner (which then gets stuffed into a FOD). I went this route because (a) the cache format has been stable for long enough that I feel comfortable with this, and (b) I didn’t know the aforementioned command existed.
I’m sure there are some benefits that exist for my method – for example, the cache doesn’t have to be reconstructed on every build, leading to quicker builds, but it might be something to consider… not sure to be honest.
If you happen to be interested in discussing this further, feel free to reach out. I’m winter on Libera and OFTC, and @winterqt:nixos.dev on Matrix. We can also talk in the Nix Node.js channel on Matrix, which is #nodejs:nixos.org.
Thanks for the reply! To be honest the way the cache is built isn’t very important IMO, although I was glad to see that npm cache had improved enough to be used. You do also mention that by building the cache by hand, it does not need to be reconstructed on every build; that’s true, though extracting the npm cache commands to another derivation would be straightforward. The example in the article was built to be easy to understand.
What I find really important on the other hand is getting rid of the FOD step, because this step forces users to update a value in the Nix config. This increases friction and adoption, and (IMO) is completely unnecessary since all the information is already present in the lockfile – provided a lockfile exists.
I’d be happy to chat! Although I think I forgot how to access matrix…
Nice work!
I admit this is somehow the first time I’ve heard of the
npm cache addcommand. ForbuildNpmPackage(the new npm builder within Nixpkgs), we construct the cache ourselves in a reproducible manner (which then gets stuffed into a FOD). I went this route because (a) the cache format has been stable for long enough that I feel comfortable with this, and (b) I didn’t know the aforementioned command existed.I’m sure there are some benefits that exist for my method – for example, the cache doesn’t have to be reconstructed on every build, leading to quicker builds, but it might be something to consider… not sure to be honest.
If you happen to be interested in discussing this further, feel free to reach out. I’m
winteron Libera and OFTC, and@winterqt:nixos.devon Matrix. We can also talk in the Nix Node.js channel on Matrix, which is#nodejs:nixos.org.Came to the comments to mention this builder, but it is a nice surprise to find its author @winter on lobsters
Hi,
Thanks for the reply! To be honest the way the cache is built isn’t very important IMO, although I was glad to see that
npm cachehad improved enough to be used. You do also mention that by building the cache by hand, it does not need to be reconstructed on every build; that’s true, though extracting thenpm cachecommands to another derivation would be straightforward. The example in the article was built to be easy to understand.What I find really important on the other hand is getting rid of the FOD step, because this step forces users to update a value in the Nix config. This increases friction and adoption, and (IMO) is completely unnecessary since all the information is already present in the lockfile – provided a lockfile exists.
I’d be happy to chat! Although I think I forgot how to access matrix…