Rage-quit: Coder unpublished 17 lines of JavaScript and “broke the Internet”
arstechnica.com
arstechnica.com
Is it the case that projects on npm refer to the original authors' repositories always? That sounds very unreasonable.
For instance, I'm pretty sure that's not the way it works with, say, yum. Red Hat hosts some packages on its servers, but that's not where the projects' code resides- the maintainers have their own repositories and in fact the rpm packages often have different maintainers altogether. So if a project goes down, the package stays on the RH server and you can still get it anytime you want.
What I'm really asking is: why is it not done this way for npm also?
> "Why did everyone else's code refer directly to that guy's repository, and not some centrally-maintained clone thereof?"
I believe the repository, which is on github, did not change. Quoting this article: "And he used that command, deleting 273 modules he had registered in npm (though he left the modules available through GitHub)."
Instead, it was the central registry which changed.
It looks like npm lets others manage "their" parts of the registry, unlike Red Hat which is in complete control of what they release.
> "What I'm really asking is: why is it not done this way for npm also?"
My thought is that it's cheaper. Otherwise each new project in the registry needs an employee to manage it. There's also a long tension going back to at least the WELL's "You Own Your Own Words" of who controls the content provided by members. If something starts off as "we control everything you do" then that's going to be viewed with suspicion.
That's because 1) npm isn't immutable. The owner of a package can delete the package on npm. 2) Developers (re)-download the entire dependency tree prior to build. A missing dependency down that tree will fail the download.
> Why did everyone else's code refer directly to that guy's repository, and not some centrally-maintained clone thereof?
The "repo" everyone's talking about is npm. npm is the centrally-maintained storage. What happened is that the guy pulled out his modules from npm.
> So if a project goes down, the package stays on the RH server and you can still get it anytime you want.
That's what everyone wishes for npm actually, for that package to live forever once released to npm. Sadly, again, npm isn't immutable.
But again, there's this suggestion of "bundling before release", making a dependent self-contained. That way, in the event a dependency is missing, the worst it could do is just paralyze the dependent's next build but not make the existing build unavailable.