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