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.

[psequeirag]

And I'd say advertising bent in the deprecation notice (possibly along with some others, if that makes you feel more comfortable) is a great way to start getting it known despite the obscure naming.

[rinsad]

Angluar 8 request module deprecated ``` npm WARN deprecated request@2.88.2: request has been deprecated, see https://github.com/request/request/issues/3142 npm ERR! code E404 npm ERR! 404 Not Found: error-ex@^1.3.1 npm ERR! A complete log of this run can be found in: npm ERR! C:\Users\Ammar\AppData\Roaming\npm-cache\_logs\2020-02-12T04_18_22_538Z-debug.log ```

[JonathanRowell]

Do you really understand what "deprecated" really means?

Deprecated. In the world of software development, "deprecated" refers to functions or elements that are in the process of being replaced by newer ones. The term comes from the word "deprecate," which means to disapprove of something.

In practice this means that when I maintain any of my (non open source) modules I'll get silly error messages.

What about the 151 issues and the 55 pull requests? Dump them?

And I'd say advertising bent in the deprecation notice (possibly with others if that makes you feel more comfortable) is a great way to start getting it known, despite the obscure naming.

This is FAR too early - see issue 2 of bent.

I think that request should go into a limbo mode - not deprecated which causes silly warnings - but where NOTHING will be undertaken, all issues and pulls will be ignored and the README page should be updated to note this and, when appropiate, references will be included to other functionally equivalent packages.

[mikeal]

What about the 151 issues and the 55 pull requests? Dump them?

Nobody has been fixing or reviewing these for some time, they were already “dumped.”

Your comments make it sound as though there is some kind of dedicated labor in this project that people are entitled to. This has never been the case, request is not a product released and backed by a company, it has always been maintained by open source developers who care and as the ecosystem has moved in a new direction we all moved with it. I recommend you move on as well.

[JonathanRowell]

Nobody has been fixing or reviewing these for some time, they were already “dumped.”

What you mean is that YOU have not been reviewing these for some time. Be fair, we who are not collaboraters have no control over this.

Your comments make it sound as though there is some kind of dedicated labor in this project that people are entitled to.

I didn't mean it like that, but in a sense it is true, Open Source Software grants certain rights to the User as well as protecting the rights of the developer. These rights are of usage not of maintainance. When maintainance or futher development involves breaking changes, much care and thought needs to be taken. 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.

[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 https://github.com/request/request/issues/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?

UPDATE: 5 days later and the comments are really piling up.

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

[nilsriga]

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 https://github.com/request/request/issues/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?

[nilsriga]

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 received 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?

[AURZeeshan]

need help!!! I'm trying to install angular,i have an issue npm install -g @angular/cli npm WARN deprecated request@2.88.2: request has been deprecated, see https://github.com/request/request/issues/3142 npm ERR! code EEXIST npm ERR! path C:\Users\FARHAN\AppData\Roaming\npm\node_modules\@angular\cli\bin\ng npm ERR! dest C:\Users\FARHAN\AppData\Roaming\npm\ng.cmd npm ERR! EEXIST: file already exists, cmd shim 'C:\Users\FARHAN\AppData\Roaming\npm\node_modules\@angular\cli\bin\ng' -> 'C:\Users\FARHAN\AppData\Roaming\npm\ng.cmd' npm ERR! File exists: C:\Users\FARHAN\AppData\Roaming\npm\ng.cmd npm ERR! Remove the existing file and try again, or run npm npm ERR! with --force to overwrite files recklessly.

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

[vighnesh153]

What are the alternatives to request? Angular is still dependant on it. Hope they will be updating their codebase soon.

[riclf]

I have a short term solution which Mikeal Rogers will recoil at, maybe even lash out at me for. This current deprecation came in 2 unscheduled phases- 1) a General Discussion of its necessity, 2) BANG, about a 30 minute notice and it was implemented. All hell has broken loose.

