Ask questionsRequest’s Past, Present and Future
Before I go into the details and reasoning I’ll get straight to the point. The most valuable thing
Apologies in advance to the other committers on
request that have been doing their best to improve it, but it’s for the best.
The first version of
request was one of the first modules ever created for the Node.js ecosystem. The earliest versions were written to APIs that pre-date the standard callback interface, streams, node_modules and npm. For the first few years,
request and Node.js evolved together, each learning from the other. As Node.js improved and migrated core interfaces so did request. As request adopted changes to the core http library and streams it also informed improvements like the
pipe event (which enabled
request’s one line proxy) and one of Core http’s many re-writes (the one I had to write).
request was one of the first modules added to the npm registry. As npm grew so did dependence on
request. Even now, when
npm is used far more for front-end than back-end work,
request remains one of the most depended on modules in the registry. As I write this, 41K modules depend on request and it is downloaded 14 million times a week.
request has in the Node.js ecosystem is no longer one of an innovator but of an incumbent. If you Google for how to do something with HTTP in Node.js the examples are likely to show
request as the client and
express as the server. This has two notably bad effects.
It’s much harder for new libraries accomplishing similar tasks to gain adoption because of the incumbent position
request holds over the ecosystem. It’s also very hard to change request in any meaningful way as the change not only may not be adopted by the majority of its dependents but it would put it out of alignment with the thousands of blog posts and stack overflow responses that use
The patterns at the core of
request are out of date. A few people might argue with that assessment, and I know who they are so I won’t be surprised, but it’s true. I have often been skeptical of the impact some of these features would have only to find myself adopting them wholesale not long after they are available in only the latest release of Node.js.
There’s a transition happening now in the ecosystem to these patterns. How messy that will be is still up in the air and I’m not going to try and read the tea leafs and figure out what the future looks like in that regard. The question for
request is “Do we try to survive through that transition?” A year ago, I thought the answer was obvious and that we would, but now I’m convinced of the opposite.
A version of
request written to truly embrace these new language patterns is, effectively, a new module. I’ve explored this space a bit already and have a project I’m quite happy with but it is incompatible with
request in every conceivable way. What’s the value in a version of
request that is incompatible with the old patterns yet not fully embracing the new ones? What’s the point in being partially compatible when there’s a whole world of new modules, written by new developers, that are re-thinking these problems with these patterns in mind?
The best thing for these new modules is for
request to slowly fade away, eventually becoming just another memory of that legacy stack. Taking the position
request has now and leveraging it for a bigger share of the next generation of developers would be a disservice to those developers as it would drive them away from better modules that don’t have the burden of
Here’s the plan.
requestwill stop accepting new features.
requestwill stop considering breaking changes.
Answer questions mikeal
This is a breaking change and in my opinion unnecessary. Just leave the module as it is and we'll all move on with the next project - particularly if the alternative offers advantages. Indeed we'd be silly not to do so. But as far as I can see there is at the moment no real alternative.
Here’s the thing. This code has known bugs that won’t be fixed. This code is no longer maintained and is deprecated.
The deprecation warning is a notice that you’re relying on problematic code. If you’re fine relying on deprecated and problematic code then simply suppress the messages. Your issue seems to be the warnings and not the state of the software. If you’re fine with the state of the software then simply suppress the warnings.
We will not be altering the deprecation state and relevant warnings to be out of line with reality in order to satisfy any particular user’s concern over warnings they can easily suppress if they are unconcerned about relying on deprecated modules.