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].
This included Facebook’s Create React App (the standard template for creating React apps), Google’s Angular.js framework, Google’s Firebasse-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.
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.