The flag iterates through the lockfile entries, rewrites `resolved` URLs
to those that will be in the cache (like `fixup_yarn_lock` from
yarn2nix), removes `integrity` for git deps whose hash won't match the
reproducible repacking that the fetcher does, writes the amended
lockfile, and exits.
In some odd scenarios, `npm prune` either fails, or hangs. I have no idea
what could possibly be wrong at the moment, but let's provide an escape
hatch for packages that can still use the rest of the install hook's
functionality.
v1 lockfiles can contain multiple references to the same version of a
package, and these references can contain different `integrity` values,
such as one having SHA-1 and SHA-512, while another just has SHA-512.
Given that HashMap iteration order isn't defined, this causes
reproducibility issues, as a different integrity value could be chosen
each time.
Thanks to @lilyinstarlight for discovering this issue originally, as well
as the idea for the sorting-based implementation.
Git dependencies with install scripts are built isolated from the main
package, so their development dependencies are required.
To take advantage of this, #206477 is needed.
This splits prefetch-npm-deps into multiple files, as well as making a
few small changes along the way, such as going from a `HashMap` to a `Vec`
as the container for packages, to deduplicate them more efficently.
Fixes "No such file or directory" error when running prefetch-npm-deps
in its default mode (print hashes, for update scripts etc),
in an environment that doesn't have a `nix` binary (for `nix hash`).
Single quotes must be used when using graves in a quote, else Bash will interpret it as a command to run.
Thanks to Dimitri for catching this (8e651111b7 (commitcomment-92100762)).
GNU tar will apparently silently include mtime of files if --mtime is
passed with an unrecognized date format. This led to hash instability
from those mtimes and this fixes it to force all mtimes to epoch
timestamp 0.
Previously, we stored the tarballs from the hosted Git providers directly in the cache. However, as we've seen with `fetchFromGitHub` etc, these files may change subtly.
Given this, this commit repacks the dependencies before storing them in the cache.
A `package-lock.json` file can contain multiple instances of the same dependency, which caused unnecessary downloads and duplicate index entries in the generated cache.
