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 👌

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

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

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!

deprecate the latest npm package and auto deprecate them on publish

Please be careful about deprecation. As Mikael wrote above, there are 41K modules depending on request. Many of these modules are useful in the current state and work well for their users, but their maintainers may not have time to rework those modules to use something else than request. By deprecating request at install time, you will basically deprecate a large portion of npm module ecosystem.

As I see it, maintenance mode is not the same thing as deprecation.

• Maintenance mode = we will fix bugs and security vulnerabilities so that you can keep using this package.
• Deprecation = nobody should be using this package any more. This typically happens when the module is abandoned and won't receive any further bug or security fixes.

I hear you. The full text

deprecate the latest npm package and auto deprecate them on publish via ci __(maybe after support has been stopped?)__

I think we should eventually deprecate request because I don't want new projects to use it.
I've been trying to triage the issues and prs down to a list we can solve, but there are bugs that we cannot fix without a breaking change. Therefore they wont get fixed and new users will have issues.

For example following redirects looses request bodies and cookies, and url parsing to remove relative paths are both bugs but I'm not sure they'll ever be fixed.

Maybe deprecation isn't the right answer, but I don't know how else to approach that.

Does that make sense?

Let’s just bump the major version when we deprecate. That way most people depending on the project won’t see this error until they try to upgrade to a new major, which means they are actively developing it and really should look for an alternative.

I'm proud to have been part of the history of request. I will also check out bent, it looks interesting, and _small_, which is more important to me these days.

We’re going to have to remove inactive collaborators and enforce 2fa, because commit rights will effectively become npm publish rights.

Fine to remove me.

I think we should eventually deprecate request because I don't want new projects to use it.

As a programmer who is VERY grateful for the module and who uses it all the time I WANT to use it on new projects.

This decision must have been very hard to take but is commendable in the extreme. Well done.

I'm proud having used this amazing tool. It forced the community to improve. 🙏
If you need help to maintain it do not hesitate to contact me.

While I respect your decision, I would ask you to consider how much real world, production, code relies on request currently. It's far more than even NPM stats can tell you. I fully understand wanting to move on to a new thing and doing something in a new, more interesting way...this is the JavaScript ecosystem after all, have to chase the new thing. But please consider the amount of time and money you'd be costing professional engineering organizations by wholesale deprecating request. If you want to leave it in maintenance mode, that's fine, but understand that plenty of people have absolutely no practical reason to change libraries. Forcing people to change because of ideology is going to lead to frustration.

Regardless, thanks for the hard work everyone has put in to this library.

I wonder what library could be considered modern and recommended now. Superagent is mostly in maintenance mode right now, axios not too active altogether.

Just a quick note to say thank you (and all the other contributors) for all the hard work over the years on this module; it was one of the first I ever used back when I started with Node so will always have a special place in my heart.

Let’s just bump the major version when we deprecate. That way most people depending on the project won’t see this error until they try to upgrade to a new major, which means they are actively developing it and really should look for an alternative.

i think this is still a viable solution for the mention above.

@kibertoad Looks like @mikeal is working on https://github.com/mikeal/bent. I've been using https://github.com/sindresorhus/got for many years and it's well supported and evolving.

With all this talk and the possibility of it being deprecated, I think there has to be equal mention of a current maturity replacement module, of parallel utility. We can't just announce its end and then suggest nothing, or a replacement of much less maturity and confidence. Request is used in serious applications. Why does this matter? Because for all its "outdated patterns at its core", it works on a daily basis, for thousands. This is not about the perfect world but the real world. What is the real world replacement, of confidence, on the day request is put in maintenance mode or is deprecated? That is an imperative.

You can find that discussion over here https://github.com/request/request/issues/3143

You can find a current working plan (which direct feedback is welcome) can be found here https://github.com/request/request/issues/3142#issuecomment-478303334

Thanks for your work on request!

The patterns at the core of request are out of date.

Patterns change every few months and years, especially in JavaScript community. Aren't the reasons why request was originally created are still valid today?

request has 10 years of commits, stability and tests. Why start from scratch? Isn't this just adding more "JavaScript fatigue", resulting in more libraries doing the same thing - HTTP requests?

It's sad to see such an important and historic library in Node's history go away because streams and callbacks are not fancy in 2019 anymore.

I don't believe that deprecating the library is really needed, it's been around for about 10 years now, used in lots of places and is actually pretty stable, and in the end. all it does is make HTTP requests, what else would the library need? Support for the JS fad of the month? 👎

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

ba-dum-chhh! 🥁

This is responsible deprecation. Well communicated, with a plan to follow through on. I think other OSS maintainers can look to this as a standard to aim for.

This is much better than forgetting about a package and letting random people (who can inject back-doors into the code) in as maintainers to take over when you no longer care.

Request was a great package, and we thank you tremendously for your contributions to the early node ecosystem. You are right in your assessment that callback style is no longer idiomatic JavaScript, and there are other packages like fetch which mirror WHATWG standards.

@stcktrce Exactly, the library doesn't need anything else, it works just as it is. But there has been major improvements in the whole ecosystem. Deprecating the library is just marking the opportunity for others to check new and more modern libraries instead of simply relying on the most popular out there.

@mikeal thank you for all your efforts in the library (r2 too) and the ecosystem. Also, for setting this precedence of a well thought through and planned deprecation in the ecosystem.

Let’s just bump the major version when we deprecate. That way most people depending on the project won’t see this error until they try to upgrade to a new major, which means they are actively developing it and really should look for an alternative.

@mikeal I don't think that's a good idea.

The problem is that most of replacements are of lower quality than request. I just moved to request from axios about a week ago.

Axios has multi-year persistent bugs around proxy support, modifying https agents, and unhandled promise exceptions. You only find these out after investing into axios heavily.

To new users axios looks superficially as good as request (similar number of users, promises by design, etc)

Thanks for request :)

If anybody is looking for a minimal promise-based HTTP library with pluggable filters and good support for streams you could check out httplease. We've been using it for a few years in production.

I love the request module.Thanks a lot.
You mean request get too much focus to prevent other same new module come out?

If there are specific bugs in comparable features in other libraries I’d like to specifically identify them. Proxy support is a complex feature and having a test case that request passes but other libraries fail is very valuable.

@reconbot in the latest axios (^0.18.0) you can't connect to a https site through a proxy server. doing so results in EPROTO errors. this is an open bug regarding this, but the issue goes back years: https://github.com/axios/axios/issues/1981

edit: specifically, you can't use axios to do https requests via a http proxy. maybe a dedicated https proxy works, didn't try that.

I sure hope fixes are not considered new features, such as my pull request for Maximum Response Size, which I see as a standard required feature of any mature library.

Also I did review other request libs before I choose this one and most of them are very problematic, incomplete and buggy. Their docs do not measure either. I do not really see what can another library bring but untested code and bugs, it's not like there's a new approach to making HTTP requests. It's all about wrapping http/https module and providing sane defaults such as buffering response, decoding responses, and of course the ability to promisify the whole thing. The biggest problem of this library here is the aim of total compatibility, trying to be compatible with legacy stuff only brings pain and legacy coding practices. But this can be fixed in many ways. There's a good base that can be refactored into something elegant, modern and minimalist. And most of all reliable. There are many ways to do this - split into more files, use ECMA6 with Babel or Typescript.

No sane developer wants 10 libraries that do the same thing but lack different features, are buggy, undocumented. This library really works and I am thankful for it and hope that it's not deprecated but instead revived.

Fixes are not considered new features. Fixes will be merge for at least a year, possibly even longer.

-Mikeal

From: mivanovaxway notifications@github.com
Sent: Thursday, April 11, 2019 2:38 AM
To: request/request
Cc: Mikeal Rogers; Mention
Subject: Re: [request/request] Request’s Past, Present and Future (#3142)

I sure hope fixes are not considered new features, such as my pull request for Maximum Response Size, which I see as a standard required feature of any mature library.

Also I did review other request libs before I choose this one and most of them are very problematic, incomplete and buggy. Their docs do not measure either. I do not really see what can another library bring but untested code and bugs, it's not like there's a new approach to making HTTP requests. It's all about wrapping http/https module and providing sane defaults such as buffering response, decoding responses, and of course the ability to promisify the whole thing. The biggest problem of this library here is the aim of total compatibility, trying to be compatible with legacy stuff only brings pain and legacy coding practices. But this can be fixed in many ways. There's a good base that can be refactored into something elegant, modern and minimalist. And most of all reliable. There are many ways to do this - split into more files, use ECMA6 with Babel or Typescript.

No sane developer wants 10 libraries that do the same thing but lack different features, are buggy, undocumented. This library really works and I am thankful for it and hope that it's not deprecated but instead revived.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/request/request/issues/3142#issuecomment-482043697, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAACQ8I4BSRtOjqHk637gRfBhkvGbRrIks5vfwKIgaJpZM4cT_Li.

TIL 41k packages just became vulnerable.

Look, I agree that request should go away, but I’m always fearful of mainstream packages like this changing their release pipeline. One bad actor or one compromised dev box publishing malicious code would effectively spread to every project out there.

Please consider tightening the npm push requirements. Set up a branch for ci, require multiple approvals, something more than simply pushing to master.

no promises though.

Pun intended? 🤣

maybe the same logical reasoning should be applied to expressjs? for request we now have the new shiny got module, there is no re-write or true alternative to expressjs on the horizon.

express is great, but it is not really actively updated with new features these years

express may not be updated with new features but it is actively maintained and, last time i checked, has a few people still quite interested in doing that work. i don’t know that they need to take the steps we’ve taken towards deprecation.

@laoshaw what has express anything to do with request?

Preparing full deprecation. https://github.com/request/request/pull/3267

We are fully deprecated!

All versions on npm note the deprecation and the README notes clearly that request has been deprecated.

It’s been a great 10+ years, thanks to everyone who contributed over the last decade. Let’s all look forward to new libraries that are better suited for the changes that are occurring in the JS language and ecosystem.

So lets get SPECIFIC.
What is the lean code replacement for the request module?

Not to be left hanging on dead crust.... so many better options... like WHICH ones?
Not GRAND do everything under the sun libraries/modules, please.

@riclf we've been using https://github.com/googleapis/teeny-request/ to help ween us off of request for a few years. It does not do everything you are going to want it to do :) It uses node-fetch under the hood. There are other great options out there too!

For a promise-first solution there's also gofer which is heavily focussed on API communication. Support for TCP connect timeouts built-in, easy configuration (and rich errors) for talking to multiple APIs, etc..

Does anyone have any recommendations for alternative clients that have good support for HTTP Long Polling and presents as either a Stream or Event Emitter?

The last time I checked in April 2019, alternatives like got, node-fetch and axios had a major problem: when a (low-level networking) error happened, they discarded the helpful stack trace reported by Node.js core and threw a new high-level error with a stack trace pointing to the http client library only. This made debugging transport-level issues pretty much impossible, for example when proxies are involved.

Is there any good request alternative that preserves error details provided by Node.js core?

@bajtos I'm pretty sure gofer only decorates the original errors but should preserve the stack traces and messages.

bent has nice errors and is designed for async/await. It’s also incredibly small and the bundle size is teeny tiny ;)

The API is nothing like request though, so I wouldn’t call it a “replacement.”

@mikeal Why is it called bent? (request was an easier name to remember.)

bent has nice errors and is designed for async/await. It’s also incredibly small and the bundle size is teeny tiny ;)

The API is nothing like request though, so I wouldn’t call it a “replacement.”

