"Like" Driven Development

Dependency Management

Anybody who has done any web development over the past few years has likely used npm. On the surface, npm is a really popular Javascript package manager with some really great content.

npm killing it

Several other Javascript package managers exist, but they're either hipster npm interfaces, or dying garbageware.

Social Network

What makes npm special, is that literally anybody can publish whatever Javascript they want, and it is immediately available to the public.

So like similar platforms such as Twitter, Facebook, Linkedin, Reddit, LiveJournal, Google+, HackerNews, etc, there are predictable classes of content available.

quality distribution

The Good

There is plenty of great useful software available, written by experienced Javascript scholars, and peer reviewed by respected open source foundations.

The Bad

But the bulk of the content is code trash written by excited code academy graduates marketing themselves to FAANG for a six figure salary.

The Ugly

And then there's some evil shit written by Putin's henchmen that tries to trick you into voting for Donald Trump.

The Problem

The issue here isn't the ugly stuff, and obviously not the good stuff. It's not really even the bad stuff per se.

The issue is the system encourages "influencers" to publish as much as possible, and followers to consume as much content as possible.

This leads to massively bloated dependency trees full of libraries owned by people that really don't give a shit unless they're getting likes and followers.

A (Likely Outdated) Example

The popular webpack software depends on a 3rd party library called is-odd.

The is-odd library does exactly what you expect:

return (n % 2) === 1;

It seems the folks at Webpack find this

// npm install --save is-odd
const isOdd = require('is-odd');
return isOdd(5); //true

To be more succinct than

return (5 % 2) === 1; //true

Or perhaps they prefer that an undocumented exception is thrown if the input is not an integer. I don't know. But their design opinions are all fine so long as the system works.

But the problem is Webpack now depends on the Is-Odd author John Schlinkert, but John Schlinkert has no reason (outside of github internet points) to be dependable.

By including this library, Webpack is no longer in control over the odd-checking logic in their system.

John Schlinkert

So by depending on is-odd, there is now an external dependency on some pseudo random guy (or gal, but in this case guy) from the internet.

John Schlinkert

Note: I have never met John, he's probably a great guy.

Note deux: Looks like his Twitter feed has taken a right wing political turn since I started writing this. I personally enjoy the tweets but I bet a lot of Javascript developers would rather cancel John instead of depend on him.

John Schlinkert does not owe you shit, nor does he owe the folks at Webpack shit. He is not obligated to maintain his library, and he's not obligated to take pull requests from someone who does want to maintain it. And you can't tattle on him to your boss if he breaks one of his million shitty packages. John Schlinkert could literally push a minor version to IsOdd tomorrow which stops returning the odd-ness of integers and instead returns random internet cat pictures.

And your program will install it the next time you run npm update and you won't notice.

So why are you including John's code into your company's source?

Timeless Examples

In April (2020) Robert Katic's library "IsPromise" which contains two lines of code, accidentally published a version that wasn't properly es6-ified, screwing over the 3.4 million projects that depend on it.

Last year the lone maintainer of core-js was sent to Russian jail for 18 months for vehicular manslauaghter leaving nobody access to his project that has 26 million weekly downloads.

A couple years prior, Theodore Dubois didn't thoroughly vet someone before giving maintainer status. And that person sneakily added code that steals cryptocurrency (instead of doing whatever event-stream does)

Around that same time the popular package eslint was breached because the maintainer was using recycled credentials

In 2016 the infamous "lpad" fiasco was caused when "Kik" stole some poor contributor's library name.

And just recently, the maintainer of the software I use for this site decided to fight at the COVID front line over maintaining his free library, so now I'm not even going to bother writing PRs for small things I would added.

Conclusion

The issue is getting less bad as the Javascript ecosystem and community are reacting to this issue.

NPM now automatically "audits" your dependencies, and people can no longer unpublish things, and there's package lock.

And there is something to be said about having a super accessible platform that engages zillions of enthusiastic new developers.

And the issue exists to certain degrees in other dependency managers.

I don't actually have a conclusion for this. What do you think? Leave your comments below and please join the non-existent mailing list, and follow me on twitter and donate to my Monero wallet.