Request’s Past, Present and Future

[mikeal]

Before I go into the details and reasoning I’ll get straight to the point. The most valuable thing request can do for the JavaScript ecosystem is to go into maintenance mode and stop considering new features or major releases.

Apologies in advance to the other committers on request that have been doing their best to improve it, but it’s for the best.

2009

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).

npm

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.

The place 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 request.

Modern JavaScript

The last few years have been dramatic ones in JavaScript. Features people had talked about for years went from ideas, to standards, to features you can reliably depend on in most environments. The speed at which these have been adopted is staggering, mostly thanks to auto-updating browsers and an aggressive Node.js release schedule.

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 request’s history.

Maintenance Mode

Here’s the plan.

• request will stop accepting new features.
• request will stop considering breaking changes.
• The committers that are still active will try to merge fixes in a timely fashion, no promises though.
• Releases will be fully automated, any merge into master will be published. I’ve already built this for some other projects using GitHub Actions.
  • We’re going to have to remove inactive collaborators and enforce 2fa, because commit rights will effectively become npm publish rights.

[reconbot]

I fully support this, I think a warning message and/or deprecating new releases is in order.

As for the change in process and guidelines, it makes my job a lot easier 👌

[simov]

Very well said @mikeal. I'm pinning this issue to gain more visibility.

[reconbot]

Things we might do - please discuss and volunteer!

• update readme with current state of project
• update ci publishing pipeline @mikeal
• provide a doc with some guidance on request alternatives #3143
• add a warning message on install of the package to use another package and reference the doc
• pick a date to stop support (I vote 6 months, but 12 is probably friendlier)
• close all feature requests and feature prs
• review and merge relevant bug fixes
• add github issue and pr templates explaining that features wont be merged
• deprecate the next major version (3.x) so project’s in active maintenance get a warning but older projects continue as usual

[analog-nico]

It makes a lot of sense! I will slowly adopt this policy for the request-promise family as well. Cheers to your important contributions to the node ecosystem!

[mikeal]

Open Source Software grants certain rights to the User

OSS licenses provide rights to re-distribute and modify, no guarantees of any kind are made on the suitability of the software for any particular use. No guarantees are ever made on future changes, including potential breaking changes.

Here’s the relevant text from the Apache 2 license. Pretty much every open source license has this.

“Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.”

[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.

[Meharab]

need help!!!..i am having this issues when i try to install node-gyp 3.6.2
PS C:\Users\User> npm install --global node-gyp@3.6.2
npm WARN deprecated request@2.88.2: request has been deprecated, see #3142
npm ERR! path C:\Users\User\AppData\Roaming\npm\node-gyp.cmd
npm ERR! code EEXIST
npm ERR! Refusing to delete C:\Users\User\AppData\Roaming\npm\node-gyp.cmd: is outside C:\Users\User\AppData\Roaming\npm\node_modules\node-gyp and not a link
npm ERR! File exists: C:\Users\User\AppData\Roaming\npm\node-gyp.cmd
npm ERR! Move it away, and try again.

npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\User\AppData\Roaming\npm-cache_logs\2020-02-13T05_12_13_683Z-debug.log

[millette]

@mikeal Oh, this is an interesting case. Having the issue number in the deprecation notice might bring a lot of unrelated comments here, as @Meharab demonstrated.

Perhaps it's time to prevent further comments here?

[itsmrTech]

@mikeal Thanks for these years

[Richienb]

Goodnight request. See you on the other side.

[simov]

request is going to work forever (as it is), because that's JavaScript .. well unless Node introduces a breaking change by deprecating a core API used by it

[Edo78]

request is going to work forever (as it is), because that's JavaScript .. well unless Node introduces a breaking change by deprecating a core API used by it

Nope.
This code has known bugs that won’t be fixed. This code is no longer maintained and is deprecated. (cit.)

So request is gonna have unfixed bugs forever is not going to work forever ...

[snotrman]

I don't get it. So what am I suppose to officially do now, not to get the deprecation warning?

[nickmccurdy]

Remove request. This may involve removing it from your own dependencies, upgrading packages that remove it in newer versions, or removing packages that haven't been updated with newer versions yet.

[b3y0ndb3z0tch]

Hello.

I am trying to install cordova.

npm install -g cordova

i keep receiving this error.
Microsoft Windows [Version 10.0.18362.592]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\Users>npm install -g cordova
npm WARN deprecated request@2.88.2: request has been deprecated, see #3142
C:\Users\AppData\Roaming\npm\cordova -> C:\Users\AppData\Roaming\npm\node_modules\cordova\bin\cordova

• cordova@9.0.0
  updated 1 package in 10.279s

Is there another way to install Cordova?
A way around this buy?

[snotrman]

Yes. Ok. I'll remove request. But what then?

So on node.js I have to switch to.. idk.. axios?

What am I suppose to put in reqest's place?

I understand the idea is to rewrite all the functions where request was present?

Is there a package I could just change with find&replace with regex?

Is there an official replacement for request or are we just set free now to find whatever comes up first on google? I don't get it

[nickmccurdy]

Is there an official replacement for request

No, you can use whatever you want, though the same developer is working on bent

[kevinvanrijn]

There is also the postman-request fork which has recieved a number of fixes, but it hasn't had any activity since the deprecation of request.

Because they don't have an issues page I suppose I'll try asking here:

@coditva @codenirvana @shamasis @vikiCoder @czardoz

Apologies for the mentions, but what are the plans moving forward for postman-request now that request is officially dead? Will postman-request continue to be maintained, or will it also be deprecated?