This feels very much like technically correct rather than user-friendly logic. From the user perspective bent solves the same problem as request but better. Now it's stuck with a worse name for no reason. You can call it request 3 without much issue imo. Yes the API is breaking but what's what we have semver for.

You can call it request 3 without much issue imo. Yes the API is breaking but what's what we have semver for.

Spend some time with bent and you may feel differently.

It’s not a small difference in naming or promises vs callbacks. The ergonomics are very different, the states it surfaces are very different, the way it thinks about error conditions is a radically different approach.

request is a more procedural API, you tell it to do something and it tells you what happened, it only gives an error if something irrecoverably failed. bent takes the success criteria for the entire lifecycle and returns you an API that will fail if anything but the success criteria is met.

You use these libraries very differently. There are other libraries that are closer to request’s API if that is what you want, but after almost 20 years of working on HTTP clients I’ve found a different and ultimately better approach that I’d encourage people to consider, but I’m not going to ram it down everyone’s throats by making it request 3.0.

Why is it called bent? (request was an easier name to remember.)

Because you “bend” it into a specific shape (very particular success criteria) and it provides an ideal API for the success of that shape and fails on anything but it.

The name is a bit abstract, but request is the kind of name you could never get today. I barely got request in the npm registry and I wrote the original npm registry 😜

what about "got" as a replacement, it's sad we don't have a clear replacement while request is officially deprecated.

what about "got" as a replacement, it's sad we don't have a clear replacement while request is officially deprecated.

Maybe we should take the fact that nobody has written an API compatible replacement as an indication that adopting an API compatible replacement is undesirable once you sit down and work on it 🧐

That was certainly my experience.

Perhaps what people really want when they ask for a "replacement", is not so much an API compatible alternative, but the maintainer perspective on what other packages are already out there to solve roughly the same problem and that are making this package irrelevant so that you can confidently call it "deprecated".

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.

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.

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.

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.

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

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.

need help!!!..i am having this issues when i try to install node-gyp 3.6.2
PS C:\Users\User> npm install --global [email protected]
npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
npm ERR! path C:\Users\User\AppData\Roamingnpm\node-gyp.cmd
npm ERR! code EEXIST
npm ERR! Refusing to delete C:\Users\User\AppData\Roamingnpm\node-gyp.cmd: is outside C:\Users\User\AppData\Roamingnpm\node_modules\node-gyp and not a link
npm ERR! File exists: C:\Users\User\AppData\Roamingnpm\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\Roamingnpm-cache_logs\2020-02-13T05_12_13_683Z-debug.log

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

@mikeal Thanks for these years

