Transition away from request

[travi]

Since it is deprecated

May be worth keeping an eye on fetch being exposed in node and consider going that route.

[basti1302]

I think it might be a bit early for this discussion. How I understand it, request is not being deprecated. It goes into maintenance mode. I might be splitting hairs here, but I think the important points are:

• request will not add new features/breaking changes - fine, so what? It is pretty feature complete anyway.
• request is still being maintained, that is, they will still merge bug fixes, see Request’s Past, Present and Future request/request#3142 (comment)

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

But it seems that it is already decided that even maintenance will stop at some point, so we might as well start thinking about alternatives, so thanks for bringing it up.

Whether native fetch happens in Node.js core is still very much up to debate, as the discussion you linked to shows. Even if it landed, it would probably land in Node.js 13/14 earliest and not be backported to older versions. I think Traversion should support LTS Node.js versions that are not EOL, so even if native fetch lands, it will be a long time until a lib like Traverson could rely on.

So, let's discuss alternatives. I don't think native fetch is the right way to go for Traverson, as pointed out above. This list has some interesting alternatives:

request/request#3143

These options seem particular interesting in my opinion:

1. The (non-native) node-fetch module: We could use this for Node, remove the superagent-based request shim for the browser case and rely on the browser's native fetch instead. That would mean that a future Traverson version drops support for IE and Opera mini, though: https://caniuse.com/#feat=fetch
2. make-fetch-happen: Similar to option (1) but apparently brings some extra features to the table. I must admit "HTTP Cache Support" makes me drooling a bit - that's something I would love to see in Traverson for Node.js but always refrained from implementing it in Traverson itself, because it should be a feature of the underlying HTTP lib.
3. superagent: We already use superagent for the browser case anyway, we might as well use it in Node.js as well - it would remove the necessity to map requests API to the superagent API, which we currently do (in a somewhat ad-hoc, incomplete way).

Side note: Any of this would of course be breaking changes because we would need to remove all configuration API that leaked the fact that we use request underneath (withRequestOptions, addRequestOptions, getRequestOptions, withRequestLibrary , getRequestLibrary).

[travi]

so we might as well start thinking about alternatives, so thanks for bringing it up

yep, this was my primary goal, just to get us thinking about it. i dont think there is any urgency at this point to make any switch soon.

Side note: Any of this would of course be breaking changes because we would need to remove all configuration API that leaked the fact that we use request underneath (withRequestOptions, addRequestOptions, getRequestOptions, withRequestLibrary , getRequestLibrary).

this is a big part of why i think its worth us starting to give a change some thought. outside of dropping support for older node versions as they go out of the LTS support window, this will be an actually disruptive breaking change that would be good to do in a clean way.

Whether native fetch happens in Node.js core is still very much up to debate, as the discussion you linked to shows.

yeah, not suggesting at all at this point that native fetch is necessarily the right answer, but worth keeping our eye on if we end up getting closer to thinking about making a switch. i do think there could be some advantages to something like this being native, but we'll see where it goes.

Even if it landed, it would probably land in Node.js 13/14 earliest and not be backported to older versions. I think Traversion should support LTS Node.js versions that are not EOL, so even if native fetch lands, it will be a long time until a lib like Traverson could rely on.

i agree with continuing to support LTS versions, but i think its worth considering (depending on how things play out) if the LTS support needs to be in the latest release of traverson. i could see an approach that makes a major release that switches to something supported on the latest versions, but continue to maintain the version using request for the LTS support with only security/bug fixes applied, as an option.

So, let's discuss alternatives.

i'm definitely open to options and i think the ones you suggest are good ones to start the conversation with. i think it would be good to introduce some level of official support for promises if we put the effort in to go down a new path, but don't have strong thoughts beyond that at this point.

That would mean that a future Traverson version drops support for IE and Opera mini, though:

i'm definitely supportive of steps that let us settle on a more common api between the browser and node, at least from a maintenance perspective. it seems that things are trending more and more in a fetch direction, so something aligned with that trend seems best to me. you probably have a much better handle on browser support needs than i do since i only use traverson on the node side. IE use seems to be trailing off anyway, but its become fairly common to use a fetch shim in that context these days, so recommending that route might be enough.

if we consider it too early to take a serious look, maybe its best to just keep our eye out for trends in the community and how things like native fetch progress. mainly just wanted to give us a place to capture thoughts as they come up and get us thinking about things at least.

[travi]

with request being officially deprecated now, we should probably discuss a path forward a bit more. i'm hoping to finally get new releases out in the coming weeks so that publishing new versions becomes easier. might be worth a migration away from request being a next focus.

in addition to the options listed above, i've been using got a fair amount with success. it even has a migration guide from request. i figure its at least worth keeping in the mix.