NPM Packages Sabotaged

> The way the Node community works

He clearly doesn't know that swift, php, java, c# and all the rest have their own package managers that work similarly. His sentiment about not vetting updates is reasonable, but why trash node like some kind of elitist who knows just oh-so-much-better?

@Ben Doesn’t Node use packages to a much greater extent, i.e. for functionality that’s built into the standard library for those other languages?

He clearly doesn’t know that swift, php, java, c# and all the rest have their own package managers that work similarly.

Yes and no.

Yes, on the surface, NPM is really no different than Python’s PIP or .NET’s NuGet.

(Also, given Gruber’s tinkering with Perl, he’s probably rather familiar with CPAN, one of the oldest package managers in the same vein.)

But in effect, it absolutely is. A big part of that is that the JavaScript standard library is very limited. This is compounded by a culture of writing very small self-contained packages, such as having an is-odd package that you might find amusing until you realize that other packages do, in fact, depend on that. As a result, you can easily end up with hundreds, perhaps thousands of transitive dependencies, even if you just have a dozen direct ones. You’re not going to vet all that. You’re not even going to know what many of those packages are for.

This is then further compounded by a “just upgrade to the latest minor update; it’s fine” culture (specifically, many a package.json references packages using caret ^ syntax, where you will get any upgrade as long as the major version stays the same). Even if you don’t do that, some of your dependencies probably do. This sounds great as long as 1) all authors can be trusted not to have breaking changes in non-major updates (already iffy), and 2) all authors can be trusted not to be malicious (good luck with that).

So NPM created the “solution” (to a problem they had created in the first place) of package-lock.json, where your transitive dependencies are locked to a specific version.

So, no, other ecosystems don’t have the issue to anywhere near the same extent.

Snark is part of John’s brand, but he’s not really wrong per se.

@Michael Tsai - Node is just a javascript runtime and has the standard library of javascript. IMO current JS has a lot of the same features languages that Swift has, from a high level. Even moreso if you are using TypeScript.

As for things built to run on node using packages to a greater extent, this is true but the web has always moved much faster and more collaboratively than any other framework/runtime. This was true before Node and npm arrived, but NPM has certainly made it easier to use packages and that's why there's tons of neat ones out there that simply don't exist for Swift.

As another counterpoint... Opening a basic Statamic (php) project and observing that there's almost 60 dependencies included from composer. I don't have an umbraco project handy, but it's probably a similar amount of dependencies from NuGET. I guess both of those pieces of software can be written off as invalid too, because they're "slurping" in dependencies.

> As for things built to run on node using packages to a greater extent, this is true but the web has always moved much faster and more collaboratively than any other framework/runtime.

Maybe — but this is an example of when "move fast and break things" isn't good.

>NPM has certainly made it easier to use packages and that's why there's tons of neat ones out there that simply don't exist for Swift.

Yes, and also, tons of outright malicious ones, too.

> Opening a basic Statamic (php) project and observing that there's almost 60 dependencies included from composer.

How many of those are actually from different teams, vs. how many are from one and the same team and really just subsets of the same project? IOW, how many distinct authors would you have to vet?

> A big part of that is that the JavaScript standard library is very limited.

Is this really that much more limited than what's available in Swift?

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects

This seems like an outdated notion. I am continually impressed with what they have added to the JS standard library.

> such as having an is-odd package that you might find amusing until you realize that other packages do, in fact, depend on that.

I think people in the web world like to have fun.

> Snark is part of John’s brand

It's really lame imo.

Actually, this is a problem with using 3rd party libraries in general.

Option 1: you write a library that does everything. Cool, but then it's so big and complex no one, except those working on it, can read and understand it.

Option 2: you write a small library that does the one thing you need. It's easy to read, and modify. People like it, but all just want to add just one feature (each).

Library users often choose libraries that follow option 1. After all, if it includes everything, then most likely all their needs will be covered, and the thing about the future is that it's hard to predict. But then it's too complicated to read / understand fully, so they punt, and hope others do it for them.

In the olden days, option 1 wasn't an option. Computers had too little memory. So people wanted small focused libraries they could understand, and perhaps even simplify/optimize. Even if computers are more powerful these days, human minds aren't.

I'm a weirdo, but I'm still not convinced that libraries were a good idea. 3rd party well documented code, yes. But libraries? Perhaps not, or at least, perhaps only in moderation.

[…] Summary from Michael Tsai […]