Did you npm install today? I know I did.
npm is now an inseparable part of most JavaScript developers' day to day development cycle.
I find myself using npm more and more every year. With the help of projects such as webpack, we’re able to use npm in any JavaScript project. npm is no longer just a “Node thing.”
It’s a “JavaScript thing.”
And up until recently npm was universally loved. But a recent event challenged that unconditional love.
A cloud in the sky
On March 22nd, 2016, one developer named Azer decided to unpublish all of his packages from the npm registry. More than 250 packages in total.
No one would have cared or noticed unless one of the unpublished packages happened to be a dependency of a dependency of a little project called Babel.
Yes, that Babel.
If you’ve missed the drama that was npmGate, The Register has you covered.
I would like to focus on a few things a lot of people including myself, realized that day regarding their beloved npm CLI tool.
Every one of the following points was common knowledge to some, since all of which are well documented and publicly available on the npm website.
However most of us didn’t care up until npmGate hit:
- npm, inc is a privately held company. It’s the company that hosts and maintains the npm CLI tool.
- npm has a package name dispute policy. npm package names are global, whoever publishes a package under a certain name first, captures it. npm, inc. reserves the right to manage npm’s global namespace according to its policies.
- npm allowed users to unpublish packages at will, regardless of how many other packages depended on them. This was the first thing npm fixed shortly after npmGate took place.
- Once Person A completely unpublishes a package, Person B can publish a completely different package with the same name. The only requirement is that the new author will advance the version by at least one patch version (0.0.1 -> 0.0.2). This was also shortly addressed after npmGate.
What followed all over the web was a long discussion about the various pros/cons and risks/benefits of each one of the points above. And as you might have guessed, the internet has a lot of opinions.
But before we get into the present and the future of npm, let’s talk a little bit about the past.
npm, the little package manager that could
Like a lot of great things in this world, npm started out as a side project.
No one asked for it. But someone decided to build it anyway. And we’re all glad they did.
That someone’s name is Isaac Z. Schlueter.
Isaac was just a developer who got into Node.js at a very early stage and went all in.
He became a Node.js core contributor early on, and decided node needed a decent package manger.
“…I wrote npm because I'd seen module packaging done terribly, and done brilliantly, and I wanted to make sure that Node didn't end up with something like Pear. Even CPAN, wonderful and impressive as it is, had some problems that I thought we could learn from.” - March 26, 2013, Isaac Z Schlueter.
When Ryan Dahl the creator of Node was hired by Joyent, he personally asked Isaac to join him. There, the two continued to work on Node, and Isaac continued to develop npm as well.
When Ryan eventually left Node.js and Joyent, Isaac was named the project’s new lead. He faithfully carried out this duty between 2012 and 2014.
Isaac is currently still the #3 all time top contributor to Node.js. Surpassed only by Ryan Dahl and Ben Noordhuis.
When Isaac left Joyent on Jan 2014, it was to co-found a startup together with his long time friend Laurie Voss.
I’m pretty sure you can guess which company they ended up founding.
How npm, inc. Came to Be
I don’t have the “inside scope”. Like you, I’m an outsider looking in.
But I was able to find something that clued me in. Something that inspired me.
I found an old blog post from mid 2011, 2.5 years before npm, inc. was founded. In his post, Isaac is detailing the future he sees for Node.js and himself, with uncanny accuracy.
The context for this post was Isaac’s response to recruiters who were trying to recruit him for various companies which he refers to here as “XYZCorp”:
”I am working on Node.js and npm. This is the technology that has already displaced Python and Ruby as the hot new high-level language platform of choice; within 5 or 10 years it’ll join the likes of .NET, Perl, PHP, Java as the go-to platform for enterprise development (ie, “serious business”) and new college grads. But there is so much more work to be done!
…When and if I leave Joyent, it will be to do some other work focused on npm and Node.js, probably as part of my own company. The only way that XYZCorp could ever recruit me is if they recruited me to do that.
…Altruistically, I want what’s best for the Node community, because I feel connected to it. Selfishly, I want to be one of the names that is remembered as part of a major revolution in software development. If you can show that these two goals are better served at XYZCorp than at Joyent, then let’s talk.”
August 31st, 2011, Isaac Z. Schlueter on responding to recruiters.
When Isaac wrote this over four and a half years ago, Node.js was somewhere between versions 0.4.0 to 0.5.0.
I remember when I was working for a .Net company at the time. I was just telling everyone about this “Cool new schtick” that allowed you to run JavaScript on the server.
No one there has even heard of Node at that point.
But Isaac was already seeing the day companies like PayPal would move to Node.js.
I’m going to be overly simplistic here for a minute. I’m sure Isaac had plenty of ups and downs from that blog post until now. But here is my take:
I can’t help but wonder if everything that happened from that blog post up until Issac founded npm, inc. was just an implementation detail.
When that level of determination and clear focus meets the right set of skills at the right time, amazing things happen.
npm and npm, inc. Present Day
Now that we have some context about npm and npm, inc. I’d like to talk about some of the concerns and questions I’ve heard floating around post npmGate.
Since I can’t point out exactly when and where I’ve heard these, let’s just say I’m dealing with a split personality disorder.
Just to be clear, I’m in no way affiliated with npm, inc. and the following views are mine and mine alone.
Will npm, inc. interests as a private company eventually hurt or neglect npm the open source project?
In this specific case, I think the answer is 100% NO.
Corporate ownership of an open source project is always a double edged sword. It’s just a matter of which end is sharper. And in npm’s case it’s clearly the right one.
Some corporate sponsorships do more damage than good, while others allocate significant resources which help support the project and take it to new heights.
In npm’s case, npm IS npm, inc. It’s the foundation of the company and everything it does. Their futures are completely interwound.
That’s enough motivation for any company to take their open source commitment seriously.
And as I tried to illustrate, the founders know a thing or two about managing and contributing to open source projects.
Allowing uncontrolled unpublish of modules was dumb
I think everyone agrees on that one. It was the first thing npm addressed post npmGate.
npm currently only allows to unpublish packages which no other packages depend on. Effectively killing the unpublish feature for any meaningful package.
For more details, here is npm’s explanation.
Will npm transfer my package name due to trademark issues?
I doubt it. As npm clearly stated, the decision which ignited npmGate to transfer ownership of the kik package from Azer to the Kik chat app company was purely based on npm’s naming dispute policy.
This wasn’t a legal issue according to npm, and I believe them. If nothing else only because Kik had such a laughably bad case.
And I’m pretty sure the whole trademark thing backfired for Kik anyway, now that there are lovely packages such as “kik-rtards” in the registry.
Will npm transfer my package name for any other reason?
This is where things get a little tricky. Here is literally the tl;dr from the npm name dispute resolution document on the date of this publishing:
- Get the author email with
npm owner ls <pkgname>- Email the author, CC support@npmjs.com
- After a few weeks, if there's no resolution, we'll sort it out. Don't squat on package names. Publish code or move out of the way.
Make of it what you will.
I personally hope that npm, inc. will never forcefully transfer a package like they did with Kik and Azer ever again.
But they reserve the power to do so if they choose.
You can check out the dispute resolution document for yourself in case it updates or you want more details.
npm is not safe!!!!
There are 2 reasons why people might think npm isn’t safe. Let’s tackle both:
1. A malicious package can replace an unpublished one
npm addressed this issue. When someone unpublishes a package, a replacement “security placeholder” package is put in its place.
This is a little cumbersome and feels more like a patch than a fix. But considering npm wishes to maintain its global namespace and allow unpublishing, I’m not sure there’s a better alternative.
2. Someone can publish an evil worm that will self-install in all npm packages!!@#@!#!#!
Theoretically possible, but highly unlikely.
I’m referring to this supposed vulnerability.
Running someone’s else’s code is an inherently dangerous thing. Using a package manager or otherwise. Open source mitigates this by having everyone see everyone else’s code.
Malicious packages could be potentially introduced to every package manager. But practically they don’t really exist.
Maybe there’s some psychological reason that explains why this doesn’t happen more often. It might be that developers don’t want to screw over other developers. Or perhaps developers are simply afraid of the retribution of their peers.
Bottom line, npm is just as safe as any other package manager out there at this point.
JavaScript is growing, and npm will grow with it.
To sum things up, npm is the heart of the JavaScript ecosystem. It makes sure our modules end up where they’re supposed to. Pumping them out as needed.
As JavaScript continues to grow, npm will grow with it. Supporting large enterprises, small startups, and tiny side projects. Being used for anything from web apps to robotics or home entertainment systems.
And although npm might occasionally skip a beat, our JavaScript ecosystem is a much better place because of it.