Another one-liner package breaks the JavaScript ecosystem

is-promise NPM package

The is-promise NPM package breaks the JavaScript ecosystem. Ironically, this utility function, whose sole purpose is to return a boolean value, according to naming conventions, didn’t always return a boolean value.

Developers were left staring at broken builds and failed installations after someone toppled the Jenga tower of JavaScript. If you’re one of the ~12 million users using the is-promise NPM package, you already know what this is about. If you’re not, breaking news, an update to a tiny one-liner NPM package has thrown a large part of the JavaScript ecosystem into chaos this week, with more than 11.7 million projects believed to have been impacted. What makes the entire situation ridiculously absurd is the fact that the whole mess was caused by a super-tiny one-liner JavaScript library.

THE is-promise ONE-LINER

The package responsible for many broken JavaScript applications this week is named is-promise. The library consists of two lines of raw source code, and developers can use it in their projects via a function call. This is the entirety of the contents of this package:

module.exports = isPromise;
module.exports.default = isPromise;

function isPromise(obj) {
  return !!obj && (typeof obj === 'object' || typeof obj === 'function') && typeof obj.then === 'function';

As you can see, the package contains just one function which again is whose whole purpose is to let developers test if a JavaScript object is a “Promise“. The function returns a boolean result of true or false depending on whether the passed object is a Promise or not.

The is-promise library, despite being just one line of code that performs a basic check, is one of today’s most popular JavaScript npm packages (libraries). According to NPM, the library is being downloaded more than 11.7 million times. More than 3.4 million projects on GitHub alone are using this package and used as a dependency by 766 other JavaScript libraries.

is-promise NPM package
is-promise NPM package

Over the weekend of 25th April, the is-promise 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 [12345678910].

The change had an immediate impact on different projects ranging from closed-source JavaScript codebases to some of the JavaScript ecosystem’s biggest projects. Facebook’s Create React App (the standard template for creating React apps), Google’s Angular.js framework, Google’s Firebase-tools, Amazon’s AWS Serverless CLI, Nuxt.js, AVA are some of the major projects impacted because of this breaking change.

Luckily, the bug didn’t crash existing projects, so there was no actual downtime, but it did prevent developers who tried to install dependencies from compiling new versions of their projects. The is-promise team has since released an update but did not manage to fix the issue, and eventually rolled back the ES module support in v2.2.2, a few hours after the issue was first reported.

The Post-mortem

The owner of the package is-promise, Forbes Lindesay, published an article on April 27, 2020, explaining the details of the issue. If you’re interested to check it out as well.


Interestingly enough, this is not the first time a single NPM package has had such a big impact on so many projects. Back in March 2016, the author of the left-pad JavaScript library (another project with mere 17 lines of code) decided to unpublish the library out of the blue, breaking thousands of projects in a similar way. Apart from this, several NPM packages over the years have witnessed various security vulnerabilities. A severe security vulnerability was found in fsevent, in April 2019, which is being downloaded more than 25 million times every week.

Time and again, incidents like this raise questions about the feasibility of the JavaScript package system and start 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.

Some developers believe that modularization in JavaScript packages 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 other bunch of developers which argue 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 writing code for the same trivial problems.

No matter which side you’re one, incidents like this sure bring the decade-old NPM ecosystem problems to the fore. Because of the nested dependencies of the packages you’re using, you’re often not fully aware of which versions of which packages are being used by your code and that remains an unsolved mystery in the NPM ecosystem.

Be sure to follow us on the social media to get notified about the latest posts as soon as they’re published

Featured Image Credit: Photo by Michał Parzuchowski on Unsplash

Leave a comment

Your email address will not be published. Required fields are marked *