Goodnight request. See you on the other side.

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

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

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

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.

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 [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
C:\Users\AppData\Roamingnpm\cordova -> C:\Users\AppData\Roamingnpm\node_modules\cordova\bin\cordova

• [email protected]
  updated 1 package in 10.279s

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

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

Is there an official replacement for request

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

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?

need help!!! I'm trying to install angular,i have an issue
npm install -g @angular/cli
npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
npm ERR! code EEXIST
npm ERR! path C:\Users\FARHAN\AppData\Roamingnpm\node_modules\@angular\cli\bin\ng
npm ERR! dest C:\Users\FARHAN\AppData\Roamingnpm\ng.cmd
npm ERR! EEXIST: file already exists, cmd shim 'C:\Users\FARHAN\AppData\Roamingnpm\node_modules\@angular\cli\bin\ng' -> 'C:\Users\FARHAN\AppData\Roamingnpm\ng.cmd'
npm ERR! File exists: C:\Users\FARHAN\AppData\Roamingnpm\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\Roamingnpm-cache_logs\2020-02-15T09_52_19_067Z-debug.log

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

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

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.

@riclf

need help!!! I'm trying to install angular,i have an issue
npm install -g @angular/cli
npm WARN deprecated [email protected]: request has been deprecated, see #3142
npm ERR! code EEXIST
npm ERR! path C:\Users\FARHAN\AppData\Roamingnpm\node_modules@angular\cli\bin\ng
npm ERR! dest C:\Users\FARHAN\AppData\Roamingnpm\ng.cmd
npm ERR! EEXIST: file already exists, cmd shim 'C:\Users\FARHAN\AppData\Roamingnpm\node_modules@angular\cli\bin\ng' -> 'C:\Users\FARHAN\AppData\Roamingnpm\ng.cmd'
npm ERR! File exists: C:\Users\FARHAN\AppData\Roamingnpm\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\Roamingnpm-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.

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

@riclf

need help!!! I'm trying to install angular,i have an issue
npm install -g @angular/cli
npm WARN deprecated [email protected]: request has been deprecated, see #3142
npm ERR! code EEXIST
npm ERR! path C:\Users\FARHAN\AppData\Roamingnpm\node_modules@angular\cli\bin\ng
npm ERR! dest C:\Users\FARHAN\AppData\Roamingnpm\ng.cmd
npm ERR! EEXIST: file already exists, cmd shim 'C:\Users\FARHAN\AppData\Roamingnpm\node_modules@angular\cli\bin\ng' -> 'C:\Users\FARHAN\AppData\Roamingnpm\ng.cmd'
npm ERR! File exists: C:\Users\FARHAN\AppData\Roamingnpm\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\Roamingnpm-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 [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142

@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

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"
  }

npm install
npm WARN deprecated [email protected]: 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 ?

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.

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

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

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.

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.

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

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?

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

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.

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

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

@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!

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

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

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

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

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

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 [email protected]: 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.

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

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

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 [email protected]: request has been deprecated, see #3142 as to why"

You are right. I did not see the "as to why" part.

Espen wrote:

"as to why"

@SimpleSamples sorry if I'm misunderstanding, but I genuinely don't see the confusion. Request is deprecated, and the text of this issue explains rather clearly why and what it implies.

Where do you get the idea that you need to do anything? A deprecation is only a deprecation, how you handle it is up to you.

There's nothing wrong with the patterns request uses. On the contrary, there is a huge community in the javascript ecosystem that still uses these patterns. In my experience it is far larger a community than the vocal minority (most large companies) who have the resources to constantly tear up perfectly working code bases for nothing more than developer vanity and arrogance.

I'm sorry that you have fallen into this trap, request has been a great service to the community and I sincerely hope you reconsider your decision.

Yea, I'm saddened that this is gone. Callbacks aren't bad, neither are promises or async await.

I think what you're missing @SimpleSamples is that the rest of the warnings you pasted have nothing to do with the deprecation warning that brought you here. You don't need to do anything about the deprecation but you might want to do something about your missing package.json (or whatever is causing those other warnings).

So what ARE we supposed to do now with all of those packages that are using request under the hood?

I tried replacing request with @root/request in one such package, assuming it was indeed a drop-in replacement, but I couldn't get it to work.

I also tried replacing request with something like...

const httprequest = require('http').request; const httpsrequest = require('https').request;

... and...

const request = parsedUrl.protocol === 'http' ? httprequest : httpsrequest`

... but I couldn't get that to work either.

So, now what? In absence of a drop-in replacement that actually does deliver on its promise, are we supposed to all just live with having multiple dependencies in our node_modules that rely on a deprecated package, several of which don't seem to be maintained? And why?

I get that request has become outdated in several aspects, but by deprecating this package without offering a suitable drop-in replacement, 41K modules are now directly depending on a deprecated package. If we consider the packages that use at least one of these 41K modules as a dependency, we may be talking about hundreds of thousands if not millions of packages that are affected.

Sure, I guess for some packages, it's easy to replace request with something like fetch, axios, superagent or Node.js's native http.request & https.request. But eg. in the case where requests are piped to another request (as with html2canvas-proxy), I struggle to figure out what the hell is going on there... and I can't really afford to spend many hours trying to replace just a few lines of deprecated code while I should actually be doing more important stuff.

I've always been weary of relying too much on a multitude of interdependent packages that are loaded in background with a package manager. Yes, I suppose it can offload a lot of the heavy lifting to third parties, but instead you get a whole bunch of other headaches to deal with.

Package managers give us a false sense of security. The whole leftpad debacle 4 years ago seems to have failed to open people's eyes with respect to the risks involved. I'm sure this won't make a difference either. Still, I feel like I must stress that there is something seriously wrong when one deprecated or broken package can impact millions of packages across the entire ecosystem. And this is likely to only get worse, as more an more projects will become abandoned, deprecated or even broken as more time passes, and we'll all be living in dependency hell...

But hey... I guess at least that means there'd always be a demand for JS developers to clean up the $%#@ mess...

@jslegers

Still, I feel like I must stress that there is something seriously wrong when one deprecated or broken package can impact millions of packages across the entire ecosystem.

The only thing that is wrong is the panic you and others appear to be suffering from. leftpad went away, deleted. That can't happen now. Request has simply been deprecated; it isn't going anywhere. If it works now, it will continue to work in the same way.

There is no impact on millions of packages, unless you count a benign warning.

I also tried replacing request with something like...

Please stop panicking; please stop trying to fix a non-existent problem. Use whatever packages you like: request's deprecation is not going to break them. Gradually their package maintainers may move to another package. Or they may not. It doesn't matter. Nothing has changed, other than the appearance of one little message.

there'd always be a demand for JS developers to clean up the $%#@ mess...

There is no mess. Just progress.

There is no impact on millions of packages, unless you count a benign warning.

Deprecating eg. a part of your API or a library basically means that you officially designate it as "obsolete" and you actively encourage users to opt for something else.

Deprecation is typically used as an intermediary stage between officially supporting something and officially dropping support for something, to give developers the time to replace whatever the thing is that you've deprecated until you that thing is no longer available or backwards compatible.

Deprecation warnings are supposed to make you nervous. They are intended as a call to action. Basically, the point of deprecation is to offer developers a “grace period”, allowing them update to their code before someone pulls the plug.

And they should not be used for any other purpose. Deprecation isn't supposed to just inform your users that "Our API doesn't follow the latest coding standards" or "I don't have the time to maintain this project anymore"... even though the library is pretty stable & pretty safe to use in +99% of all uses cases and likely to continue working fine for at least the next decade or so. That's not what deprecation means, and using deprecation warnings just to express a message like that sets a very bad precedent IMO.

Also, it's just plain ugly to have your npm install logs full of deprecation warnings. It looks sloppy. It's kind of a red flag and creates a bad first impression to people trying out your library or framework. Especially if people are actually paying you to use your library / framework, you want to give them a nice / clean install process with zero warnings.

Nothing has changed, other than the appearance of one little message.

That one little message looks sloppy and is supposed to have no other purpose but as a call to action... a call to replace an obsolete package with something else.

That may not matter to you, but it definitely matters to me and other people out there.

There is no mess. Just progress.

I guess you're one of those people who can't tell the difference between change and progress.

Either way, I noticed others in the comments suggested using postman-request. Unlike @root/request, that one does seem to work as a drop-in replacement, so I'll be updating all my packages with this one for the time being...

I think what you're missing @SimpleSamples is that the rest of the warnings you pasted have nothing to do with the deprecation warning that brought you here. You don't need to do anything about the deprecation but you might want to do something about your missing package.json (or whatever is causing those other warnings).

Touché !

The point has been made yet personal attacks continue. You guys are very intelligent and highly capable technically but there is room for improvement in personal expertise.

The point has been made yet personal attacks continue. You guys are very intelligent and highly capable technically but there is room for improvement in personal expertise.

Being smart unfortunately does not prevent people from letting their emotions cloud their judgements... especially when their stuff happens like things getting deprecated seemingly without a good reason or a general consensus on what's the purpose of deprecation.

Anyway, I think I made my point quite clearly. I'd like to finish by encouraging @mikeal, @reconbot or any other maintainer of this project to officially propose postman-request as a feature-complete drop-in replacement for request, and possibly @root/request for those who just need a limited subset of request and don't care about eg. streams. This allows any package maintainer to drop request and get rid of the annoying deprecation message without spending more than a few minutes of dev time on this issue, and without having to refactor their entire library or app.

@mikeal coming up from the reality of request being deprecated, I'd like to ask you for one moment of reflection that will be helpful to some or maybe many of us. You have 2 later http request modules, subsequent to request: r2 and bent.

May I ask you to give us a short summary of the differences, benefits, and plus or minus's of moving to one of therse request replacements, over the other. I trust your work.

Thank you for this time, and may I be sure to say Thank You for the years of the request module.

-Ric

Is request-promise-native also deprecated or is it the right thing to use?

@anton-bot https://github.com/request/request-promise-native#deprecated

[email protected]: request has been duplicated ....unable to create new project

[email protected]: request has been duplicated ....unable to create new project

You can create a project just as always. NPM is simply giving you a warning.

Why has this project been deleted ?

Yes this is good

Used by 4,476,352 Repositories, 52,377 Packages.
Say goodbye to the legend.

Why has this project been deleted ?

@jleppert it hasn't, please read the issue you are commenting on.

I tried to install angular in linux and then in windows and in both I could not, after executing the command npm install -g @ angular / cli @ latest in both I appeared this error

C:\Users\Hanzell>npm install -g @angular/cli@latest
npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
C:\Users\Hanzell\AppData\Roamingnpm\ng -> C:\Users\Hanzell\AppData\Roamingnpmnode_modules\@angular\cli\bin\ng

@angular/[email protected] postinstall C:\Users\Hanzell\AppData\Roamingnpmnode_modules\@angular\cli
node ./bin/postinstall/script.js

• @angular/[email protected]
  added 260 packages from 205 contributors in 188.027s

Then, I created the repository and this appeared

C:\Users\Hanzell\Desktop>ng new
? What name would you like to use for the new workspace and initial project? hola
? Would you like to add Angular routing? No
? Which stylesheet format would you like to use? CSS
CREATE hola/angular.json (3551 bytes)
CREATE hola/package.json (1281 bytes)
CREATE hola/README.md (1021 bytes)
CREATE hola/tsconfig.json (543 bytes)
CREATE hola/tslint.json (1953 bytes)
CREATE hola/.editorconfig (246 bytes)
CREATE hola/.gitignore (631 bytes)
CREATE hola/browserslist (429 bytes)
CREATE hola/karma.conf.js (1016 bytes)

• Installing packages...npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142g.spec.json (270 bytes)
  npm ERR! Unexpected end of JSON input while parsing near '...f8x\n2SbOSCsT+zdXwIaf'

npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\Hanzell\AppData\Roamingnpm-cache_logs\2020-03-01T05_15_55_441Z-debug.log
× Package install failed, see above.
The Schematic workflow failed. See above.
CREATE hola/src/assets/.gitkeep (0 bytes

help!

@RiveraHan the problems you're having are unrelated to request being deprecated. The message that lead you here is only a warning.

That being said, I was curious. Although I haven't used angular since its JS days, I gave it a shot. Note that I didn't want to add the angular cli to my global modules, so I proceeded a bit differently. I tested the following with npm 6.14.1, node 12.16.1 and Debian GNU/Linux.

mkdir wrk-dir
cd wrk-dir
mkdir w1
cd w1
npm init -y
npm install @angular/cli --save-dev # this puts `ng` in `wrk-dir/w1/node_modules/.bin/ng`
cd ..
w1/node_modules/.bin/ng new my-app
cd my-app
../w1/node_modules/.bin/ng serve --open # browser will open with compiied results

If you install the angular cli globally, just remove ../w1/node_modules/.bin/ and w1/node_modules/.bin/ from above ng should be found globally.

@millette It didn't work on Linux ubuntu and windows 10. It's the first time I install the angular

@RiveraHan it's not an error. it's an npm warning. If whatever setup you use fails on npm warnings, then you need to check the config for it.

@csvan But, I realized when opening the new project in my code editor that the node_modules folder does not appear and do a little research to generate the node_modules folder again and it is with the npm install command I do it and the same appears another error.

@RiveraHan yes, but again this has nothing to do with request or npm - npm warnings will not break an install unless your development environment is somehow configured to do so. You need to look into why your environment does not tolerate npm warnings and what you can do about it - if that is even the problem in your case. It could very well be something completely different.

@anton-bot so offer to take over the project and put in all the work that the current maintainers do not have the time to do. It's quite arrogant to tell others how to run their project if you are not willing to put in the work yourself to make it happen. It's open source.

@mikeal has quite clearly explained why request is deprecated. It's the responsible thing to do, it's a good decision, and unlikely to be reversed.

Also, this:

Also, realistically, people are not going to replace their perfectly good working code that uses request with something else. See some of the linked pull requests - it is just not an idea that people want to do.

This is why we end up with garbage legacy code that depends on ancient modules that were "perfectly good code" in their day. Part of maintaining software is getting rid of old and deprecated modules, replacing them with actively maintained ones.

@anton-bot Just use @root/request which is basically an 80% compliant implementation of request that uses modern Node HTTP APIs under the hood.

@anton-bot You are clearly missing several facts of life:

1. This is free, open source software. You do not have the right to tell the maintainers to "Just stop it".
2. Request was past its sell-by date (although not past its use-by date). It has become weighty and old-fashioned.
3. @mikeal has produced at least two new packages that replace request. They are both much more light-weight.
4. If you and others wish to continue using it, you are free to do so. Nothing in the deprecation prevents you from doing so.

Personally, I have taken the opportunity gradually to upgrade my packages. kraken-exchange, for example, has gone down from 5.9MB to 284KB installed, by switching to bent.

@csvan said you were "quite arrogant". That's a much politer phrase than I'd have used.

@anton-bot Just use @root/request which is basically an 80% compliant implementation of request that uses modern Node HTTP APIs under the hood.

80% compliant is not nearly good enough.

I use dependencies that rely on the missing 20% (eg. streams). For that, you need a feature-complete drop-in replacement like postman-request.

I suggested in a previous comment (which seems to have been censored / deleted) that the maintainers handed over their project to the Postman team, so they could replace request's implementation with the implementation of postman-request, as that package is still actively maintained, feature-complete and fixes some of the bugs never fixed in request.

That way, the original authors of request could take a step back & enjoy their well-earned "retirement" without scaring or annoying a hell of a lot of people by deprecating request unnecessarilly.

This is free, open source software. You do not have the right to tell the maintainers to "Just stop it".

Sure he does. And much the same, the maintainers have the right to say "f* you".

Request was past its sell-by date (although not past its use-by date). It has become weighty and old-fashioned.

Still not a valid reason to deprecate.

@mikeal has produced at least two new packages that replace request. They are both much more light-weight.

So?

Thousands of packages are still using request today, and are now unnecessarily producing deprecation warnings during npm install. This should not have happened and could have easily been prevented by eg. handing over the torch to the Postman team or just letting this project die peacefully.

If you and others wish to continue using it, you are free to do so. Nothing in the deprecation prevents you from doing so.

Sure it does.

Customers that get nervous when they see deprecation warnings during npm install prevent many of us from just sitting this out and doing nothing.

Deprecation = a call to action. It basically gives people a grace period to replace their dependencies until their dependencies break. It should not be used in any other case but cases where dependencies are expected to break existing functionality after a grace period has ended.

Personally, I have taken the opportunity gradually to upgrade my packages. kraken-exchange, for example, has gone down from 5.9MB to 284KB installed, by switching to bent.

I tried replacing several of our dependencies with internalized / customized local versions of those packages & replaced request with request-postman to get rid of the deprecation warnings. This seemed like an easy fix, which would later allows us to incrementally replace request-postman with a more lightweight alternative.

Then I learnt that NPM is incredibly buggy with respect to handling with local packages that itself rely on local packages, which made our environment significantly less stable. It opened a whole 'nother can of worms, really, so I had to revert my changes and moved back to request, as it was simply not worth the time & effort to try to fix this kind of issue at this point in time.

For now, I see no other alternative than living with the deprecation warnings, as we simply use too many dependencies that have request as a dependency themselves to get rid of it with but very little headaches. This is unfortunate and IMO should never have happened!

@csvan said you were "quite arrogant". That's a much politer phrase than I'd have used.

Who are you to call a person "arrogant" or worse, just because you fail to understand why deprecation warnings matter to them and their projects?!

What I find arrogant, is to just deprecate a project millions of other projects depend on without any good reason, instead of looking for a different maintainer to take things over from you. And considering the Postman team already does have a feature-complete fork of request that is actively maintained, I can't imagine it would have been very difficult to convince them to do this.

What is your estimate, in millions of USD, of the worldwide cost of this decision to deprecate request?

Zero. It works as well as it ever did. It just won't get any better.

Zero. It works as well as it ever did. It just won't get any better.

Bullshit!

If you think deprecation warnings have no impact on projects that depend on them, you have zero clue what deprecation entails & what those messages are intended for!

Deprecation makes a lot of people very nervous, and with good reason. That's what deprecation is supposed to do!

Ah, no problem then. My back-of-the-envelope calculations are roughly USD $30m but I guess I was wrong.

USD $30m sounds like a very low estimate to me, considering how many packages depend on this project either directly or indirectly!

I am amazed and astonished how many people here think they have a right to free software.

I am amazed and astonished how many people here think they have a right to free software.

I am amazed and astonished how many people think they have no responsibility whatsoever with respect to how their actions impact their users just because their products are free or open source.

IMO it's a matter of basic respect to treat your users / customers no different whether they're paying to use your app / library or whether they're not paying.

Would you ever deprecate a project used by millions of other projects as a dependency if people were paying for it unless you had a really, really, really good reason for it (like dependent projects crashing if people don't take some kind of action in time)?

@jslegers My point exactly. So entitled! Amazing!

@jslegers My point exactly. So entitled! Amazing!

Pot...

Kettle...

I can't think of anything more entitled than arguing that users in one way or another "owe" you for giving them open source software and that they should feel "honored" or "grateful" to you and thus have no right to complain whatsoever when your actions impact their projects directly.

Sure, maintaining an open source project for years requires a lot of hard work & dedication. Sure, it's something to be admired when people are willing to do that in their own spare time without any financial compensation. But that's still no excuse for acting all entitled and leaving your users in the cold when they need you the most ánd there's several zero-effort alternatives!

@CliffS

Personally, I have taken the opportunity gradually to upgrade my packages. kraken-exchange, for example, has gone down from 5.9MB to 284KB installed, by switching to bent.

I have just had a look and the package.json is still referencing request version 2,88.0

I have just had a look and the package.json is still referencing request version 2,88.0

@JonathanRowell Yes. It's currently being tested before pushing it to npm. Version v1.9.0 will be there by the end of the day.

But that's still no excuse for acting all entitled and leaving your users in the cold when they need you the most ánd there's several zero-effort alternatives!

Exactly, which is why we have people like @jslegers willing to put a few hours of their free time every day aside to help out with the maintenance, evening the workload and taking the project forward, rather than whining in an issue!

Oh, wait.

Exactly, which is why we have people like @jslegers willing to put a few hours of their free time every day aside to help out with the maintenance, evening the workload and taking the project forward, rather than whining in an issue!

Wrong!

That's why we have the friendly folks of the Postman team, who already have their own request fork named postman-request, which can act as a feature-complete drop-in replacement for request and which is actively maintained! The common sense alternative to deprecating request would be to ask them to take over maintenance of request.

In case the Postman folks decline for whatever reason, request could still officially recommend postman-request as a feature-complete drop-in replacement in the deprecation warning, to prevent resources from being unnecessarily wasted by hundreds - of not thousands - of devs independently looking for such a drop-in replacement.

Alternatively, you could just announce officially dropping maintenance / support of request and let it die slowly & peacefully without a deprecation warning, since there is really no need to deprecate OR continue maintenance of a package that works perfectly fine and isn't about to break in the near future.

Either of these 3 approaches would be infinitely better than the current approach and wouldn't require any additional resources from any party.

I don't think arguing whether or not one or the other is entiltled to their expectations is constructive nor will help addressing the issues at hand. We all take and give, and cooperate with each other with the hope that one's own problems can be dealt with more easily, but no one can force the other to act against their will.

I believe the facts are that a) the current owner doesn't want to move the project forward anymore (perfectly understandable), but also that b) many people are feeling a lot of pain from the deprecation warning as migration away from it will not happen immediately most of the time (perfectly understandable as well).

So it seems to me that a reasonable compromise would be, similarly to what @jslegers suggests, that the project ownership be transferred to someone interested and willing to take it, remove the deprecation warning for now and manage the deprecation process in a way that is gentler to those affected by the move.

So, @mikeal , are you willing to hand over the project ownership to someone else?

And is anyone else willing to take it from Mikeal to resolve the problem people is having with the warning being issued?

Besides the cooperation for handing over the project ownership, none of us can speak for the others, telling them to do this or that; one can only speak for oneself.

one other fact that hasn't been mentioned much in this thread is the security impact of transferring ownership of a package this popular. we have had recent incidents where an ownership transfer was to a bad actor and resulted in malicious activity in new versions of the package. popular packages like this are great targets for that type of actor.

i won't comment on the trustworthiness of any specific team that could take over ownership, but it is important to recognize how risky such a suggestion really is. deprecating this package does not prevent forks from continuing to maintain this package under a different name, but the name change allows a consumer to make a decision to consume that fork rather than it happening automatically with no opportunity to evaluate the risk to their project.

one other fact that hasn't been mentioned much in this thread is the security impact of transferring ownership of a package this popular. we have had recent incidents where an ownership transfer was to a bad actor and resulted in malicious activity in new versions of the package. popular packages like this are great targets for that type of actor.

Obviously, you can't just transfer ownership to just anyone. But the Postman team sounds like a logical choice, because...

• They have a reputation to protect and therefore can't afford harming the request project by injecting malicious code into the project
• As a platform for API development & testing, it can be a marketing win for them to become the official maintainer of a very popular NPM package used by many of their potential customers
• As they already maintain their own fork of request, it should require no additional resources from them. They could just merge their fork into request, and move resources from their own fork (which would no longer be needed) to the official request repo

Obviously, there's no guarantee that they will accept. But if they had any common sense, they would jump on this immediately. So unless a request maintainer has already tried contacting them and can confirm that they did in fact decline this proposal, this is definitely worth a shot IMO!

there is really no need to deprecate OR continue maintenance of a package that works perfectly fine and isn't about to break in the near future.

This is so backwards I don't even know where to begin. That a package is unmaintained and recommended to be moved away from is the entire point of deprecation.
The owner is letting you know that you are building technical debt by using it so that you can move on. The great thing about an official deprecation via npm is exactly that people are given a clear indication of this, rather than having to discover it years down the line (in your "let it die slowly" scenario) where it is probably already too late to consider a smooth migration.

Widely used and subsequently abandoned packages do not die peacefully. They die when the people using them start moving away in a panic after their unmaintained state actually leads to stuff breaking and security holes open up.

Face it, neither you nor me would likely have known the state of request without the deprecation notice. Nor would the vast majority of users.

I tried to install angular in linux and then in windows and in both I could not, after executing the command npm install -g @ angular / cli @ latest in both I appeared this error

C:\Users\Hanzell>npm install -g @angular/cli@latest
npm WARN deprecated [email protected]: request has been deprecated, see #3142
C:\Users\Hanzell\AppData\Roamingnpm\ng -> C:\Users\Hanzell\AppData\Roamingnpmnode_modules@angular\cli\bin\ng

@angular/[email protected] postinstall C:\Users\Hanzell\AppData\Roamingnpmnode_modules@angular\cli
node ./bin/postinstall/script.js

• @angular/[email protected]
  added 260 packages from 205 contributors in 188.027s

Then, I created the repository and this appeared

C:\Users\Hanzell\Desktop>ng new
? What name would you like to use for the new workspace and initial project? hola
? Would you like to add Angular routing? No
? Which stylesheet format would you like to use? CSS
CREATE hola/angular.json (3551 bytes)
CREATE hola/package.json (1281 bytes)
CREATE hola/README.md (1021 bytes)
CREATE hola/tsconfig.json (543 bytes)
CREATE hola/tslint.json (1953 bytes)
CREATE hola/.editorconfig (246 bytes)
CREATE hola/.gitignore (631 bytes)
CREATE hola/browserslist (429 bytes)
CREATE hola/karma.conf.js (1016 bytes)

• Installing packages...npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142g.spec.json (270 bytes)
  npm ERR! Unexpected end of JSON input while parsing near '...f8x\n2SbOSCsT+zdXwIaf'

npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\Hanzell\AppData\Roamingnpm-cache_logs\2020-03-01T05_15_55_441Z-debug.log
× Package install failed, see above.
The Schematic workflow failed. See above.
CREATE hola/src/assets/.gitkeep (0 bytes

help!

Check npm update and later npm install into angular project

This is so backwards I don't even know where to begin. That a package is unmaintained and recommended to be moved away from is the entire point of deprecation.

That a package is unmaintained and REQUIRES to be moved away from before a grace period ends is the point of deprecation.

If there is no requirement to move away before a specific point in time, you should not deprecate... at least not unless you can propose a drop-in replacement (like postman-request in this case)!

The difference may be subtle, but the consequence is significant. You're wasting the resources of possibly many thousands of companies for no good reason by deprecating, which could be avoided by just ending maintenance and leaving it at that!

one other fact that hasn't been mentioned much in this thread is the security impact of transferring ownership of a package this popular. we have had recent incidents where an ownership transfer was to a bad actor and resulted in malicious activity in new versions of the package. popular packages like this are great targets for that type of actor.

... deprecating this package does not prevent forks from continuing to maintain this package under a different name

Fair enough; I guess we can wait a little bit to have news from the Postman people and assess if transferring to them is viable; but otherwise, forks appear to be the way forward, then.

No, you are not wasting anybodys time by making it clear that one of their dependencies is now abandoned and almost certainly a source of technical debt. Quite the opposite is true, and the entire discussion on this issue is proof of that - a discussion that would most likely not have happened anytime soon without the deprecation.

No, you are not wasting anybodys time by making it clear that one of their dependencies is now abandoned and almost certainly a source of technical debt.

Just because a project is abandoned, that doesn't mean it should be replaced by anything else.

Especially for projects that use multiple dependencies that all use request as a dependency themselves, the potential gain of trying to replace request with something else doesn't even come close to the effort required to achieve this!

a discussion that would most likely not have happened anytime soon without the deprecation.

This discussion would not have been necessary without the deprecation.

https://xkcd.com/386/

Yes it would at some point, with or without a deprecation. That point is always better reached earlier rather than years down the line when the effects of an unmaintained package start being felt.

Anyway, I give up on this. Have fun.

”Everything is changeable, everything appears and disappears; there is no blissful peace until one passes beyond the agony of life and death.”

— Gautama Buddha

@mikeal You're a riot man... thanks for the reminder!

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.

What happens if we just delete it? these dependencies are a killer!

@grikard I'd agree with that - good analysis. But without wanting to sound trivial - this is a genuine query - do the Americans spell the plural of "leaf" as leafs? I lernt "leaves".

leaves is plural for leaf :)

Installing packages...npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
if anyone else goes here because you are got an error about
ng new my-app
try again
sudo ng new my-app
happy hacking

Hi How to resolve this error? https://github.com/request/request/issues/3142

Hi How to resolve this error? #3142

What error?

https://github.com/request/request/issues/3142

On Wed, Mar 11, 2020, 8:23 PM Cliff Stanford notifications@github.com
wrote:

Hi How to resolve this error? #3142
https://github.com/request/request/issues/3142

What error?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/request/request/issues/3142#issuecomment-597602350,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AN6OSLTSIY5LZVUEOX3JWHDRG57FNANCNFSM4HCP6LRA
.

I can't complete my project because of this... and it's due tonight. Can anyone help with fixing this issue in request??

@AELDREI This is not an error. Deprecation ist just a warning/info, everything still works.
@valentina-js "This" is just a warning/info, so it can't be the cause of you not being able to finish your project. If you have a problem then it must have another cause. Try looking for an actual error message and see if there is a similar issue reported. If not, open one and describe your error in detail.

Oh no. This wasn't necessary. Rip

New Merch

npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142

Please solve this! I don't know what I am doing wrong:

npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN checkPermissions Missing write access to /usr/local/lib/node_modules
npm ERR! code EACCES
npm ERR! syscall access
npm ERR! path /usr/local/lib/node_modules
npm ERR! errno -13
npm ERR! Error: EACCES: permission denied, access '/usr/local/lib/node_modules'
npm ERR! [Error: EACCES: permission denied, access '/usr/local/lib/node_modules'] {
npm ERR! stack: "Error: EACCES: permission denied, access '/usr/local/lib/node_modules'",
npm ERR! errno: -13,
npm ERR! code: 'EACCES',
npm ERR! syscall: 'access',
npm ERR! path: '/usr/local/lib/node_modules'
npm ERR! }
npm ERR!
npm ERR! The operation was rejected by your operating system.
npm ERR! It is likely you do not have the permissions to access this file as the current user
npm ERR!
npm ERR! If you believe this might be a permissions issue, please double-check the
npm ERR! permissions of the file and its containing directories, or try running
npm ERR! the command again as root/Administrator.

npm ERR! A complete log of this run can be found in:
npm ERR! /Users/Hazem/.npm/_logs/2020-03-15T16_16_03_301Z-debug.log

@hazembergg NPM does not have write access to node_modules. There is nothing wrong with request that blocks npm install. Try running it with sudo.

Thanks for your prompt reply, it worked like a charm!

So I think I am going crazy! I must've read README at least 20 times. This whole program is above my basic html knowledge...

_How do I obtain youtube comments?_
Do I run youtube-comment-scraper in node? basic terminal? or command?
the node response is ...
the terminal response is the title changes but nothing happens

_What about if I wish to have a csv file?_
is the command: youtube-comment-scraper --outputFile youtubecomments.csv --stdout --format csv correct?

_Ballpark how long would it take to run the program to obtain, let's say, a thousand comments?_

@hazembergg Both. See https://www.npmjs.com/package/youtube-comment-scraper#usage for command line usage and https://www.npmjs.com/package/youtube-comment-scraper#method for programmatic usage. You can also run npx youtube-comment-scraper with Node.js installed in the command line to access the CLI.

@Richienb Thanks again for the info! I'll study them and hopefully I will succeed!

Yes, it seems that everyone is doing something wrong. I've been told there would be zero cost to the decision to deprecate request.

There's never zero cost!

I am facing issue with Creating the Sauce Tunnel.
Using the following sauce service.
npm install -g wdio-sauce-service
25hnpm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
25h

[email protected] postinstall /usr/local/lib/node_modules/wdio-sauce-service/node_modules/sauce-connect-launcher
node scripts/install.js || nodejs scripts/install.js

+ [email protected]

Getting the below error while trying to create the sauce tunnel.
Could not start Sauce Connect. Exit code 1 signal: null
A service failed in the 'onPrepare' hook
Error: Could not start Sauce Connect. Exit code 1 signal: null
at ChildProcess. (/usr/local/lib/node_modules/wdio-sauce-service/node_modules/sauce-connect-launcher/lib/sauce-connect-launcher.js:566:12)
at ChildProcess.emit (events.js:198:13)
at ChildProcess.EventEmitter.emit (domain.js:448:20)
at Process.ChildProcess._handle.onexit (internal/child_process.js:248:12)

Please be respectful and avoid posting serious questions. Only memes about request.

@anton-bot let it go and move on with your life.

Please be respectful and avoid posting serious questions. Only memes about request.

@anton-bot let it go and move on with your life.

Back to seriousness, now that request has been "officially" deprecated via npm deprecate, now _every_ single upstream user is getting new warnings about it.

Can we consider this for a moment? I think this has caused undue panic. Not only that but automated systems that commit their logs are now referencing this issue b/c of the issue key in deprecation warning.

I'm in agreement that request has matured to the point of obsolescence, but if it still works fine and has hundreds of dependencies with varying levels of upkeep, perhaps it shouldn't be officially deprecated in npm but rather a big ol' warning in maximum font in the README?

And then one day every one of those users will say: "Why weren't we warned about this!?" 😄

but if it still works fine and has hundreds of dependencies with varying levels of upkeep, perhaps it shouldn't be officially deprecated in npm but rather a big ol' warning in maximum font in the README?

The problem is that essentially _nobody_ reads those. 99% of people having a panic now would never even have known request was deprecated unless NPM warned them about it. _Nobody_ sits and combs through the README of _all_ their dependencies to figure out which ones are no longer maintained - until it's too late.

I am repeating myself, but the scenario you are proposing essentially means that people will instead find out the hard way that request is deprecated - when it eventually starts breaking stuff and causing security holes due to being an old, unmaintained dep in a modern environment. When that happens, people will instead need to _scramble_ for an alternative, rather than having the chance - as it is now - to look for one while request is still stable and usable, which is probably another year at least.

Deprecating request was the responsible thing to do, and it is not going to be reversed. The community should focus their efforts on agreeing on a good alternative and/or fork rather than trying to get this overturned. Move on.

WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142 .
How can I fix that error?

@mrmehi Can you please read the very first message here?

It is not an error. Either you directly depend on request (and then you should move to another library, e. g. got or bent), or you transitively depend on it through one of your dependencies - then either update it if they moved on already, or ping them to move on.

@kibertoad I'm really confused what should I do now?
it happens when I try to download expo.io

@kibertoad I'm really confused what should I do now?
it happens when I try to download expo.io

You don't have to do anything. It's not an error, it's a warning. That's what the "WARN" part of the log indicates.
You _could_ make expo.io aware that they might want to start looking for alternatives to request, because it is deprecated and thus might some day stop working properly.
But they seem to be aware of that already, as you can see here:
https://github.com/expo/expo-cli/issues/1659

Microsoft is still relying on this package. appcenter-cli gives this deprecation warning on install:

npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142

Given the AppCenter team's track record it seems unlikely this is going to change any time soon. Our build logs are full of warnings about packages that were deprecated more than a year ago in some cases.

Please Some One can help me i am facing difficulty while installing the expo-cli --global.
i have installed node ,git . i write command as npm install expo-cli --global but facing issue as :
"npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
[..................] | fetchMetadata: WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142"".
what i am getting this error . kindly reply me how to solve this issue.

@mrmehi Can you please read the very first message here?

It is not an error. Either you directly depend on request (and then you should move to another library, e. g. got or bent), or you transitively depend on it through one of your dependencies - then either update it if they moved on already, or ping them to move on.

please can you help me to solve this issue ? i am facing the issue.

@lemessur Turns out, the maintainers simply didn't know that request was deprecated. See https://github.com/microsoft/appcenter-cli/pull/758#issuecomment-603667106

Someone, please put this at the top of the main issue comment:

Deprecation notice

If you are getting WARN deprecated [email protected]: request has been deprecated, see #3142 when trying to install your dependencies, please be assured that this is NOT an error. The author of the package you are installing (or you if you depend on request) needs to migrate to another library. See: https://github.com/request/request/issues/3143

@alijatoi
See https://github.com/request/request/issues/3142#issuecomment-604126783

@Richienb
See #3142 (comment)

So what should i do now . please can you help me to solve this issue?

@Richienb
See #3142 (comment)

I am new in github and could not understand what to do . can you please tell me step by step how can i solve my issue? looking for your quick resposne.

@alijatoi expo-cli is using request therefore it's dependency must be changed.

@Richienb So what should i do now ? should i wait or is there any other way to install the expo-cli.
please help me i waiting .
thankyou

@alijatoi Create an issue and/or wait.

@Richienb thankyou for your response.
there is not any other way to install expo cli?

@alijatoi no

guys, if you are facing troubles install expo-cli with npm because of depreacted message: install yarn then yarn install expo-cli

@caio-vinicius That only works because yarn only displays the warning once and will continue to display it when regenerating the lockfile.

guys, if you are facing troubles install expo-cli with npm because of depreacted message: install yarn then yarn install expo-cli

@caio-vinicius yes i have done installing by using install yarn then yarn install expo-cli globlly but after installing when i check for the version of expo cli it gives issue that expo is not define any internl or external command

@alijatoi please make sure you are using the correct syntax when using yarn to install globally.

https://classic.yarnpkg.com/en/docs/cli/global/

However, @alijatoi, an install breaking over a deprecation warning is almost certainly a problem with your environment or the package you are trying to install. It's not specific to request and nothing you should report here.

I'm a bit late to the party but it would be nice to add a small list of alternatives so folks can use them to replace the request, like nodejs built in http.ClientRequest. Thanks.

uuuh https://github.com/request/request/issues/3143

F

I agree with everything you said about form, compatibility and progress, but
I cannot see why [email protected] cannot do it with breaking changes. After all - that's the idea behind semver...

Many other libraries have adopted to the new patterns and capabilities, and therefore broke compatibility and raised their major.

Even if it's a completely new module - the name represents the credibility and
experience of lessons learnt, which I'm sad to see going away.

Interested learning more about this.

Well, thanks for the ride and all the hard work you've put in. 👍

You my lord, are a hero.

I do understand the reason behind it, its making JS/Node (in general), progress a little bit faster.

You did 'almost' as much, for the NodeJS space as jQuery did for the browser/DOM space. You made it a joy to work with TCP, and thats critical for back-end development.

I thank you for this.

Take care.

So what's the guide on the alternative way of making https request for me that is new to back end development with node?

@OluwafemiAdesegha https://github.com/request/request/issues/3143

Thanks Cliff. Will have a look.

npm WARN registry Unexpected warning for https://registry.npmjs.org/: Miscellaneous Warning EINTEGRITY: sha512-7G3s83fOoweLlAsvR3wtw4DnepkrY+/FxmYxk1XnfAjE9xnoWRy9cLHWCywcc6l6018X1RdNxpJdtqX9WQAEXw== integrity checksum failed when using sha512: wanted sha512-7G3s83fOoweLlAsvR3wtw4DnepkrY+/FxmYxk1XnfAjE9xnoWRy9cLHWCywcc6l6018X1RdNxpJdtqX9WQAEXw== but got sha512-NhZAWqNqTzZaAfgJYp0NlbBDUX8BMyOmobe3kYnymXfSxDgaiej4nP6N3aLVDtBTPHOfivySRs+AVsca0JgrTQ==. (20905 bytes)
npm WARN registry Using stale data from https://registry.npmjs.org/ due to a request error during revalidation.
npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
npm ERR! code EINTEGRITY
npm ERR! errno EINTEGRITY
npm ERR! Invalid response body while trying to fetch https://registry.npmjs.org/uuid: Integrity verification failed for sha512-7G3s83fOoweLlAsvR3wtw4DnepkrY+/FxmYxk1XnfAjE9xnoWRy9cLHWCywcc6l6018X1RdNxpJdtqX9WQAEXw== (C:\Users\MULAMBA SERGIO\AppData\Roamingnpm-cache_cacache\content-v2\sha512\ec\6d\ecf377cea3078b940b2f477c2dc380e77a992b63efc5c666319355e77c08c4f719e8591cbd70b1d60b2c1c73a97ad35f17d5174dc6925db6a5fd5900045f)

npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\MULAMBA SERGIO\AppData\Roamingnpm-cache_logs\2020-04-03T22_54_57_842Z-debug.log

npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated [email protected]: This version has been deprecated in accordance with the hapi support policy (hapi.im/support). Please upgrade to the latest version to get the best features, bug fixes, and security patches. If you are unable to upgrade at this time, paid support is available for older versions (hapi.im/commercial).
npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated [email protected]: core-js@<3 is no longer maintained and not recommended for usage due to the number of issues. Please, upgrade your dependencies to the actual version of core-js@3.
npm WARN deprecated [email protected]: This version has been deprecated in accordance with the hapi support policy (hapi.im/support). Please upgrade to the latest version to get the best features, bug fixes, and security patches. If you are unable to upgrade at this time, paid support is available for older versions (hapi.im/commercial).
npm WARN deprecated [email protected]: This version has been deprecated in accordance with the hapi support policy (hapi.im/support). Please upgrade to the latest version to get the best features, bug fixes, and security patches. If you are unable to upgrade at this time, paid support is available for older versions (hapi.im/commercial).
npm WARN deprecated [email protected]: This version has been deprecated in accordance with the hapi support policy (hapi.im/support). Please upgrade to the latest version to get the best features, bug fixes, and security patches. If you are unable to upgrade at this time, paid support is available for older versions (hapi.im/commercial).
npm WARN deprecated [email protected]: This module has moved and is now available at @hapi/topo. Please update your dependencies as this version is no longer maintained an may contain bugs and security issues.
npm WARN deprecated [email protected]: This module has moved and is now available at @hapi/hoek. Please update your dependencies as this version is no longer maintained an may contain bugs and security issues.
C:\Users\Matheus\AppData\Roaming\npm\expo -> C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\bin\expo.js
C:\Users\Matheus\AppData\Roaming\npm\expo-cli -> C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\bin\expo.js
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: @expo/[email protected] (node_modules\expo-cli\node_modules\@expo\traveling-fastlane-darwin):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for @expo/[email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: @expo/[email protected] (node_modules\expo-cli\node_modules\@expo\ngrok-bin\node_modules\@expo\ngrok-bin-linux-arm):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for @expo/[email protected]: wanted {"os":"linux","arch":"arm"} (current: {"os":"win32","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: @expo/[email protected] (node_modules\expo-cli\node_modules\@expo\ngrok-bin\node_modules\@expo\ngrok-bin-darwin-ia32):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for @expo/[email protected]: wanted {"os":"darwin","arch":"ia32"} (current: {"os":"win32","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: @expo/[email protected] (node_modules\expo-cli\node_modules\@expo\ngrok-bin\node_modules\@expo\ngrok-bin-freebsd-x64):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for @expo/[email protected]: wanted {"os":"freebsd","arch":"x64"} (current: {"os":"win32","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: @expo/[email protected] (node_modules\expo-cli\node_modules\@expo\ngrok-bin\node_modules\@expo\ngrok-bin-freebsd-ia32):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for @expo/[email protected]: wanted {"os":"freebsd","arch":"ia32"} (current: {"os":"win32","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: @expo/[email protected] (node_modules\expo-cli\node_modules\@expo\ngrok-bin\node_modules\@expo\ngrok-bin-linux-ia32):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for @expo/[email protected]: wanted {"os":"linux","arch":"ia32"} (current: {"os":"win32","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: @expo/[email protected] (node_modules\expo-cli\node_modules\@expo\ngrok-bin\node_modules\@expo\ngrok-bin-linux-x64):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for @expo/[email protected]: wanted {"os":"linux","arch":"x64"} (current: {"os":"win32","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: @expo/[email protected] (node_modules\expo-cli\node_modules\@expo\ngrok-bin\node_modules\@expo\ngrok-bin-darwin-x64):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for @expo/[email protected]: wanted {"os":"darwin","arch":"x64"} (current: {"os":"win32","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: @expo/[email protected] (node_modules\expo-cli\node_modules\@expo\ngrok-bin\node_modules\@expo\ngrok-bin-win32-ia32):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for @expo/[email protected]: wanted {"os":"win32","arch":"ia32"} (current: {"os":"win32","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: @expo/[email protected] (node_modules\expo-cli\node_modules\@expo\ngrok-bin\node_modules\@expo\ngrok-bin-sunos-x64):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for @expo/[email protected]: wanted {"os":"sunos","arch":"x64"} (current: {"os":"win32","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: @expo/[email protected] (node_modules\expo-cli\node_modules\@expo\ngrok-bin\node_modules\@expo\ngrok-bin-linux-arm64):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for @expo/[email protected]: wanted {"os":"linux","arch":"arm64"} (current: {"os":"win32","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@^1.2.7 (node_modules\expo-cli\node_modules\chokidar\node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})
npm WARN @expo/[email protected] requires a peer of sharp-cli@^1.10.0 but none is installed. You must install peer dependencies yourself.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\abbrev):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\abbrev' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.abbrev.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\ansi-regex):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\ansi-regex' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.ansi-regex.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\aproba):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\aproba' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.aproba.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\balanced-match):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\balanced-match' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.balanced-match.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\chownr):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\chownr' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.chownr.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\code-point-at):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\code-point-at' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.code-point-at.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\concat-map):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\concat-map' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.concat-map.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\console-control-strings):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\console-control-strings' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.console-control-strings.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\core-util-is):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\core-util-is' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.core-util-is.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\deep-extend):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\deep-extend' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.deep-extend.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\delegates):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\delegates' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.delegates.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\detect-libc):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\detect-libc' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.detect-libc.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\fs.realpath):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\fs.realpath' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.fs.realpath.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\has-unicode):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\has-unicode' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.has-unicode.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\inherits):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\inherits' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.inherits.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\ini):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\ini' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.ini.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\isarray):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\isarray' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.isarray.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\minimist):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\minimist' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.minimist.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\ms):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\ms' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.ms.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\npm-normalize-package-bin):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\npm-normalize-package-bin' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.npm-normalize-package-bin.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\number-is-nan):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\number-is-nan' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.number-is-nan.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\object-assign):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\object-assign' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.object-assign.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\os-homedir):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\os-homedir' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.os-homedir.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\os-tmpdir):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\os-tmpdir' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.os-tmpdir.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\path-is-absolute):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\path-is-absolute' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.path-is-absolute.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\process-nextick-args):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\process-nextick-args' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.process-nextick-args.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\safe-buffer):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\safe-buffer' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.safe-buffer.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\safer-buffer):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\safer-buffer' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.safer-buffer.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\sax):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\sax' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.sax.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\semver):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\semver' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.semver.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\set-blocking):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\set-blocking' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.set-blocking.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\signal-exit):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\signal-exit' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.signal-exit.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\strip-json-comments):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\strip-json-comments' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.strip-json-comments.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\util-deprecate):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\util-deprecate' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.util-deprecate.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\wrappy):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\wrappy' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.wrappy.DELETE'
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\expo-cli\node_modules\fsevents\node_modules\yallist):
npm WARN enoent SKIPPING OPTIONAL DEPENDENCY: ENOENT: no such file or directory, rename 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules\yallist' -> 'C:\Users\Matheus\AppData\Roaming\npm\node_modules\expo-cli\node_modules\fsevents\node_modules.yallist.DELETE'

npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
please can you help me? I cannot solve this problem and I cannot start my project

npm WARN deprecated [email protected]: request has been deprecated, see #3142
please can you help me? I cannot solve this problem and I cannot start my project

Me neither

@liaz98 @TheLitz it's not an error, it's a warning. If your project will not build/start due to an npm warning, then something is wrong with your project and/or environment. This is not a problem with request.

@liaz98 @TheLitz it's not an error, it's a warning. If your project will not build/start due to an npm warning, then something is wrong with your project and/or environment. This is not a problem with request.

but when I try to run the Expo, it doesn't work

@TheLitz then that is a problem with Expo, and you should report it in their bug tracker. It's nothing that can or will be solved on the request side.

@TheLitz then that is a problem with Expo, and you should report it in their bug tracker. It's nothing that can or will be solved on the request side.

Ok. Thanks

we request a request future.

tldr;
what am i supposed to use now ?

@YashKumarVerma https://github.com/request/request/issues/3143

@YashKumarVerma use postman-request

@TheLitz then that is a problem with Expo, and you should report it in their bug tracker. It's nothing that can or will be solved on the request side.

are you solve this issue????
npm WARN deprecated [email protected]: request has been deprecated,

So what's the guide on the alternative way of making https request for me that is new to back end development with node?

@OluwafemiAdesegha
Did you manage to get some clarity on where to move? I am in the same boat as you! :(

To anyone looking for alternatives, look at #3143 (@farhan3040 @OluwafemiAdesegha @iamdesfranco )

@mikeal I'd recommend closing this issue ;)

@iamdesfranco @farhan3040 HTTP was deprecated, please use Gopher or UDP

@mikeal I'd recommend closing this issue ;)

Or rather lock it. Essentially everything that needs to be said has been said at this point, and the only questions being asked tend to be ones that are already answered (multiple times).

Franco,

Apology for the late response. I'm still trying to see which I would
finally go with based on the suggestions given.

On Mon, Apr 6, 2020, 9:12 AM Franco Labuschagne notifications@github.com
wrote:

So what's the guide on the alternative way of making https request for me
that is new to back end development with node?

Did you manage to get some clarity on where to move? I am in the same boat
as you! :(

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/request/request/issues/3142#issuecomment-609643295,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOL4QYXM7V2BUK5LZCS7LDDRLGFH5ANCNFSM4HCP6LRA
.

and possible alternatives refer to this issue.

Where I found the alternatives in this page?

Is the suggestion to use fetch in browser + fetch lib for node, or just a promise based alternative etc?

@TomYeoman The suggestion is to not use request.

@gcacars Alternatives here: https://github.com/request/request/issues/3143

@Richienb thanks. I think that is important to have a link to this in the README.

I removed "node_modules" folder & "package-lock.json" file and then execute following 2 commands.
npm init
npm install

And then, it worked properly.

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

Brilliant accidental(?) pun

npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142

how to solve this??,

@anton-bot No malware please.

npm WARN deprecated [email protected]: request has been deprecated, see #3142

how to solve this??,

@Amouthinie there is nothing to solve, it's not an error. NPM is warning you that request is deprecated and you (or whoever maintains your dependencies which in turn depend on request) should consider moving to an actively maintained package instead.

Tenho tido dois problemas:
1 - sudo apt-get install nodejs npm
Lendo listas de pacotes... Pronto
Construindo árvore de dependências
Lendo informação de estado... Pronto
nodejs is already the newest version (13.13.0-1nodesource1).
Alguns pacotes não puderam ser instalados. Isto pode significar que
você solicitou uma situação impossível ou, se você está usando a
distribuição instável, que alguns pacotes requeridos não foram
criados ainda ou foram retirados da "Incoming".
A informação a seguir pode ajudar a resolver a situação:

Os pacotes a seguir têm dependências desencontradas:
nodejs : Conflita: npm
E: Impossível corrigir problemas, você manteve (hold) pacotes quebrados.

2 - sudo npm install -g @angular/cli
npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
npm ERR! code EEXIST
npm ERR! syscall symlink
npm ERR! path ../lib/node_modules/@angular/cli/bin/ng
npm ERR! dest /usr/bin/ng
npm ERR! errno -17
npm ERR! EEXIST: file already exists, symlink '../lib/node_modules/@angular/cli/bin/ng' -> '/usr/bin/ng'
npm ERR! File exists: /usr/bin/ng
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! /home/anderson/.npm/_logs/2020-04-17T16_25_56_704Z-debug.log

Sou usuário Linux Mint 19.3 Cinnamon, 4.4.8, 5.3.0-46-generic

Alguem consegue me ajudar?

@LeloCorrea Your error is not related to request, it's a problem with creating a symlink in your local environment:

npm ERR! EEXIST: file already exists, symlink '../lib/node_modules/@angular/cli/bin/ng' -> '/usr/bin/ng'

@LeloCorrea Seu erro não está relacionado request, é um problema com a criação de um link simbólico no seu ambiente local:

npm ERR! EEXIST: file already exists, symlink '../lib/node_modules/@angular/cli/bin/ng' -> '/usr/bin/ng'

Sabe como posso resolver esse problema?

@LeloCorrea Seu erro não está relacionado request, é um problema com a criação de um link simbólico no seu ambiente local:
npm ERR! EEXIST: file already exists, symlink '../lib/node_modules/@angular/cli/bin/ng' -> '/usr/bin/ng'

Sabe como posso resolver esse problema?

Not the exact same problem, but the solution may be the same. You should start here:

https://stackoverflow.com/questions/48808384/angular-cli-error-path-and-code-eexist

Also, again, this problem is not related to request in any way, you should ask for help about the Angular CLI in the relevant issue tracker.

So what's the recommended alternative? Just using http/https packages?

@RonRofe I am using https://github.com/sindresorhus/got, seems to be a nice successor, it has a guide on how to migrate from request.

@RonRofe there is a (WIP) list of alternatives here: https://github.com/request/request/issues/3143

I'm sad to this go, request has been my go-to lib for as long as I can remember.
I can only thank the author and contributors for the incredible work they've put in this over the years, and hope your next adventure is as exciting as this one was.
Cheers!

can you give recommendations for alternatives in your first sticky comment?

Hello , i am trying to create a new angular project and i have this error :
/ Installing packages...npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated [email protected]: Chokidar 2 will break on node v14+. Upgrade to chokidar 3 with 15x less dependencies.
npm WARN deprecated [email protected]: fsevents 1 will break on node v14+. Upgrade to fsevents 2 with massive improvements.
npm WARN deprecated [email protected]: Please see https://github.com/lydell/urix#deprecated
npm WARN deprecated [email protected]: https://github.com/lydell/resolve-url#deprecated
npm ERR! Unexpected end of JSON input while parsing near '...":{"@angular/core":"5'

npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\dell\AppData\Roamingnpm-cache_logs\2020-04-21T11_50_16_582Z-debug.log
× Package install failed, see above.
The Schematic workflow failed. See above.
Could anyone help me with this ?

Hello , i am trying to create a new angular project and i have this error :
/ Installing packages...npm WARN deprecated [email protected]: request has been deprecated, see #3142
npm WARN deprecated [email protected]: Chokidar 2 will break on node v14+. Upgrade to chokidar 3 with 15x less dependencies.
npm WARN deprecated [email protected]: fsevents 1 will break on node v14+. Upgrade to fsevents 2 with massive improvements.
npm WARN deprecated [email protected]: Please see https://github.com/lydell/urix#deprecated
npm WARN deprecated [email protected]: https://github.com/lydell/resolve-url#deprecated
npm ERR! Unexpected end of JSON input while parsing near '...":{"@angular/core":"5'

npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\dell\AppData\Roamingnpm-cache_logs\2020-04-21T11_50_16_582Z-debug.log
× Package install failed, see above.
The Schematic workflow failed. See above.
Could anyone help me with this ?

me too

CREATE my-project/angular.json (3598 bytes)
CREATE my-project/package.json (1286 bytes)
CREATE my-project/README.md (1026 bytes)
CREATE my-project/tsconfig.json (489 bytes)
CREATE my-project/tslint.json (3125 bytes)
CREATE my-project/.editorconfig (274 bytes)
CREATE my-project/.gitignore (631 bytes)
CREATE my-project/browserslist (429 bytes)
CREATE my-project/karma.conf.js (1022 bytes)
CREATE my-project/tsconfig.app.json (210 bytes)
CREATE my-project/tsconfig.spec.json (270 bytes)
CREATE my-project/src/favicon.ico (948 bytes)
CREATE my-project/src/index.html (295 bytes)
CREATE my-project/src/main.ts (372 bytes)
CREATE my-project/src/polyfills.ts (2835 bytes)
CREATE my-project/src/styles.css (80 bytes)
CREATE my-project/src/test.ts (753 bytes)
CREATE my-project/src/assets/.gitkeep (0 bytes)
CREATE my-project/src/environments/environment.prod.ts (51 bytes)
CREATE my-project/src/environments/environment.ts (662 bytes)
CREATE my-project/src/app/app-routing.module.ts (246 bytes)
CREATE my-project/src/app/app.module.ts (393 bytes)
CREATE my-project/src/app/app.component.html (25757 bytes)
CREATE my-project/src/app/app.component.spec.ts (1071 bytes)
CREATE my-project/src/app/app.component.ts (214 bytes)
CREATE my-project/src/app/app.component.css (0 bytes)
CREATE my-project/e2e/protractor.conf.js (808 bytes)
CREATE my-project/e2e/tsconfig.json (214 bytes)
CREATE my-project/e2e/src/app.e2e-spec.ts (643 bytes)
CREATE my-project/e2e/src/app.po.ts (301 bytes)
/ Installing packages...npm WARN deprecated [email protected]: TSLint has been deprecated in favor of ESLint. Please see https://github.com/palantir/tslint/issues/4534 for more information.
npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated [email protected]: Upgrade to chokidar 3 with 15x less dependencies. Chokidar 2 will break on node v14.
npm WARN deprecated [email protected]: Please see https://github.com/lydell/urix#deprecated
npm WARN deprecated [email protected]: https://github.com/lydell/resolve-url#deprecated
npm ERR! Unexpected end of JSON input while parsing near '....0.1","systemjs":"^0.'

npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\92306\AppData\Roamingnpm-cache_logs\2020-04-21T16_08_05_350Z-debug.log
× Package install failed, see above.
The Schematic workflow failed. See above.

@awais0048 @xunyegege your error has nothing to do with request. Study the actual output and it tells you precisely what the error is. If you have further problems with the Angular CLI, report it in their issue tracker.

@awais0048 @xunyegege your error has nothing to do with request. Study the actual output and it tells you precisely what the error is. If you have further problems with the Angular CLI, report it in their issue tracker.

I tried to upgrade NPM and node but no clue . if anyone find solution can you tell me please ?

@ANadjia again, the error has nothing to do with this package. You should ask in the tracker for Angular CLI.

Hi , Installing packages...npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142 npm ERR! Unexpected end of JSON input while parsing near '...ZXQ4dst\n4bcYaiOdlbvh'
when i create new project
any suggestions

Two months ago...

https://github.com/request/request/issues/3142#issuecomment-585561589

@mohamedelsoufi this is a problem with your environment or project, not this package. NPM is only warning you that this package is deprecated.

@milette
Good idea to keep this thread running as a reminder of the consequences of deprecating a package used in 99% of projects in the world.

@anton-bot Actually a reminder of how many people don't RTFM.

@csvan and they say it's not their problem too
Any way i finally got things to work for me .
So basically :
1 / i downgrade to node js version 10.13.0 ;
2 / i deleted manually the npm_cache folder
3 / run npm install ;
and by magic it worked

@ANadjia good to hear!

The suggested replacement is unclear. What should we be using instead?

@johnworthley whatever works for you. There is a list of suggested alternatives here: https://github.com/request/request/issues/3143

@johnworthley whatever works for you. There is a list of suggested alternatives here: #3143

hmm nice place https://www.youtube.com/watch?v=riuZHZPcZsg

Can we still use this library even if it is deprecated? Please advise @mikeal

Can we still use this library even if it is deprecated? Please advise

@DokurOmkar Yes. There is nothing preventing you from using the library. It's simply a warning. However, it is deprecated for a reason: there are better, more modern libraries out there. Read this thread and you will find a link to a list of alternative libraries.

not able to create a new angular project
it is failing due to -
npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142

@adibhosale Do you have more information? What are the other messages in the console that you are seeing?

@adibhosale no, it's not failing because of that. If it does, then it's a problem with angular-cli, not this package. Check the rest of the log output.

@anton-bot
Reply to - > @adibhosale Do you have more information? What are the other messages in the console that you are seeing?

This the error I am getting while creating new angular project.

Installing packages...npm WARN deprecated [email protected]: TSLint has been deprecated in favor of ESLint. Please see https://github.com/palantir/tslint/issues/4534 for more information.
npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated [email protected]: Chokidar 2 will break on node v14+. Upgrade to chokidar 3 with 15x less dependencies.
npm WARN deprecated [email protected]: fsevents 1 will break on node v14+ and could be using insecure binaries. Upgrade to fsevents 2.
npm WARN deprecated [email protected]: Please see https://github.com/lydell/urix#deprecated
npm WARN deprecated [email protected]: https://github.com/lydell/resolve-url#deprecated
npm ERR! cb() never called!

npm ERR! This is an error with npm itself. Please report this error at:
npm ERR! https://npm.community

npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\adibh\AppData\Roamingnpm-cache_logs\2020-05-05T08_46_31_829Z-debug.log
× Package install failed, see above.
The Schematic workflow failed. See above.

I'm confused about why so many users report totally irrelevant details to this issue?

seems most of the users who came here have no idea what they are doing, probably don't even understand what word deprecated means.

but the last message posted here, there is more than one deprecation message, why do they pick reporting to this issue? because some users already did and they just continue?

and the last bit of that specific message, specifically tells that npm bug should be reported to npm.community.

the maintainers here I think should delete all non-relevant discussion items to requests deprecation, and lock discussions here.

maybe the deprecation message of requests package should be changed to a link, rather issue, like lydell/urix and lydell/resolve-url packages do, so the flood of irrelevant posts doesn't appear here.

@glensc Who knew that deprecating a package used by almost every JS project in the world would have unintended consequences!

@glensc we are reporting to this particular issue because at time of angular/CLI installation we are provided with the link to this issue.

Thank you :-)

If it says WARN, it means that it's not an ERR. Just some facts.

@adibhosale no, you are given an NPM warning which has a link to this github issue - among MANY other links in the same log output. The warning has nothing to do with the failure, you need to read the log more carefully. It clearly states that:

npm ERR! cb() never called!
npm ERR! This is an error with npm itself. Please report this error at:
npm ERR! https://npm.community

and that is the reason the install fails. You need to do your due diligence and figure out what causes this before reporting an issue in a package which has absolutely nothing to do with it.

@anton-bot you keep saying that. Do you have anything constructive at all to contribute or are you still just here to troll?

@csvan @leoskyrocker @glensc I apologize for initiating this. Will be taking care in future. Thank you :-)

how to solve this issue
not able to create a angular project
issue

////////

deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN checkPermissions Missing write access to /usr/local/lib/node_modules
npm ERR! code EACCES
npm ERR! syscall access
npm ERR! path /usr/local/lib/node_modules
npm ERR! errno -13
npm ERR! Error: EACCES: permission denied, access '/usr/local/lib/node_modules'
npm ERR! [Error: EACCES: permission denied, access '/usr/local/lib/node_modules'] {
npm ERR! errno: -13,
npm ERR! code: 'EACCES',
npm ERR! syscall: 'access',
npm ERR! path: '/usr/local/lib/node_modules'
npm ERR! }
npm ERR!
npm ERR! The operation was rejected by your operating system.
npm ERR! It is likely you do not have the permissions to access this file as the current user
npm ERR!
npm ERR! If you believe this might be a permissions issue, please double-check the
npm ERR! permissions of the file and its containing directories, or try running
npm ERR! the command again as root/Administrator.

npm ERR! A complete log of this run can be found in:
npm ERR! /Users/vivek/.npm/_logs/2020-05-05T11_48_34_569Z-debug.log

@vivek08011991 the log output explains what you need to do. This is a problem with you trying to install angular globally without using sudo. It has nothing to do with this package.

hey Man this all a shit of talking, never mind,
i will tell you the solution
i tried 3 days then i got it
first: npm install npm
seconde: npm uninstall --save react-native-cli
finally: npm install -g @angular/cli

hey Man this all a shit of talking, never mind,
i will tell you the solution
i tried 3 days then i got it
first: npm install npm
seconde: npm uninstall --save react-native-cli
finally: npm install -g @angular/cli

Man you were right alhamdou lil allah. Why react cli is causing the problem ? is there some ugly competition practices right there ? thanks buddy

please pay attention to this is request module issue tracker, not angular.

• https://lmgtfy.com/?q=angular+cli

Can someone tell me the alternative to request?

I am reading this, and I much prefer request's simplistic API:

https://www.twilio.com/blog/2017/08/http-requests-in-node-js.html

@dolanmiu Sure. Anyone who has read the thread you just posted to (or even searched it for _alternative_) could tell you that there is a list of alternatives at https://github.com/request/request/issues/3143.

@dolanmiu @root/request is a mostly drop-in replacement.

@Richienb between postman-request (also a drop-in replacement) and @root/request, which one is better? postman-request doesn't have TypeScript typings which is an issue.

@anton-bot Definitely @root/request.

I have been using request for a while now and I agree with mikeal. Node's native modules have been developed over time to match this request module that there isn't just any reason to use it anymore, other than to repeatedly fix the code when a new version of request came out.

request will be written forever in the stones of history; node has grown up. This is about the time when we need to let some things go. request has always been a pioneer in innovative features, and I'll feel that without request, node development wouldn't have been as great.

As a young programmer, I loved using this package, but I also know that in order to improve and build even greater programs, one must not linger in the past any longer.

As a young programmer, I loved using this package

That made me laugh. As I young programmer, I used Commodore BASIC. :smiley:

@darkRaspberry:

1. read your error report to the end, not just the first line, there's clearly written what is the error and even suggestion what to do. you clearly have not read past the first line.
2. did you google your error?
3. read previous discussions and please explain why you post this here, your problem report has nothing to do with requests module.

just disable your antivirus you won't get any errors
Thank you !!!

@glensc I completely reinstalled my terminal to remove any other version of node then i tried "sudo"
And it worked.
I am using node version of nodejs by using curl to add node js in my PPA.

and Here it worked
dark@darkRaspberry:~$ sudo npm install firebase-tools -g

npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
/usr/bin/firebase -> /usr/lib/node_modules/firebase-tools/lib/bin/firebase.js
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@~2.1.2 (node_modules/firebase-tools/node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

+ [email protected]
updated 2 packages in 42.696s

This made me emotional. And :bow: to all the contributors!

@sudarsan2017 That error is not related to request in any way

Olá! pessoal passe pelo mesmo problema no Windows e resolvi usando o comando

npm install [email protected]

Espero que de certo o de vocês.

I am getting npm Warn npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142

How do I fix it ?

@aman78600 There is no way to fix it.

I am getting npm Warn npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142

@aman78600 It doesn't need fixing. It's just a warning that request has been deprecated.

Your NPM says to come here for alternatives, but I don't see them.

Your NPM says to come here for alternatives, but I don't see them.

@skeddles If you had pressed Control-F and searched for alternatives, you'd have found the link to https://github.com/request/request/issues/3143.

I can't install vue-cli from this command npm install -g @vue/cli its show the message : npm WARN deprecated [email protected]: request has been deprecated

@somnangrom This can't be true, I am sure there are some other messages in the console and not just this one line.

I really wanted to say thank you so much for working on this package. It is helped me a lot in my projects. Totally understandable reasons why support is stopped.

You did an awesome job, you should proud yourselves!

🤝

I am unable to install latest version of Angular CLI.
Nodejs 64 bit version: 12.18.1
npm version: 6.13.6
When I run npm install -g @angular/cli@latest to install latest version of Angular CLI, it gives me following error warning
npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142

Installation stucks with message: postinstall: sill install executeActions
Please help me out on resolving this problem

I am unable to install latest version of Angular CLI.
I have installed Nodejs on my Windows 10 Pro Laptop
Nodejs 64 bit version: 12.18.1
npm version: 6.13.6
When I run npm install -g @angular/cli@latest to install latest version of Angular CLI, it gives me following error warning
npm WARN deprecated [email protected]: request has been deprecated, see #3142

Installation stucks with message: postinstall: sill install executeActions
Please help me out on resolving this problem

@anjaikr and @aman78600 refer https://github.com/angular/angular-cli/wiki/stories-1.0-update for installing the latest version hope it helps

npm install -g json-server is not working what should i do ?

We can still use it for basic actions , right?

i am getting error while intalling angular 5, i tried to install but it is showing request has been depreceated...what should i do

@mikeal To be clear, do you intend for bent to replace request?

Hello,

Somebody know what's the problem:
npm i -g json-server
npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated [email protected]: this library is no longer supported

Thx.

One of the dumbest reasons I've heard for depreciation. Imagine if Google and Microsoft took all of their products of the shelves because it's "much harder for new libraries accomplishing similar tasks to gain adoption" and because "there’s a transition happening now in the ecosystem to these patterns". Completely ridiculous.

Firstly show my respect to this repo, however, to be honest, what @cypheron said did make sense.

@Wenjie-Shao No sense whatsoever, I'm afraid. Without the deprecation notice, even more people would be downloading and using this library without realising it was out of date. @mikeal has done a great service to the community by formally deprecating this library rather than just letting it rot. Maybe the mistake was in linking to this thread though.

I'm just trying to fumble my way through the tutorial for setting up surge.sh.

Seems like you guys got a lot going on in here. Is it gonna screw me up here in the new future if I just kind of ignore the warnings and leave?

One of the dumbest reasons I've heard for depreciation. Imagine if Google and Microsoft took all of their products of the shelves because it's "much harder for new libraries accomplishing similar tasks to gain adoption" and because "there’s a transition happening now in the ecosystem to these patterns". Completely ridiculous.

But they have done it. And often. There are many, many products from these software giants that no longer exist or are currently deprecated and not getting any updates. Ever hear of, say, Windows 95 or FoxPro? Every software project will eventually come to and end for one reason or another. And the authors of Request aren't pulling it from the shelves either, they're stopping new development. Critical bugfixes will still happen for a while and if your project depends on it - no problems. You can still continue to use it.

But if you start a new project, there are better, more modern alternatives out there. The language has evolved, there are better ways to do the same things now, but Request cannot keep up with it because it needs the legacy projects to work with it. For new projects it is suboptimal.

So this decision makes total sense to me. Leave Request where it is so that legacy projects can still continue to use it, but for new projects recommend new libraries.

Is there any specific reason why anyone would use request over axios?

Is there any specific reason why anyone would use request over axios?

Sure. Off the top of my head:

• You're just used to it or have a lot of experience with it
• Your project already uses it all over the place. Switching it all would take weeks if not months of code rewriting.
• Company/project coding guidelines demands this library (or only allows libraries with certain "maturity" requirements)
• A 3rd party library requires it (and maybe even requires that you use it when you work with the library). Extra points if the library does not have any alternatives.
• You're a student and the course you're taking explicitly teaches about request and has it in exams/homework

In essence these are all variations of the same theme - you need to work with some legacy stuff that hasn't yet caught up with the latest trends. This tends to happen pretty regularly in real life.

npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated @hapi/[email protected]: joi is leaving the @hapi organization and moving back to 'joi' (https://github.com/sideway/joi/issues/2411)
npm WARN deprecated @hapi/[email protected]: This version has been deprecated and is no longer supported or maintained
npm WARN deprecated @hapi/[email protected]: This version has been deprecated and is no longer supported or maintained
npm WARN deprecated @hapi/[email protected]: This version has been deprecated and is no longer supported or maintained
npm WARN deprecated @hapi/[email protected]: This version has been deprecated and is no longer supported or maintained
npm WARN deprecated [email protected]: this library is no longer supported
npm WARN deprecated [email protected]: Please see https://github.com/lydell/urix#deprecated
npm WARN deprecated [email protected]: https://github.com/lydell/resolve-url#deprecated
npm WARN deprecated [email protected]: Chokidar 2 will break on node v14+. Upgrade to chokidar 3 with 15x less dependencies.
npm WARN deprecated [email protected]: fsevents 1 will break on node v14+ and could be using insecure binaries. Upgrade to fsevents 2.

WHYY???? ALL OF MY NPM GLOBAL INSTALLATION ALWAYS WARN ME THAT IT IS DEPRECATED?? HOW TO FIX THIS

I TRY TO UNINSTALL NODEJS
OR
UPDATING NPM
BUT IT DOESN'T WORK
PLEASE HELP ME

IT IS DEPRECATED.
YOU CANNOT FIX THIS.
IGNORE THE WARNING.

_{Or rewrite your code so that it doesn't use Request.}

@acatzk

Try

npm install -s (or --silent)
or

npm install -q (or --quiet)

to silence warnings

This thread is the best.

Hi. I am new to APIs. I was trying to install the request package and it said that it is now deprecated. I tried to look it up and see what is going on but I would appreciate it if someone can explain to me what I can do now? Does this mean that the request package is no longer usable? What other package can I use to do the same job?

@mohammed3736 No, it can still be used. But it won't be updated. It won't get new features. It might get a few bugfixes for a little while, but not for long. And the warning will always be there. Essentially they're abandoning the project. If you want any changes to it, you'll need to do it yourself. After all - all source code for request is still available. You can make your own fork and do whatever with it.

If you're writing a new project, better try another more modern library. For example, we use Axios, but I'm sure there are others.

I am going to ask the following question on my interviews now instead of Fizzbuzz:

You have faced the following message in your console.

What should you do about it and how do you fix it?

> npm WARN deprecated [email protected]: request has been deprecated, see #3142

@anton-bot That's easy, the answer is, "I click the link, don't read anything but go to the bottom of the thread and post the same question as everyone else."

Do I get the job?

@anton-bot That's easy, the answer is, "I click the link, don't read anything but go to the bottom of the thread and post the same question as everyone else."

Do I get the job?

The reason I was asking is because I keep getting 401s on my console log. And the request module is not working for me. I am trying to use the api from bitcoinaverage and from https://any-api.com/ and none of them were working. When I go into localhost3000 the html works and I get the page but when I press the button to get the result my console crashes. My console log either says app crashed or 401 for the statusCode and on the browser. Also note that none of my proxies are enabled I tried everything but I keep getting errors. IF you can help me I would appreciate it.

@mohammed3736 - This is the wrong place to ask. Also I'm 99.99% sure that it's not the request library that is to blame. There's a bug in your program and you made it yourself. You'll have to figure it out yourself too. If you still need help, try asking at StackOverflow, but please include the code that doesn't work. Best of all - try to make the smallest possible program that crashes and show that source code.

I also came here to ask a question but... what's up with all the racist attacks here? you people are unbelievable.

And yes I still have no idea why my code doesn't work. The only error in the console brings me here.

Check your privilege and have fun

I also came here to ask a question but... what's up with all the racist attacks here? you people are unbelievable.

And yes I still have no idea why my code doesn't work. The only error in the console brings me here.

Check your privilege and have fun

Which racist attacks are you referring to? That sounds really bad

Same issue observed. Please help if someone knows how to resolve

[email protected]: request has been deprecated, see https://github.com/request/request/issues/3142

@HaseebAhmed49 the "request" npm package being deprecated is not an issue per se. the message is to library project developers.

Don’t worry about it. A lot of people on github told me that it’s ok. It
just basically means that the package is not gonna have new features added
to it anymore and it won’t be updated but it is still perfectly fine to
use. I used it and it was fine.

On Mon, Sep 14, 2020 at 11:57 PM Elan Ruusamäe notifications@github.com
wrote:

>
>

@HaseebAhmed49 https://github.com/HaseebAhmed49 the "request" npm
package being deprecated is not an issue per se. the message is to library
project developers.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/request/request/issues/3142#issuecomment-692279572,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQFTBJ255VRYJW4VMUFQQ23SFZYSZANCNFSM4HCP6LRA
.

but it is still perfectly fine to use

Not really. It may work _for now_, but you should never have an explicit dependency on a package which will not be receiving further bug and security fixes. You are putting your app (and users) at significant risk of sudden breakage and security leaks when that package eventually _does_ stop working (which it almost certainly will). This is especially true for a package like request which provides something as crucial and sensitive as making network requests.

A deprecation warning is a serious notice to start migrating elsewhere. Several alternatives have already been mentioned (and repeated) in this thread.

Hi everyone I also did have this deprecated issues
so what I did is to uninstall nodejs and download the latest features of nodejs
which is 14.10.1 Current Latest Features
https://nodejs.org/en/

and delete all those global npm installed you have in the computer

and that's it...

all those deprecated are gone...

@acatzk wtf lmao

This library is deprecated. If there's a bug, nothing will be done to fix it. If there's a security issue, nothing will be done to fix this.

You should not use this. At all.

@davwheat thanks

what the alternatives of this request module?

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

Any updates of who is doing what at this point?

For those looking for a solid, Google-supported alternative (apart from the ones in https://github.com/request/request/issues/3143), I highly recommend https://github.com/googleapis/gaxios. Been using it in a recent project and it is excellent so far.

What are the alternatives? You npm page says For more information about why request is deprecated and possible alternatives refer to {the link to this page}

3143

npm WARN registry Using stale data from https://registry.npmjs.org/ due to a request error during revalidation.
npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142

@thbestforyourbizdeployment yes.

Thanks.

can you help me?

npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated [email protected]: this library is no longer supported
npm ERR! code EEXIST
npm ERR! syscall symlink
npm ERR! path ../lib/node_modules/firebase-tools/lib/bin/firebase.js
npm ERR! dest /usr/local/bin/firebase
npm ERR! errno -17
npm ERR! EEXIST: file already exists, symlink '../lib/node_modules/firebase-tools/lib/bin/firebase.js' -> '/usr/local/bin/firebase'
npm ERR! File exists: /usr/local/bin/firebase
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! /Users/bahar/.npm/_logs/2020-11-18T17_07_43_310Z-debug.log

@baharozcelik There's nothing to help you with.

Read. The. Issue.

sudo npm install --global gulp-cli
try like this