I ask @mikeal if he would consider rolling back the deprecation today, and announce a 6 month "Notice of Depreciation", which will be implemented on, and completely effected on August 15, 2020.

The 3 Phases- 1) Discussion: March 20, 2019 through February 15, 2020 2) 6 Month Notice of Deprecation: February 15, 2020 3) Implementation of Deprecation: August 15, 2020

This way, not only are frameworks and application projects NOT instantly broken, which is just too harsh, but this community can now use THIS discussion area to share alternatives, the +/-'s over the next few months and get the alternatives in place by the 6 mo deadline. Then when it happens we can all salute it, yell cheerio, and nothing is broken.

Please, understand, I am not making any argument about the necessity for it's deprecation, or right of the creator to do it... I am suggesting a the 3-step prior notice schedule, as stated above, which will account for its very significant usage in the developer community, and the apps alive in the world today depending on the request module.

Mikeal, please, consider my suggestion, and remove the Deprecation status today and announce the 6 month notice. Less than 6 months is not enough time for many of us, 6 is fair. I would appreciate that, we all would.

Many thanks for hearing me, -Ric Fink

[nickmccurdy]

Adding a deprecation warning doesn't break anything though, it just warns users that it could be broken in the future. I'd rather see a deprecation message sooner than have to wait for community discussion before knowing that I'll eventually have to replace a package.

Also, friendly reminder that this package was being developed via open source free of charge, and the maintainer doesn't owe you anything. If you'd like to continue using the package, you can fork it and continue maintaining it yourself.

[Richienb]

@riclf

need help!!! I'm trying to install angular,i have an issue npm install -g @angular/cli npm WARN deprecated request@2.88.2: request has been deprecated, see #3142 npm ERR! code EEXIST npm ERR! path C:\Users\FARHAN\AppData\Roaming\npm\node_modules@angular\cli\bin\ng npm ERR! dest C:\Users\FARHAN\AppData\Roaming\npm\ng.cmd npm ERR! EEXIST: file already exists, cmd shim 'C:\Users\FARHAN\AppData\Roaming\npm\node_modules@angular\cli\bin\ng' -> 'C:\Users\FARHAN\AppData\Roaming\npm\ng.cmd' npm ERR! File exists: C:\Users\FARHAN\AppData\Roaming\npm\ng.cmd npm ERR! Remove the existing file and try again, or run npm npm ERR! with --force to overwrite files recklessly.

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

This seems to have been solved by the latest release of Angular in which request is replaced with node-fetch.

[Cyral]

@AURZeeshan Your error does not relate to this. You are just seeing a warning from this package, the error is different.

[vighnesh153]

@riclf

need help!!! I'm trying to install angular,i have an issue npm install -g @angular/cli npm WARN deprecated request@2.88.2: request has been deprecated, see #3142 npm ERR! code EEXIST npm ERR! path C:\Users\FARHAN\AppData\Roaming\npm\node_modules@angular\cli\bin\ng npm ERR! dest C:\Users\FARHAN\AppData\Roaming\npm\ng.cmd npm ERR! EEXIST: file already exists, cmd shim 'C:\Users\FARHAN\AppData\Roaming\npm\node_modules@angular\cli\bin\ng' -> 'C:\Users\FARHAN\AppData\Roaming\npm\ng.cmd' npm ERR! File exists: C:\Users\FARHAN\AppData\Roaming\npm\ng.cmd npm ERR! Remove the existing file and try again, or run npm npm ERR! with --force to overwrite files recklessly. npm ERR! A complete log of this run can be found in: npm ERR! C:\Users\FARHAN\AppData\Roaming\npm-cache_logs\2020-02-15T09_52_19_067Z-debug.log

This seems to have been solved by the latest release of Angular in which request is replaced with node-fetch.

I installed the latest CLI version. It still throws the same warning

npm WARN deprecated request@2.88.2: request has been deprecated, see https://github.com/request/request/issues/3142

[Richienb]

