Telerik blogs
javascript_fragile_header

This article is the transcript of a Slack chat between Brian Rinaldi, TJ VanToll and Cody Lindley

If you're a JavaScript developer and are Twitter or Reddit at all, you've probably already heard about the huge controversy that raged over an unpublished npm module yesterday. If you haven't, here's the backstory.

In a nutshell, one developer, who had published hundreds of npm modules, was upset over npm Inc's response to a copyright infringement claim and unpublished all of his modules. Unfortunately, one of those, left-pad, which contained all of 11 lines of code, was a dependency for a large number of projects, both large and small. This meant that, by the simple act of unpublishing these 11 lines of code, builds were broken around the globe. In response, npm has since restored the prior version of left-pad, and the world moved on.

However, are there lessons to be learned from this? As fans of FiveThirtyEight, we decided to borrow their Slack chat format to give you the varying perspectives of three members of our Telerik Developer Relations team on this topic.


brian (Brian Rinaldi, Developer Programs Manager): Ok, so let’s chat about the recent controversy surrounding the removal of npm modules that seems to have broken a large number of projects, at least temporarily. I’ve argued in the past that the over-modularization and too much dependency have caused the JavaScript ecosystem to become very fragile. This is an example, if somewhat extreme, of that fragility.

TJ (TJ VanToll, Principal Developer Advocate): Can we call this left-pad-gate?

cody (Cody Lindley, Senior Developer Advocate): We’ll have to unpack what is meant by fragile. To suggest a car is fragile because a lightbulb goes out, is not exactly the correct use of that term. i.e. because a small modules fails, and it is widely used, is not an example of fragile and I actually would argue it is the exact opposite, if, by simply adding in another small module, everything is fixed.

brian: I am suggesting that many projects have added in tens to hundreds of potential points of failure into their projects, points that are not under their direct control. Often this is done in order to reach some idealistic view of modularity. If modular is good, they think, then making everything a module must be better.

cody:

brian: Ah, but that only reinforces my point. The fact that it was 11 lines of code. When a lightbulb goes out in your car, the car doesn’t become useless or broken.

TJ: But, to continue this metaphor-off, in this case the car was only broken for a matter of hours.

cody: But now, we are talking about something different i.e. module make-up. That is a different conversation, one we can have, but not the same as the concept behind npm and Unix like philosophies.

brian: I’m not clear on how it is different.

cody: The, "Write programs that do one thing and do it well.” isn’t an issue. Thus, we can talk about npm and the concept of building large apps from smaller programs. Or, we can talk about exactly what a module should be and how you depend on it.

TJ: I think we’re basically arguing how far you take that “do one thing really well” ideal.

brian: Agreed. I think the two arguments are one and the same.

cody: And I think they are very different.

TJ: In UNIX having small commands like cp and ls is really nice, but those commands are still very complex — not exactly left-pad. But let’s attack it from the latter argument then: should left-pad be a thing on npm in the first place?

cody: In principle, I think it should be. npm should be an open place where developers use, at their own risk, smaller programs to build bigger programs.

TJ: Then maybe the better question is, should a major open source project depend on something like left-pad?

cody: Ah, now we get to it. Developer responsibility.

brian: I have no problem with left-pad being a thing. I have a problem with all the projects that didn’t weigh the risk of being dependent on 11 lines of code that did something simple and not in any way central to their application. I’m not clear on what long-term maintenance was eased by relying on this project. And I’ve seen similar examples of this kind of behavior recently in other projects.

TJ: And that’s what broke most people. Most people weren’t depending on left-pad, rather, depending on something that was depending on left-pad.

cody: So, we have moved past the value of npm and the philosophy of the system. We all agree that is sound. Right?

TJ: Yes

Well wait, I think? :-P

cody: Or, as sound as it can be given alternatives

TJ: I think we all agree people should be able to put things like left-pad on npm, and that others should be able to depend on packages like that at their discretion.

brian: I’m going to use the example of Metalsmith (a static site generator built in JavaScript). Every core feature of Metalsmith is a module. Most of these modules are written by 3rd parties. All of them are in varying states of maintenance. All of them have different quality of documentation. Yet, just to access the core features of a static site generator, a user will need about 8-10 different modules installed.

cody: So, again, we are now talking about developer decisions. Which is fine, just want to be clear that we are now discussing usage not value.

brian: I think philosophically this was a “let’s make everything a module and it’ll make it better somehow” gone wrong. So, I do think there is a flaw in the philosophy to a degree. Left-pad should have been a Gist I could reference where necessary. Why was it a module? What good is it as a module?

