It's insane that NPM allows anybody to just take over a module name if the original is unpublished, without even a warning to users.
That's the part that really got me. Questionable dependency practices is one thing; but running whatever JS when a package is installed, with no warning whatsoever, is probably a very bad idea.
A year ago I never ever would've thought I'd be happier writing C than NodeJS, but here I am. Weird how that works.
It destroys days of development.
> This is the sort of amateur behaviour that is emblematic of the entire nodejs community.
This is pure mudslinging
https://www.reddit.com/r/rust/comments/4bm3rk/how_would_crat...
That's a strange thing to say considering how insanely complex modern hardware and software are. While the NPM setup is indefensible, there are countless ways a stranger can prevent your deployment, if that stranger works at Microsoft, Intel, or the manufacturer of any production hardware component. OS bugs, driver bugs, compiler bugs, and hardware/microprocessor bugs are a thing. At any point, you are dependent on the work of many thousands of strangers, no matter how perfect your decisions are.
Even if I have a dependency locked down in my NPM shrinkwrap file, it can change underneath me? That is pretty absurd and gives me zero confidence in my packages. It means I MUST commit them to source control or risk having my project completely broken some day.
I thought for sure that since NPM removed the ability to re-publish the same version of a package with different content that they also wouldn't let you remove versions of a package. It also means you should never user the "^" version specifier or risk downloading some completely different project.
They do have a "warning" at https://docs.npmjs.com/cli/unpublish: > WARNING > > It is generally considered bad behavior to remove versions of a library that others are depending on!
Seriously, what good does that do? Nobody takes warnings seriously.
If you depend on a version range like ^1.2.3 or ~1.2.3 its a different story, of course.
Moral of the story is imo always pin to exact versions and use shrinkwrap for production apps.
EDIT: This may not be true .. see below.
That's not true. I thought it was but it's not. That's the terrible part.
To demonstrate with one of the packages that was removed, run:
$ npm info andthen
You'll see that versions 0.0.1 and 0.0.2 were published at one point. However, for "versions" it only mentions 2.0.0. And of course, if you run:
$ npm install andthen@0.0.2
It blows up in your face.
That's a reasonable excuse in the 90s, before automatic updates over HTTP were common. Our industry now has decades of experience securing HTTP updates and package managers, with various Linux solutions demonstrating good practices.
And people wonder why big enterprises are scared of touching open source stuff.
some open source stuff. Most enterprises dig distributions, especially with LTS.
It is insane that modules don't have signatures (that are actually verified, of course). Because npm can feed you basically anything.
It's not a problem that something else gets published under the old address. It's perfectly natural. The real problem is the trust model - that new content's accepted without even warnings.
My semi relevant tweet, it's just asking for it with that warning