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