It’s not like I am looking down the road for new left-pad features to improve my app.

TJ: I’d say this is also one of the things driving the whole “JavaScript fatigue” phenomenon too. Two years ago I got started with something in JavaScript by adding a <script> tag. Today I’m in dependency hell before getting started.

brian: It’s funny because it is true!

I’m not arguing the whole philosophy is wrong, just that we’ve often taken it to an extreme.

cody: A solution made up of smaller programs is a good concept. One has to be judicial in building that app. Right?

TJ: I’d agree there. In general I like the concept of small modules, but I agree with Brian that left-pad took that to an extreme.

Or rather, the developers that chose to depend on left-pad did.

brian: Right. You have to weigh the risk of the dependency with its value.

cody: Ok. I can live with that. People will do things they should not with any system. But, the small failed package isn’t a sign of fragility it is a sign of resilience.

This brings, us to the role of the developer. And the risk that they are willing to take on.

brian: We ridicule copy/paste, but, in some cases (like this and others) you actually would benefit from it. I get the functionality I need, one that isn’t complex or really all that critical, but without the risk of failure on a needless dependency.

cody: I’d argue that just because the package was not available does not conclude that the philosophy of npm is flawed. In fact, I’d use any 11 lines of code I don’t have to write, mostly because if I did have to write it would likely take minutes.

brian: And, going back to the more extreme case of Metalsmith, for instance, if something is core to what your application aims to do (say, generate static files or parse Markdown in this instance), the developer of the project should own it.

cody: You see, it is the fact that it was only a light bulb that needed changed, that is the best we can do in these situations. Imagine if, the light build controlled all the electrical in the car (a circuit). Yes, all the electrical in the car would fail if one light bulb went out, but the fix is to just replace the bulb. Easy.

brian: Cody, I’m not arguing you should reinvent it, but just take those 11 lines and place them into your project. No npm install - just Ctrl+C and Ctrl+V. :-)

TJ: left-pad isn’t changing :-)

cody:

If all you mean is, business logic should mostly be programmed, not installed by a third-party, I can see that as a developer lesson to learn. But, honestly, if you build a solution on the complete shoulders of other tools then, yes, you take on a lot of risk.

brian: Right. But clearly a lesson that a lot of this community has not yet learned.

TJ: So I’d like to ask more more question, maybe it’s a bit off topic, but should npm have different procedures for unpublishing modules?

To me that’s the biggest problem here, that a dependency you take on can just disappear at a single developer’s whim. (edited)

brian: I agree. I am also concerned that they actually just decided to restore the project. I worry that it blurs the line of ownership on the project, however minor this project was.

cody: So, we agree that npm and “Write programs that do one thing and do it well.” in an open setting is a good solution. But, developers can do risky stuff inside the system. Personally, I didn’t like the Register article because I think it was just sensationalizing a potential problem, that isn’t really that big of an issue.

brian: It may have been a relatively easy fix, but it clearly impacted a lot of developers worldwide.

cody: It was sensationalized as if it did. The fix was trivial.

TJ: It’s a news article, so to an extent sensationalizing comes with the territory. They’re trying to make a big deal about builds being down for a few hours.

cody: Of course, npm could step in here and do some smart things, like determining if your package is too valuable to not prop up regardless of your wish to remove it.

brian: Hehe. Here we are at “too big to fail” in the JavaScript world. uh oh!

cody: The more interesting question is what npm can do with a package once you publish it

TJ: Apparently un-unpublish :-P

cody: Right, but, everyone has the problem. i.e. every system, can fail, and does at times.

TJ: I’d summarize my thoughts like this: While I think most people are having the small module debate right now, I think the more interesting debate to come our of left-pad-gate (that name’s totally going to catch on) is whether npm should change their unpublishing rules and procedures, and that’s likely a discussion going on at npm Inc right now. Ideally a single developer shouldn’t be able to break builds worldwide by running npm unpublish.

cody: I agree. I think I said as much. The interesting conversation is what can npm do, in this context, for good for the greatest amount of people. I think a too big to fail policy might be in order. :-)

brian: If the three of us are all agreeing, then problem solved. You're welcome, JavaScript community! ;-)

Thanks for the chat guys! Let's continue the discussion in the comments.

Header image courtesy of treybunn2


Brian Rinaldi is the Developer Content Manager at Telerik
About the Author

Brian Rinaldi

Brian Rinaldi is a Developer Advocate at Progress focused on the Kinvey mobile backend as a service. You can follow Brian via @remotesynth on Twitter.

Comments

Comments are disabled in preview mode.