> 3) "deprecate request and start new" - and discard 10 years of commits, stability and tests? Wouldn't be a rational way to go. The new package doesn’t have t

> 3) "deprecate request and start new" - and discard 10 years of commits, stability and tests? Wouldn't be a rational way to go. The new package doesn’t have to start from zero — it can start from where the old package left off. In terms of version control history it could even start life as a copy of the old git repo. The developers having worked on the old version for that long certainly know what will be best for them I should hope. Whether that means reworking the old code for the new package, or taking some parts of it with them, or rewriting everything. As long as they don’t fall for the temptation of implementing new features in the rewrite, or at least not any significant number of new features. > 2) "ignore it and become a thorn in the side of devs everywhere" - it wouldn't become a thorn more than it is now, would it? It's a 10 year old package that's downloaded 14 million times a week. It doesn't feel a thorn with those numbers. You can also `util.promisify` it if a callback is a "thorn" for you as a developer. (but see https://news.ycombinator.com/item?id=19604867 https://news.ycombinator.com/item?id=19604867) Just because people are using it doesn’t automatically mean people enjoy using it.