"Copying" might just be: check your needed dependencies into your source code tree.
Managing complexity is important, depending on several hundred things (especially if you don't have control over them) is not managing it.
Depending on simple things like "left pad" is just shooting yourself in the foot in a future time, as this has shown
In today's world it's easy to forget the million ways in which a castle of cards might fail.
> Managing complexity is important, depending on several hundred things (especially if you don't have control over them) is not managing it.
You're still depending on the thing you checked in. You're just storing it somewhere else.
PS. You can achieve the same thing (frozen dependency tree) with shrinkwrap.
Yes, since it's checked in it won't change "behind your back" or disappear
You also can add fixes to it
It will also not get fixed, when important bugs or security issues are discovered and fixed upstream.
>You also can add fixes to it
Which is called a "fork" which you'll then have to maintain.
only because of a design oversight by npm which is now being fixed. Like I said, fix the issues in handling your dependencies, and you remove the overhead of including them, such that "depending on several hundred things" is managing it.
Checking your needed dependencies into your source tree can either be done by recreating them in your source tree or pointing to them. Your pick.
But it hasn't. Left-pad was republished by a third party shortly after it was unpublished by its original author. It was open source and so it was trivial to fork and republish.
Personally my only direct dependency on azer's modules was a module for shuffling an array in place. A quick look in the registry provided me with a substitute that had the same API and used the same algorithm and had the same test coverage, by another reputable author.
Now imagine instead of dozens of small tiny modules it had been jQuery, or React, or Babel. Or anything else that survives the "is it too large to copy-paste into your codebase" test the article puts forth. Good luck replacing that kind of dependency in less than an hour (if your argument is "well, I can just download a copy elsewhere and paste it: what if it was unpublished because of an undisclosed vulnerability with no patch available and you need to replace it).
Facebook and others "copy" by checking in dependencies into version control. They will never be affected by a decision to unpublish something from the registry. But even so unpublishing is a red herring: it's a quirk of npm Inc's registry.
The real takeaway from #unpublishgate is: don't depend on external sources for continuous deployment. If you need a registry, proxy it (hint: there are free alternatives to npm Inc's on premise offering). If your deploys only work when npm (or GitHub) is online, your deployment process is already broken.
This is the standard method for 'copying' in Go as well. It's called 'vendoring' and is often applied to Go programs (as opposed to Go libraries). You basically put a checkout of the dependency in the vendor/ folder and the go tool will prefer it over fetching the dependency and/or grabbing it from GOPATH (since Go 1.6).