Another one-line npm package breaks the JavaScript ecosystem

An update to tiny "is-promise" library impacted millions of JavaScript projects.
Written by Catalin Cimpanu, Contributor

An update to a tiny JavaScript library has thrown a large part of the JavaScript ecosystem into chaos on Saturday, with millions of projects believed to have been impacted.

Making the entire situation ridiculously absurd is that the whole mess was caused by a "one-liner" JavaScript library, marking this the second time when a tiny JavaScript project has caused widespread issues.

The is-promise one-liner

The package at the heart of this weekend's problems is named is-promise. The library consists of two lines of raw source code, and developers can use it in their projects via a one-liner call.

Its purpose is to let developers test if a JavaScript object is a "Promise," with the function returning a boolean result of yes or no when used in production.

Despite being just two lines of code that perform a basic check, the is-promise library is one of today's most popular JavaScript npm packages (libraries). According to GitHub, the library is part of more than 3.4 million projects and used as a dependency by 766 other JavaScript libraries.

Over the weekend, the is-promised library was updated to receive support to work as an ES module -- the standardized module system used by the JavaScript language.

However, the is-promise v.2.2.0 release didn't adhere to the proper ES module standards. As soon as the update was out, projects that used is-promise inside their build chain started failing due to the improper ES module support [1, 2, 3, 4, 5, 6, 7, 8, 9, 10].

The effect of the error was felt immediately, and impacted from closed-source JavaScript codebases to some of the JavaScript ecosystem's biggest projects.

This included Facebook's Create React App (the standard template for creating React apps), Google's Angular framework, Google's Firebase-tools, Amazon's AWS Serverless CLI, Nuxt.js, AVA, and more.

The bug didn't crash existing projects, so there was no actual downtime, but it did prevent developers from compiling new versions of their projects.

The is-promise team released an update but did not manage to fix the issue, and eventually rolled back the ES module support in v2.2.2, released a few hours after the dominos started falling around it.

Happened before in 2016

This incident marks the second time that a tiny JavaScript library caused problems all over the JavaScript ecosystem. Something similar happened in March 2016, when the author of the left-pad JavaScript library (another project amounting to 17 lines of code) decided to unpublish the library without warning, breaking thousands of projects in a similar way.

As it did in 2016, the is-promise incident raised questions and started discussions on the need to have one-liner libraries available in the ecosystem.

The same arguments are being raised again, as have been raised in 2016, and in years before, in the ecosystems of other programming languages.

There's the side who says that modularization is going too far when developers are creating libraries that only account for a few lines of code, for the most trivial of operations.

Then there's the side which argues that modularization of such items is needed, as in this manner, "Task A" could be managed inside one module, rather than have thousands of developers deal with it in their own projects in different ways.

Discussions about modularization have been raging for years and they're most likely not going to reach a conclusion anytime soon.

What's in a name? These DevOps tools come with strange backstories

Editorial standards