For the last several years, I've been checking all dependencies of my team's nodejs project into source control. At first, we stored the archives of all dependencies using yarn v1's offline mirror, now we store zip
s using yarn v2's cache feature.
The reason I felt like it was a good idea to do this is package security, namely:
- We can run CI builds completely without internet connection using vetted packages.
- We're insulated against package loss: if someone were to unpublish their work, or there would be an npm registry outage, we'd still have access to packages to perform builds.
These feel like good reasons; however, what I didn't realize until well after this decision were the costs of the decision:
- Network speed in many scenarios is faster than disk speed: it's often faster to fetch all packages from a CDN than to decompress them on disk and restructure into
node_modules
- Storing archives inside git balloons repository size significantly, reducing CI speed non-trivially through slower clone times (even shallow clones are slow because of the size of the dependency tree, though this may be limited exclusively to the train-wreak of the JavaScript ecosystem).
(1) is covered generally by a lock file: storing hashes of repositories to avoid malicious attackers changing packages. (2) is a risk but perhaps a fairly low one all-things-considered.
I think this question almost delves into the range of opinion, but I hope just slightly enough to be an OK question here, which is: is it more beneficial to check project dependencies into source control or to fetch them with a proper lock file? An extension of this is: if you do check dependencies into source control, what are the best practices to maximize benefits and minimize costs?
Yarn
something like that? You wrote "Storing archives inside git balloons" - I don't know Yarn, but isn't the job of a package manager to avoid this?