@vighnesh153 What version of @angular/cli is specified in your package.json? It seems that some of the dependencies need request but not the base package itself. See http://npm.anvaka.com/#/view/2d/%2540angular%252Fcli

[vighnesh153]

Perhaps you are right. I am not quite sure which of the packages is using the request-package. Here's a snap of the deps:

"dependencies": {
    "@angular/animations": "~9.0.1",
    "@angular/common": "~9.0.1",
    "@angular/compiler": "~9.0.1",
    "@angular/core": "~9.0.1",
    "@angular/forms": "~9.0.1",
    "@angular/platform-browser": "~9.0.1",
    "@angular/platform-browser-dynamic": "~9.0.1",
    "@angular/router": "~9.0.1",
    "rxjs": "~6.5.4",
    "tslib": "^1.10.0",
    "zone.js": "~0.10.2"
  },
  "devDependencies": {
    "@angular-devkit/build-angular": "~0.900.2",
    "@angular/cli": "~9.0.2",
    "@angular/compiler-cli": "~9.0.1",
    "@angular/language-service": "~9.0.1",
    "@types/node": "^12.11.1",
    "@types/jasmine": "~3.5.0",
    "@types/jasminewd2": "~2.0.3",
    "codelyzer": "^5.1.2",
    "jasmine-core": "~3.5.0",
    "jasmine-spec-reporter": "~4.2.1",
    "karma": "~4.3.0",
    "karma-chrome-launcher": "~3.1.0",
    "karma-coverage-istanbul-reporter": "~2.1.0",
    "karma-jasmine": "~2.0.1",
    "karma-jasmine-html-reporter": "^1.4.2",
    "protractor": "~5.4.3",
    "ts-node": "~8.3.0",
    "tslint": "~5.18.0",
    "typescript": "~3.7.5"
  }

[li-car-fei]

npm install npm WARN deprecated request@2.88.2: request has been deprecated, see https://github.com/request/request/issues/3142

when I want complete "npm install" in \vue-devtools-dev, I have warn about this how can I solve it ?

[cecilemuller]

I totally respect your decision to deprecate it and wish you the best for the future.

As for people coming to the thread looking for "so what should I use from now on ??", gotor axios are what you're looking for.

[csvan]

Pathetic. Time to migrate to node-fetch.

...except you yourself question if node-fetch is a good replacement for request, or even actively maintained. Pathetic indeed.

https://github.com/node-fetch/node-fetch/issues/668#issuecomment-586903934

[csvan]

Btw, people who are opting for node-fetch really need to be careful. That lib, while great, has severe maintenance issues of its own.

[dobromyslov]

Pathetic. Time to migrate to node-fetch.

...except you yourself question if node-fetch is a good replacement for request, or even actively maintained. Pathetic indeed.

node-fetch/node-fetch#668 (comment)

At least node-fetch is not deprecated. Hard deprecation of the request has caused troubles with autobuild systems. I dont understand and dont accept this move and in my opinion simple note explaining that the lib is unmaintained would be enough instead of hard deprecation. Thats why I consider this situation pathetic.

[CliffS]

in my opinion simple note explaining that the lib is unmaintained would be enough

That's exactly what a deprecation notice is: a simple note.

[mikeal]

@asgetz all npm does is print that warning when installing a deprecated package, everything else works exactly as it did before.

[ljwestwhos]

I am having issues with less.js files working on github. They work fine within PHP. When I tried to put less in the command, this warning popped up. Any ideas on what the issue is?

[csvan]

@ljwestwhos request is marked as deprecated, the text of the issue you are commenting on explains what that implies. However, it most likely has nothing to do with your problem with less.js, since request still works like it did before.

[maple3142]

Is there a replacement for request, but with node.js's stream interface? I found that node-fetch, axios are both based on Promise.

I would like to know a replacement for stream interface, which is more convenient for lower level use cases.

[millette]

@maple3142 got has a stream interface (as well as promises) and a migration guide.

[CliffS]

@asgetz

npm is indicating to me that I have to install it myself now.

