In my org, we use Artifactory as a cache between us and external sources. They have a free version too. I'd encourage everyone to use it, or something like it. Stop pointing your package managers to the public registry.
Minutes before reading this comment I sent an email to our team to verify our artifactory did not download any packages over the weekend. Most likely not as nobody is working (to add a new one or update a version) but better safe than sorry. +1 for artifactory cache.
Stop pointing your package managers to the public registry.
Unfortunately with NPM this is still awkward, because as soon as you try to shrinkwrap your project, it doesn't just pin the version numbers, it also pins the full source location. That's in direct conflict with (and apparently takes precedence over) using one of the local caching proxies that would otherwise be a useful practical solution to this problem, and the situation gets even more complicated if you have people building at multiple locations and want each to have their own proxy.
Yarn seems to have a better approach to this. It has a few problems of its own, notably surprising, quiet updates to the lock file when using the default options (IMHO a mistake since the big selling point of Yarn is its deterministic, reproducible behaviour) but at least you can do something resembling a local cache combined with something resembling version pinning, which is the ante for any sane build system.
Don't use shrinkwrap - this comes directly from Laurie Voss, COO of NPM Inc. In my own experience using npm shrinkwrap has been pretty bad.
NPM has its own lockfiles now, similar to yarn.
> It has a few problems of its own, notably surprising, quiet updates to the lock file when using the default options
This I've never noticed. I'm genuinely curious how it would happen. The only way I imagine it might happen is if you do a fresh install with no cache and some of the packages have moved or changed on the registry. Do you happen to have more details?
Some of its commands, notably install, can modify yarn.lock if it's out of sync with package.json, and I think that by default they still do so silently. You can override that modification with various options, but it seems to defeat the point of a tool whose main function is to ensure stable, repeatable builds if something on say your CI server or a developer's machine after a source control merge can wind up with a locally modified yarn.lock that doesn't fetch identical versions of all dependencies to what everyone else is using.
Edit: Also thanks for the tip about npm's new locking mechanism. Apparently that arrived with NPM 5. I just checked, and we have developer machines here that were last updated well under a year ago and are still on NPM 3, and that had itself been installed along with something like the third new major version of Node in not much over a year. I don't know how anyone is supposed to do development intelligently while the most fundamental tools for things like dependency management are bumping a major version and radically changing how they do even the most basic and essential things literally every few months. :-(
It is fundamentally more secure as it functions as a private controlled proxy for the public repo. Also solves some other nice gotchas such as people pulling a left-pad joke on you and reproducible installs as all packages are cached so your build servers and dev systems get the same version of all packages (if properly used with shrinkwrap kind of solutions, or even without if properly handled).
We self-host Artifactory. If our internal instance goes down, it's always possible to fall back to the public registry of language (NPM, Maven, pip etc). It's far more unlikely for our Artifactory and the public registry to go down simultaneously.
