Ironically, this happened because of a mitigation put in place to prevent the leftpad disaster from happening again. To recap: the developer of leftpad removed his package, which broke packages that depended on it. To prevent this from happening again NPM decided that you can't unpublish a package that has dependents, which I think is a sensible policy. The result of this is that you can prevent anyone's package from being unpublished by depending on it. This 'everything' package simply took this concept to its extreme conclusion.
Personally, I think if you're not sure you want a package to be available publicly in perpetuity, you should maybe consider publishing it to a private registry. Even if NPM did allow developers to unpublish any package, there's nothing stopping me from downloading a tarball of your package as soon as you publish it, and hosting a mirror of it somewhere else.
I'm still sad the lesson learned from this was "don't allow people to unpublish packages" and not "you should vendor your dependencies".
> Even if NPM did allow developers to unpublish any package, there's nothing stopping me from downloading a tarball of your package as soon as you publish it, and hosting a mirror of it somewhere else.
As far as I can tell, NPM does not enforce any limitations on the license of published packages; I would not assume you can legally do this unless you have verified the package has been published under a license which permits such actions and which you are certain you understand.
Weird downvotes! From the source: "Your Content belongs to you. You decide whether and how to license it. But at a minimum, you license npm to provide Your Content to users of npm Services when you share Your Content. That special license allows npm to copy, publish, and analyze Your Content, and to share its analyses with others."[0]
I'm not a lawyer, but in my best judgment I see no reason to assume an NPM package can continue being used after it is taken down -- you need to actually evaluate the license it's published under to determine that. If I'm mistaken, I'd love to see a source establishing the contrary.
[0]: https://docs.npmjs.com/policies/open-source-terms
Just to be clear: I'm not planning on running an NPM mirror. My point is that if you're not sure you want your code to be publicly available, you should perhaps consider not publishing it to a public registry in the first place. Everything published to the internet can be downloaded and archived. If I publish a blog post I assume it might be cached by a search engine, or snapshotted by archive.today or the wayback machine.
Oh, I agree you shouldn't publish if you aren't sure your code should be public! On the flip side, a package manager could easily address this by requiring code to be published under a limited selection of licenses that actually ensconce those rights, rather than treating it like the wild west as NPM chooses to do.
> As far as I can tell, NPM does not enforce any limitations on the license of published packages
I once saw a package on NPM that had a commercial license. It even had a link to its source on GH.
And a note that if you used the package you needed to pay up.
Sure, that's true, but good luck suing a Chinese NPM mirror or a Russian NPM mirror.
When you upload something to the internet it's there forever. The only way to ensure something is not on the internet is if you don't post it (and even then...). People are destined to learn this lesson over and over again.
It works both ways, if you want something gone, it will remain forever. If you spend hours searching for something and finally finding a post on a forum from 2007 where someone goes "this fixed it for me: <link>", that link will never work and won't be archived by archive.org.
Are you really excited to use a Russian NPM mirror that is providing tarballs and ignoring copyright as your dependency vendor?
Maybe something like this should put up big siren noises that it has so many dependencies. Can -anything- have that many dependencies? seems like a check they could build in and not let it go into the npm packages without a review.
So just make a new package per dependency then. And have each version of that package depend on each version of the original package.