It what way is it indicating that. When I install request I just get the deprecation notice and everything works as before.

my planned use for it is so small

It that case, maybe take a look at bent which is far lighter weight and seems to work nicely.

[kaue]

@mikeal can you please take a look at https://github.com/request/request/pull/3245 proxyHeaderExclusiveList is one of the best features in this package and its not working properly. Lets fix this!

[Edo78]

@kauegimenes this package is deprecated ... nothing will be fixed ever again

[czardoz]

@kevinvanrijn I'm not actively involved in maintaining postman-request anymore, but the project is definitely alive and the last release was a month ago. I will let the active maintainers chime in on the longer term plans though.

[kevinvanrijn]

@czardoz That's good to know. I have a bunch of small projects (all private) depending on request that I can't spend time on rewriting. Dropping postman-request in as a replacement means I can rely on them to continue functioning for just a little while longer.

cloudscraper is also suffering from slow maintenance and will likely not be able to move away from request just yet. Having postman-request available as an option means it'll at least not be at risk of becoming deprecated itself.

[kaue]

@Edo78 why you say that? i still have faith one day my PR will get merged 😆

The committers that are still active will try to merge fixes in a timely fashion, no promises though.

[jakehewitt]

Btw, people who are opting for node-fetch really need to be careful. That lib, while great, has severe maintenance issues of its own.

@csvan Can you explain a bit? I'm only seeing a few issues

[SimpleSamples]

I know very little about npm. I used it to install an API and I got some warnings I do not understand. They direct me here. This is totally useless for me. Someone should post something here that is useful for those of us directed here or the message in npm should be fixed to be more useful. The following is the messages I got.

npm WARN deprecated request@2.88.2: request has been deprecated, see https://github.com/request/request/issues/3142 npm WARN saveError ENOENT: no such file or directory, open 'C:\Users\Sam\package.json' npm notice created a lockfile as package-lock.json. You should commit this file. npm WARN enoent ENOENT: no such file or directory, open 'C:\Users\Sam\package.json' npm WARN Sam No description npm WARN Sam No repository field. npm WARN Sam No README data npm WARN Sam No license field.

Also, there is no package.json file but there is a package-lock.json. I have no idea what to look for there.

[csvan]

@SimpleSamples the package is deprecated and will not be actively maintained apart from possible bug fixes, as the text clearly explains. NPM is simply warning you that you are using a deprecated package, so that you have the opportunity to switch to something else.

If you do not understand what deprecation means, there are several useful articles a Google search away.

[SimpleSamples]

Yes I understand what deprecation means and therefore the link to the discussion of Request’s Past, Present and Future does not provide any clarification, it just adds confusion. Or is there something more I do not understand and you are not clarifying? If it is only saying that Request is deprecated than that is all it needs to say, instead of implying there is something more we must do.

It would be most helpful if it were to say (link to an article explaining) what replaces it, or whatever action we should be aware of.

Christopher Svanefalk mailto:notifications@github.com Tuesday, February 18, 2020 10:45 PM

@SimpleSamples https://github.com/SimpleSamples the package is deprecated and will not be receiving further updates, as the text clearly explains. NPM is simply warning you that you are using a deprecated package.

If you do not understand what deprecation means, there are several useful articles a Google search away.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/request/request/issues/3142?email_source=notifications&email_token=ACK22R4G7LHULMPO6DHH273RDTIP7A5CNFSM4HCP6LRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMGR4HI#issuecomment-588062237, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACK22R7UFQSYKW7NEYZ4OTDRDTIP7ANCNFSM4HCP6LRA.

[Mansarde]

If it is only saying that Request is deprecated than that is all it needs to say

Yeah, f*ck anyone who appreciates context and likes to know reasons for decisions or wanting to know particulars about the phase-out. :P To be serious though, if there was an added "as to why" to the warning, would that have prevented your confusion?

"npm WARN deprecated request@2.88.2: request has been deprecated, see #3142 as to why"