request has gone into maintenance mode. Maybe replace it.

[Tchiller]

Dear team,

thanks for your work!

I would like to report that the package request which you are loading has went into maintenance mode request/request#3142

Therefore, yarn is currently giving me:

warning node-gyp > request@2.88.2: request has been deprecated, see request/request#3142

Maybe you find time (and a good replacement) to replace it.
Thanks!

[rvagg]

Yeah, thanks @Tchiller, it got deprecated last week after a long warning period (mind you, I didn't pick up on the fact that it would be properly deprecated in npm so this was a bit of a surprise).

We don't have a plan to deal with this, maybe we'll follow what npm does (or is doing, I don't know status). This will take someone doing the work and making sure it's maximally compatible back to Node 10.x at least (yes 10 is going away soon but node-gyp can't be as aggessive as a lot of software since it's a piece of core infra).

[rvagg]

Yeah, maybe not, npm uses its own library that's a wrapper around a fork of node-fetch, not an ideal tangle to get involved in https://github.com/npm/make-fetch-happen

We could consider bent but we have yet to embrace async/await in node-gyp. We're either going to have to do an awkward piece-wise migration or go whole-hog at some point.

Too hard to think about right now! Proposals are welcome!

[imatlopez]

@rvagg are you saying that for node-gyp v7.x Node 6-9 are getting dropped? You could cage any calls to request in v6.x, then swap the underlying api for v7.x

[rvagg]

What version of Node we support is partly informed by npm. I don't have much insight into their current strategy but recent years suggest that they're being more aggressive with dropping older versions of Node from support as those versions get dropped upstream.

I don't think there's any reason to consider supporting Node 6, it's roughly 1 year out of support.
Node 8 was dropped at the beginning of this year. There's an argument to be made that we should consider continuing to make node-gyp compatible with Node 8. I wouldn't want npm to decide to ship an older node-gyp because they wanted to be more compatible than us. But, at this point, the kinds of features we want to start adopting are in Node 8 anyway - async/await being the main one, so it probably wouldn't be hard.

After my last post here I thought of a possible interim solution, switching to hyperquest. I still use it in many of my Node libraries and it still works great. It's much simpler than request but has a very similar API so doesn't suffer from many of the costs that request had with its bloated feature set and dependency tree. The challenge we'll have is that some of those missing features are required by our users, such as proper proxy detection. But we've already adopted a big chunk of request's proxy code here to do some custom work with it so that should be fairly simple to insert to hyperquest to bring parity. We're going to have this feature problem with whatever we switch to I think; there'll be some weird edges where request has certain behaviour that our users are relying on that we will no longer support when we switch http clients.

[imatlopez]

hyperquest seems dated, though that means support for older Node versions would be a given.

The challenge we'll have is that some of those missing features are required by our users, such as proper proxy detection.

What are the features that are needed? I can think of 2 (mostly due to my ignorance) streams and proxies

[rvagg]

hyperquest seems dated, though that means support for older Node versions would be a given.

I'm thinking more about the amount of change required on our end to adopt something new. We're still working on a thoroughily old-style Node codebase. Modernising is an option but a costly one that I don't see happening in the short term. Hence, hyperquest might be a good short-term fix, in many cases it's a drop-in replacement for request.

[imatlopez]

Is it for visuals? I'd think request was updated last sometime since hyperquest has

[rvagg]

hyperquest is still "supported", it has many users who rely on it. It's not recently updated because it just works and is simple enough that it doesn't need constant curation. substack would consider it "finished" although he's handed over maintenance to others (Julian Gruber among others I believe). request is a beast of a codebase with a lot of dependencies, hyperquest is much more focused.

also, npm install node-gyp won't give a deprecation notice if we switch to hyperquest! that's the top-level concern here, there's no real problems with request (yet), but the deprecation notice is going to get severely annoying and I expect this issue to get busier as people encounter it more and more.

[imatlopez]

request is a beast of a codebase with a lot of dependencies, hyperquest is much more focused.

agreed :)

I think your logic is sound, so what has to be feature matched on top of hyperquest?

[rvagg]

The main one I can think of is proxy detection, but we've done the heavy lifting now (recent addition) in proxy.js, which is mostly copied out of request, so we should be able to leverage that for free! I can't think of anything else off the top of my head, I'm just a little afraid that there are some because of the wide variety of ways people are using node-gyp (behind weird firewalls, proxies, redirecting to alternate source locations - like for electron...).

[SampsonCrowley]

would it work to pin request to the version before it was deprecated?

[targos]

The package is entirely deprecated. npm prints a warning for any version.