I, being a victim of the npmapocalypse, feel like I need to weigh in on the whole debacle. The community seems to be honing in on the idea that micropackages and microdependencies are generally a bad thing. I disagree on principal with this sentiment but at the same time, think we've gone a little off the deep end.
I, myself, would probably not write a one-function package or take a direct dependency on one. But, I also wouldn't write a leftpad function myself if I didn't have to. In my case I would probably just use lodash. I think packages, generally, should do one thing and one thing well. I just disagree on the scope of what that one thing is. Is the one thing string manipulation? Or is it specifically padding a string?
But anyway, I don't want to talk about that. I think that side of the argument has been way overblown. I want to address what I think is the real problem -- that someone was allowed to "unpublish" a package that is apparently heavily depended upon. I don't really have anything to say about his reasoning for doing this. That is fine if he wants to protest because he feels like he was wronged. My beef is with npm who allows such a fiasco to occur in the first place.
Unbeknownst to me, apparently npm has an
unpublish command. Forgive me for not knowing that as I assumed when I started using npm that it worked like all other package managers do. If I take a dependency on a specific version of a package, I expect my package manager to pull down the same bits everytime I ask for that version. This, to me, is the basic function of what a package manager does. It manages my packages for me. In order for a package manager to provide that service, a published package version needs to be immutable.
In the documentation for
unpublish, it even explicitly says:
It is generally considered bad behavior to remove versions of a library that others are depending on!
It is beyond me why it is so ridiculously easy for one disgruntled developer to break the internet.
Words Mean things
The word publish comes from back in the day, when publishers (like as in books), you know, actually published things:
prepare and issue (a book, journal, piece of music, or other work) for public sale.
You'll notice that there is not a dictionary definition for the word unpublish because it doesn't make any damn sense. As most of us internet denizens know, when something is put out on the internet, it is out there. It can't be taken back as much as you may want it to. Someone has a copy of it somewhere.
I get that npm wants developers to have control over their code. Control to giveth and to taketh away. But that last bit of control is imaginary. As evidenced by how quickly the original package was replaced by the exact same package (but a different developer), the code is out there for good. Just removing it from npm doesn't change that. It just breaks everyone's builds.
Allowing unpublishing so that "developers have control" seems to me to be the same broken logic that would make someone think if they accidentally published security credentials, "unpublishing" is going to save them (the other reason this feature supposedly exists).
I'm not going to delve into the security issues involved with allowing anyone to pick up and take over a package name that has been "unpublished." I'll leave it as an exercise for the reader to imagine all the horrible things that could happen if someone took over an unpublished package and published a patch version bump with whatever code they wanted.
I'm Still Going to Use npm
I really don't have a choice. I really do think npm has done great things for client side development and I generally trust that the people of npm are Good People™ trying to do the Right Thing™. I just think they are somewhat misguided, fighting fervently for a feature that I think will lead to their downfall.
The official response is kind of vague on what they are going to do to address this. I just hope they come to their senses and realize that Unpublish needs to die. The package feed should be immutable.