
Request’s Past, Present and Future - HatchedLake721
https://github.com/request/request/issues/3142
======
garou
[https://github.com/request/request/issues/3142#issuecomment-...](https://github.com/request/request/issues/3142#issuecomment-479085436)

mikeal commented 6 days ago:

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

~~~
novaleaf
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. Probably due to low contributions (the code base is quite
complex). 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)

------
userbinator
_request will stop considering breaking changes._

Does the JS community seem to consider that a bad thing...? To me, this sounds
more like "is becoming stable" than "is being deprecated".

~~~
Klathmon
As the post explains, Javascript has changed significantly since request was
first created, and that left them with 3 real options:

1\. Try to make massive breaking changes to the request module to make it more
easy to work with in the current javascript landscape (promises, new streams,
async generators, etc...). This is a problem because then the millions of blog
posts, comments, stack overflow answers, and more are all now outdated and
wrong. And as the author explained, it would basically be a completely new
library.

2\. ignore it and become a thorn in the side of devs everywhere (oh, i can use
new streams and promises in 99% of my codebase, except for a few old modules
that we still use or have to code around until they get removed as they are
difficult to work with)

3\. Deprecate request, and make a new module under a new name which can adapt
to the current landscape.

So if you value non-breaking changes over developer experience and complexity
of integration, then it's a good thing for you. If you value tools which work
with the language as it exists now rather than against it, it's also a good
thing for you since the new "request by a different name" will work much
better in current javsascript.

This is the opposite of what Angular did. Angular 1 vs 2+ were basically
different libraries. Rather than take the angular route and just increment the
number and keep the name, they are trying something different. They are
throwing away the name and starting fresh.

~~~
HatchedLake721
I'll start from bottom options:

3) "deprecate request and start new" \- and discard 10 years of commits,
stability and tests? Wouldn't be a rational way to go.

