All Javascript developers might have used npm at some point in their lifetime. npm is the default package manager for node.js. For those who don’t know what npm is, npm – short for Node Package Manager is a package manager for the JavaScript programming language. npm, Inc. is a subsidiary of GitHub. npm can manage packages that are dependencies of a particular project, allowing users to reuse modules or pieces of code that are already distributed and present in npm’s remote registry. A package, that your project depends on, can itself have a dependency on another package, which has a dependency on another package and so on.. But the good thing is, with npm you don’t have to worry about the other dependencies, npm handles it for you and does all of it for free.
Now that we know what npm is and how it works, let’s see what happened on 22nd March 2016 that caused highly used packages like React, Node, Babel etc to break with multiple JavaScript programmers around the world receiving a strange error message when they tried to run their code.
Background
Azer Koçulu is an open-source developer who had been publishing and maintaining his packages on npm for other developers to use and include in their packages. Out of his ~270 packages on npm, one of them was called kik, which helped programmers set up templates for their projects.
Kik also happens to be the name of a freeware instant messaging mobile app available on both android and iOS, from the company Kik interactive based in Ontario, Canada.
The E-mail
One fine day, Koçulu received an email from one of Kik’s patent agents, asking him to rename his package called kik as they were planning to publish a package on npm and Koçulu’s NPM package could have caused a confusion. The entire e-mail thread can be found here but to give you the gist, Azer declined Kik’s request. Bob Stratton, Kik’s patent agent, put forward Kik’s request for the name kik to NPM team, again citing the company’s trademark and potential confusion.
NPM decided to side with Kik and took kik away from Azer, handing the name over to the company.
The Liberation of Modules
On finding out that NPM had sided with the corporate, Koçulu wrote to NPM saying that he wanted all of the packages he had published on npm taken down, or they should let him know how he can take them all down quickly. Two days after Koçulu sent this email, on Tuesday 22nd March, Programmers all over the world were left staring at broken builds and failed installations. Out of the multiple lines of errors, one of the lines read as :
npm ERR! 404 'left-pad' is not in the npm registry.
What this error means is that, the code that you’re trying to build/run requires a package called left-pad that does not exist in the npm registry (the one that we talked about at the start of this post) . Where did this package named ‘left-pad’ go?
It seems Koçulu did exactly what he had written in his email, he unpublished all his packages from npm and left-pad was one of the packages published by Koçulu. He wrote a blog post explaining why he had unpublished all his modules. “This situation made me realize that NPM is someone’s private land where corporate is more powerful than the people, and I do open source because Power To The People,” Koçulu said in his blog.
Un-Un-publishing left-pad
To fix all the failing projects and packages around the world, on 23rd March Laurie Voss, CTO and cofounder of NPM, decided to do something unconventional and restore the unpublished left-pad 0.0.3 that apps required on NPM. His tweet read “Un-un-publishing is an unprecedented action that we’re taking given the severity and widespread nature of breakage, and isn’t done lightly.”
With that, all the failing packages started building and running successfully thus fixing the internet. Laurie also said “Even within npm we’re not unanimous that this was the right call, but I cannot see hundreds of builds failing every second and not fix it.” while I agree with him on this, it also made me wonder and think about a couple of things that we are gonna talk about next.
What was left-pad ?
Let’s have a look at the contents of left-pad and try to figure out why were so many projects all over the world making use of this package.
left-pad, as the name suggests, pads the lefthand-side of strings with characters or spaces and the entire package contains only 11 lines of code. 11 lines . This is left-pad in it’s entirety.
module.exports = leftpad;
function leftpad (str, len, ch) {
str = String(str);
var i = -1;
if (!ch && ch !== 0) ch = ' ';
len = len - str.length;
while (++i < len) {
str = ch + str;
}
return str;
}
Why did this cause so many packages on NPM to break?
React, Babel, and a bunch of other high-profile packages on NPM broke on March 22nd 2016 because all these packages and projects took on a dependency for a simple left padding string function on the package left-pad. Most programmers, who were facing these build errors, might not have even heard the name left-pad but their code was breaking because their apps were dependent on some packages, which in turn were dependent on some packages and down the line, one of the dependencies might have been left-pad.
Ideally programmers don’t have to worry about all these dependencies as NPM takes care of this for them and has always been reliable in doing so. In this case though, the package was unpublished, and there was no way npm could find this dependency, thus causing these unforeseen errors.
Why did so many packages depend on left-pad to, well, left pad?
With only 11 lines of code, left-pad is just a function exported as a module that so many packages took a dependency on rather than the developers of those packages writing a basic function to left pad by themselves. It would hardly take a few minutes for a well versed programmer to write such a function and yet they decided to depend on another developer for this. Tying together multiple third-party dependencies or packages and developing a project with minimal code should not be considered ideal. Any issues with the third-party dependency would cause your code to break and you’ll be dependent on another developer to fix their work so that you can get your project to start functioning properly again. This has to be considered a serious issue when web services like Facebook, for example, become indirectly dependent on code written by other programmers that don’t even know the impact their code might be having down the line.
How many dependencies are too many dependencies?
Have we become so lazy that we require a package to check if an object isArray? The package contains one line of code and is downloaded 39,001,468 times weekly as I write this post. Do we really need to publish packages containing just one function? And should we be creating dependencies on packages for few lines of code that we can easily write?
I think this method of software development needs to change and dependencies should be created on ‘libraries‘ that provide an array of interrelated complex functionalities. Why would you import a package to add, subtract, multiply instead of importing a package that provides all Math functionalities?
Ease of writing code by adding dependency after dependency for minimal functionality, leads to difficulties in maintaining code when you don’t have control on third-party packages and increases the points of failure.
There should be least amount of dependencies and only on well-known libraries that offer many complex functionalities that would be hard/time consuming to write by oneself so that the risk of errors are worth it.
To all programmers, all I say is that in the near future if there is a small and simple functionality that you need to use in your project, choose to write a few lines yourself rather than add a dependency on an unknown package. Take the frustrated programmers as an example who chose to directly or indirectly depend on 11 lines of code instead of writing it themselves.
I have not written this blog to discuss the ethics/legality of the actions taken by Kik, NPM or Azer as I am no expert in that area and my opinions on that would not be valid.
I have written this blog to discuss how the methodology of depending on so many small APIs( should 1-liner functions classify as API? ) can be disastrous and to re-think this way of programming.
I’d also suggest you to go through this reddit post to see what other programmer’s opinions are on this event.
All of this blog’s content comes from google search, reading articles etc and I may have been wrong in some places, please reach out to me if I have missed something.
Note: The featured image is by xkcd and all credits go to the artist.
I hope you enjoyed reading this post!
Thank you.
Top comments (30)
I don' think that's the real issue here. The problem is that the whole javascript eco system is built and used in such a way that someone can break the internet by removing a 12 line package from a website. The reasons why he did that are irrelevant.
This has nothing to do with Copyright, which isn't applicable at all. And it's not "illegal" to not remove something with a name conflict on the Internet. Trademark law is a civil matter, and there are a lot of complexities to what extent a company is protected. I think NPM should have waited for a letter from a lawyer and given the author a chance to legally respond. The whole "don't want to get lawyers involved ha ha! so please take away someone else's work" shouldn't really fly. It probably would have ended with the same result, but at least there would be a proper process around it.
Exactly. I'll add my perspectieve as a root comment.
It's a shame this nonsense is the first comment on here. We get that you were in the same situation as kik and you won you so you think you were right. You weren't, and neither was kik. You don't magically get to use your name everywhere because you are a company. Might does not make right.
And yet you are insisting that the company that has trademarked kik in one country can ignore all trademark/copyright laws in the rest of the world, just because they are in another country ...
As far as I understand, Fernando, he used the name Kik without knowing there was a company in US that registered the name. Actually, there are a lot of companies called Kik in the world !! That kind of short names are pursued by companies, and they registered it. This patenting existing names is quite a issue, worldwide. Azer is Turkish, that Kik is US (there are a Austrian, a German one, etc), Internet is international. Consider that a lot of names of packages are probably the name of some company on the world. And if a much bigger company with more lawyers wants the name Kik for another package, NPM will reassign them the name? We can be changing names of packets just because a company decided to adopt a name, it would be a never-ending mess. So, for me, declining such kind of request was the logical step to take, and fulfilling it was a failure from NPM. Maybe they had no option due to the laws of the country they are in, which shows that this is a problem to be solved: in laws and/or software structure.
And I understand perfectly the feelings of the developer: so many people working for OpenSource make the base of what is programming today, and if a company comes with a request, the choice of the developer is disregarded, undone, and even twice.
But well, yes, the point of this article is how code is build and related.
Thats a false implication. He did understand copyright, the kik lawyers tried to conflate patents, trademarks, and copyrights. His kik package predated the kik company and therefore his claim to the copyright for his filename was legitimate. Npm further broke the law itself by republishing his package without consent as it had been previously litigated that "open-source" does not mean free or free use. The material still belongs to the owner and can only be used or published as licensed. In this case as part of another module and not as a package itself.
Software and human relationships and emotions are intrinsically tied in a forever loop.
Regardless of who may have been right or wrong in this case, it demonstrates the delicate nature of this complicated thing we've built.
This has nothing to do with copyright law. In your case your code is copyrighted so someone who is not the owner put it on pypy. But in kik case there was no copyright law broken. The issue was a trademark and he didn't lose a lawsuit but npm sided with the company which was wrong. It was wrong because you allowed to use the same name for non-related thing. For example in Germany if you say kik to anyone, no one would think about chat program from kik.com but they would think about kik.de (so 2 different companies use exactly the same name).
I wonder if Indonesia government will sue us for using name Java or Java Script , since Java is the name of their island... #eh..
Holy s**t man, stop with this trademark nonsense. It's clear you understand little to nothing about trademark law and it's intricacies. Please argue from a perspective that you understand. Reading your comments is painful. One moment "I am not a lawyer" but then you continue to argue as if you are.
I've always been a bit confused about this. I know it is only 11 lines, but... the idea that everyone should write those 11 lines instead of importing left-pad seems like the exact wrong lesson to learn here.
I am sure if we look hard enough we can find plenty of other 10-15 line functions that solve common problems. Do we believe that all "experienced" JS programmers should write their own versions of these? What about inexperienced programmers? Should we let them write 40-line versions?
It seemed to me that left-pad did precisely what we want open-source software packages to do: solve common problems so that the rest of us don't have to re-invent the wheel. The fact that it is "only 11 lines" is irrelevant. If it were 50 lines, and still broke the internet, would we all just have said "¯\_(ツ)_/¯ nothing we could have done differently here at all!"?
Exactly this. I remember when this happened a bunch of people went on to "lament" the downgrade of today's developers - because they didn't want to do this stupid function. Apparently being able to
left-padmakes one a "true developer".Obviously dependencies are bad, which means the real question here is why such a trivial function is not in the standard library in the first place.
Let give some background for myself to help you get context. I've developed as hobby before internet and then I did .NET C# for a long time sometime until 2010. I was mostly involved with enterprise software.
Personally, I would feel ashamed to publish such a package. It feels incomplete and even I started this with bigger dreams, most probably it will never receive a 1.0 version. I would rather gist/block my amazing code for inspiration rather than doing this. I'm writing this to help you connect with the perspectieve that is driven from my background. I hope this help you give context for the following.
The concept of package repositories is amazing. But, for my background, to add a package dependency, the package needs to offer something substantial. I don't think that there is any gain here when 10line code packages that don't even have a major verion are linked everywhere. It is a very volatile situation.
When a package is delivered as binary, then a small referenced package is of a lesser problem because the deliverable includes the compiled code. For example in .NET, the only potential problem is that if 2 different packages have the same dependency then 2 dlls with the same name lead to problems at runtime. But, outside of the compiled world, there is the concept of builing everything which multiplies the potential problems of this approach. Because, if my package needs to be built, then my dependency and its dependencies need to be built as well. Everytime I try to work with node and use a tool, it's like it never works out of the box. Errors and warning over wring 0.0 packages etc. If you think about it, easy workaround suggested everywhere is to override the version restrictions like
bundle exe. It makes you wonder what is the point? Yes, the desciplined shops will not do this, but from all my circle, developer and especially junior ones are more and more copy/pasting from a proposed solution and if it works, then its in without evaluation. Yes there are code reviews etc but lets be honest here about how effective these are when the code is not evaluated by the whole planet. :)Call me concervative but when a package is small, I prefer the copy of it's code in a designated location with a clear mention for future maintanence but there is control. I'm glad that there is open source and I can get insight and inspiration but adding non major dependencies is already a problem in my approach, yet alone when the dependency is 10 lines. It's not worthwhile. I can always revisit this and chose the code when it is mature. But this is a nice plan that goes all to the garbage when a nice big package has dependencies to 10line of code non major versioned releases.
I believe that the current mess (not only in javascript) with non major packages is because of what I mention in the top of me being ashamed to publish a 10line package. I'm sure I'm not the only person who has this mental blocker but still wants to share. Like "viral" the outcome of the usage could be very far from my original expectations and planning.
IMO it's not a matter of how many lines of code the package is, but a matter of how well tested it's in the CI pipelines. When you see in the repo that the authors have added tests that make you happy, you may use it. If the only tests are a linter then it's time to look for a different package. The power of open source is that in fact, you can see these things and not put your trust in some entity.
But the situation in the original anecdote completely bypasses any question of testing. Because you can test a package all day long, but the core question is: What do you do if that package... disappears???
That is also part of my point. Every package is a dependency and a potential problem. You need to weight the benefits against the risks.
If for every package you need to check quality, license and lifetime then maybe the overhead is to big. If the organisation has actual oss policies, then it can get out of control. What if the package changes license?
There is a reason that in ESCROW agreement, all dependencies are included.
Agreed. This is also why many companies have started using solutions like Artifactory.
leftpad had a real influence on my approach to software development.
This post left me with some real food for thought that taught me to take a more deliberate approach with some of my choices in software.
davidhaney.io/npm-left-pad-have-we...
And the whole thing just helped me confirm that this whole industry is, in fact, kind of just a bunch of stuff tied together as best as possible. Any system can fail and we have to be able to deal with this as best we can on average. We'll never have a perfect flawless ecosystem.
I understand your point of dependencies. Check out @tinyhttp. Its built as an alternative/clone to Express completely using TypeScript as first class citizen but with the least number of dependencies. I think such projects should be really encouraged.
Secondly, Lawsuits etc can be really messy. Open Source should shy away from those. NPM did a pretty bad job there.
In the end, the
kikpackage is empty on npm: npmjs.com/package/kikAnd they published their package under
@kikinteractive/kik
npmjs.com/package/@kikinteractive/kikVery interesting read! Packages are fun and I use them a lot, but that’s why in larger applications I try to push out as many dependencies as possible.
Actually no! If npm allowed him to register the name and if npm had no such copyright checks in place then the user is not at all wrong here. He came, he saw that the name he wanted was available and he used it. He was turkish, I bet he had no idea that such a company even existed and furthermore seeing that the company didn't even use the reassigned name to publish a package simply implies that they wanted the name just to feel good about owning it. Kik should have been sued in a class action suite just to cause these turn of events.
This is why I try to host as much of the code I need as possible.
crates.io is just good, you can't pull down a package once it is published.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.