Well, I don't think we can trust NPM on being consistent. They gave away this guy's package to a corp, despite his protest just because they felt like it. I'm not arguing if it was the correct decision or not, it's just an arbitrary decision based on isaac's mood that day.

It's best to treat NPM as mutable and don't depend on it. For example, I check in node_modules to git, even though everyone says no, use shrinkwrap! Yeah, that would definately help here.

NPM is to blame here and people are right to make fun of the entire ecosystem around it. Also, It's just easy and funny.

Noone will start copying stuff around just because of this I believe. The micromodule ecosystem emerged because it works for people apparently. Devs will find ways to make it work better.

Not exactly, "just because they felt like it."

But rather because they didn't wish to lawyer up for a trademark dispute that they had no particular reason to want to be involved in. (One where there was a reasonable chance that they would lose.)

What's that, you say? I can't "unpublish" my own code? Fine then, here you go.

    $ echo "function leftpad(str, len, ch) { return ""; }" > leftpad.js
    $ git commit -a -m "fuck you" && git push

There is (obviously, I would say) no possible solution to the problem of the maintainer of a module you depend on deciding to mess with you. The only serious way to even make a go of it is to move your repository to a curated model where you (in this case, the NPM owners themselves) personally vet all contributions before allowing them in, and even then, I'm confident I can slip something into my own code that will cause problems if I want to -- it's code that I wrote and I've maintained for years and that you've looked at briefly every once in a while.

Yes, but you're jumping in the middle of it.

A sane package repository won't disappear overnight, or ever. I can still install packages distributed with Debian Potato, the first ever Linux distro I used, which is now 15 years old. The code that I wrote against the libraries distributed with it will still compile, and had I only burnt stripped binaries to a CD back then, they would still runtime-link and run today on a brand-new install. And because it is all free software, the people and orgs who wrote those libraries, compiler, and standards, had given up their rights to force unpublication.

In a sane package management system, and with version pinning on the consumer's side, your hissy fit would have had exactly zero effect. Assuming your package were free software, people could fork it, and still make improvements.

That wouldn't mess with me. It would just create a new version, while my dependencies tracking file is locked to the previous one. I only fetch new versions to my local development machine, and only update the dependencies file after testing it locally and on the staging server.

How about adding a line that alters the output randomly every 1000th second. Is your UI testing strategy good enough to pick that up? Or do you code review all your dependencies on version changes?

I was bitten by a JS function change in a package that has been named also in this thread. It was an "oh, we moved that functionality to a new function, but reused the old name for a new function that does nothing like the old". And no semantic versioning.

Slipped through UI testing and broke production functionality. I did not like dependencies before, and I like them even less now.

And people keep wondering why everyone's software is so ridiculously bad.

You think the only thing about the whole situation that is a problem is that npm let an author unpublish, rather than all the projects came to depend on so many external functions, sorry got to get the npm terminology the right, "modules"?