2) "ignore it and become a thorn in the side of devs everywhere" \- it
wouldn't become a thorn more than it is now, would it? It's a 10 year old
package that's downloaded 14 million times a week. It doesn't feel a thorn
with those numbers. You can also `util.promisify` it if a callback is a
"thorn" for you as a developer. (but see
[https://news.ycombinator.com/item?id=19604867](https://news.ycombinator.com/item?id=19604867))

1) "there are a lot of google results with solutions that the new breaking
changes will make obsolete" \- that's what semver and major versions are for.
"We'll break Stack Overflow answers" doesn't feel like a valid reason. jQuery
has had its fair share of breaking changes in the last 12 years, and we know
the numbers if we compare `jQuery` vs `request` questions on Google/Stack
Overflow, so again, it doesn't feel like a valid reason.

~~~
Klathmon
As another commenter answered 3 and 2 (and I agree with them), i'll answer 1:

There's a difference between "has some breaking changes" and "will have
basically an entirely new API, and will support different features and make
different tradeoffs"

Like for instance AngularJs 1.x vs Angular 2+, or what seems like every major
version of react-router, or various other examples of this that come back
around and bite people. The only difference with those is that they don't have
literally 10 years of documentation, blogs, SO answers, and more with no
version numbers on them.

This isn't an instance where dogmatic application of the "rules" is a good
idea. This is one where choosing to make a new library under a new name is the
lesser of 2 evils. The hope is it will cause less problems, less confusion,
less difficulty for both new and old devs, and be better for everyone.

I don't know about you, but i've absolutely spent ~30 minutes on multiple
occasions trying to figure out why some documentation seems to be wrong, or a
feature isn't working in a library only to realize that i'm not on the latest
version or the docs don't have an easy way to go back through old versions,
and it's a big timewaste as well as a source of bugs. This move is trying to
prevent that!

~~~
Izkata
> There's a difference between "has some breaking changes" and "will have
> basically an entirely new API, and will support different features and make
> different tradeoffs"

Doesn't this library also predate the semver spec, and wasn't just such major
alterations the purpose of the major version number back then?

------
royjacobs
Hmm, so there are 41K packages depending on 'request' but from now on
everything that is merged into master is immediately going to be published?

Sounds like a recipe for disaster not unlike what happened with event-stream.

~~~
zamadatix
"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."

You won't be able to enter the "recipe for disaster" without at least seeing
the warning when you update your dependencies. At that point it's your
prerogative if you want to continue with a deprecated package.

------
VeejayRampay
I think a comment in this thread should be visible to highlight any
alternatives to request.

I've been mentions to got
([https://www.npmjs.com/package/got](https://www.npmjs.com/package/got)), if
anyone cares to point to other alternatives, that'd be nice, if only for
educational purposes.

~~~
skrebbel
fetch() has an excellent API. It's native in browsers and it has a good Node
implementation called node-fetch.

[https://developer.mozilla.org/en-
US/docs/Web/API/WindowOrWor...](https://developer.mozilla.org/en-
US/docs/Web/API/WindowOrWorkerGlobalScope/fetch)

~~~
ihuman
How come fetch hasn't been integrated directly into node, like how its
integrated directly into browsers?

~~~
snek
it uses a lot of infrastructure that node doesn't have, like Request objects
and Response objects and Body objects and mime checking etc etc list goes on.

if someone feels like adding all those things to node and feels like arguing
with our core maintainers about the duplication with http then maybe it will
be added.

[https://github.com/nodejs/node/issues/19393](https://github.com/nodejs/node/issues/19393)

------
spion
Node really doesn't pay attention to nice API design. If all readable streams
had

`Stream<T>.toBufferAsync(): Promise<Buffer>`

`Stream<T>.toStringAsync(): Promise<string>`

`Stream<T>.toArrayAsync():Promise<T[]>`

then you could quickly collect any stream you want into a promise, including
the stream returned by request.

Here is how you do a Stream API properly.

[https://api.dartlang.org/stable/2.2.0/dart-async/Stream-
clas...](https://api.dartlang.org/stable/2.2.0/dart-async/Stream-class.html)

Has first, last, toList(), map, reduce, filter, takeWhile, skipWhile,
Stream.periodic and other great goodies that make stream usage nice and easy.

Too bad Google never invested this amazing API designer power into JS, they
could've been the "apache commons" of node.

~~~
snek
We're getting there. I made both node and web streams into async iterables,
and have now proposed this for js standardisation:
[https://github.com/tc39/proposal-iterator-
helpers](https://github.com/tc39/proposal-iterator-helpers)

------
cphoover
I use this package... which mirrors the whatwg fetch API and has support for
promises baked in:

[https://www.npmjs.com/package/isomorphic-
fetch](https://www.npmjs.com/package/isomorphic-fetch)

------
namanyayg
What's the alternative to Request? I see Mikeal has made Bent [1], but I'm not
sure if the new, alien syntax is worth it? Also found got [2], thoughts?

[1] [https://github.com/mikeal/bent](https://github.com/mikeal/bent) [2]
[https://github.com/sindresorhus/got](https://github.com/sindresorhus/got)

~~~
Raed667
bent seems too "bare-bones" for my daily usage. If you like that good for you,
but I have been using axios[0] which is more heavy weight.

[https://github.com/axios/axios](https://github.com/axios/axios)

~~~
pier25
Problem with Axios is that it has almost 500 open issues and not enough
maintainers.

We've moved to fetch, which is not as handy, but is the standard lib in the
browser. Actually we use wretch which adds a more convenient API on top of
fetch.

[https://github.com/elbywan/wretch](https://github.com/elbywan/wretch)

For Node we use node-fetch which mimics the fetch API using the native HTTP
module in the background:

[https://github.com/bitinn/node-fetch](https://github.com/bitinn/node-fetch)

~~~
Raed667
I'm using axios in production for over 2 years now. Can you point me to a
certain issue you had I'd need to anticipate (or check if I already have)?

~~~
pier25
I've used it in production for 3-4 years with no issues (that I know of) but
it's a ticking time bomb.

[https://github.com/axios/axios/issues/1965](https://github.com/axios/axios/issues/1965)

[https://www.reddit.com/r/javascript/comments/an94xq/axios_ne...](https://www.reddit.com/r/javascript/comments/an94xq/axios_needs_maintainers/)

~~~
dimgl
How is it a ticking time bomb if all of the tests pass in that package?

------
UK-Al05
I don't know much about the javascript ecosystem, but isn't this what major
version updates are for?

~~~
rmrfrmrf
There's precedent for outright deprecating a package when others exist that do
a better job of meeting current development needs. With Promises and
node/browser cross compatibility being the biggest ecosystem shifts, there are
a few newer choices that already meet those needs. Also, `request` in
particular would be gross to upgrade since so many people rely on additional
dependencies that add compatibility for things like Promises, retry
strategies, etc., all with varying degrees of active maintenance.

------
CSMastermind
As someone who's tried to switch off of `request` recently, I'm worried about
this. I didn't find any of the alternatives to be particularly viable.

------
andybak
Gosh. I was rather hoping the days of Javascript churn were over but reading
this reminds me of why I lost interest in front-end web development.

~~~
dimgl
`request` is mostly used on the server-side...

------
dap
Is the implication that every library module with async code must be rewritten
to use promises or else be obsolete?

~~~
snek
it's not just promises. as the maintainers of request continue trying to try
to fix architectural bugs they are finding it would be easier to rewrite it
from scratch rather than continue modifying the current one. this is said in
about as many words in the linked issue too, so make sure you read before
commenting ;)

~~~
HatchedLake721
"easier to rewrite from scratch" is a fallacy.
[https://www.joelonsoftware.com/2000/04/06/things-you-
should-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-
do-part-i/)

~~~
matt_kantor
"Easier to fix if they allow themselves to completely break the public API"
was how I interpreted the situation with request.

~~~
HatchedLake721
That's what MAJOR stands for in semver - when you make incompatible/breaking
API changes

------
revskill
What's the reason for being in maintainance mode then ? I don't see it in the
post though.

~~~
staticvoidmaine
I because think maintenance mode is a responsible alternative to abandoning
the package altogether as it has (from the post) ~41k packages that depend on
it.

------
menzoic
Clickbait title on HN? He said it's one of the first, not the very first one.
Also just say "request". Anyone interested in an old npm package being
deprecated will probably know this module. "request is being deprecated on
NPM" is eye catching enough.

~~~
scrollaway
On top of this it's not being deprecated, although it seems they considered
that option. It's just going into maintenance mode, which makes sense for a
library which is essentially done (and why wouldn't it be, if it's been around
for 10 years?).

~~~
bryanrasmussen
[https://news.ycombinator.com/item?id=19604560](https://news.ycombinator.com/item?id=19604560)
explains why it is not really going in to maintenance mode though.

