
Request Node lib used by 48k modules is now deprecated - lootsauce
https://github.com/request/request/issues/3143
======
floatingatoll
Previously on HN (72 comments):
[https://news.ycombinator.com/item?id=19604148](https://news.ycombinator.com/item?id=19604148)

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

Sounds to me like the library is "done".

~~~
neurobashing
Hardly a hot take but a lot of people seem to think that if code isn't
actively being worked it, you can't use it, as if there can never be a point
where fewer and fewer bugs are reported and fewer and fewer features are
requested.

when's the last time Knuth wrote a check for TAOCP? Is it "dead"?

~~~
svat
> when's the last time Knuth wrote a check for TAOCP?

Got one in the mail yesterday (check was written Feb 10). In fact you can
figure out how many checks were written in the last month, roughly: compare
[https://web.archive.org/web/20200110074014/https://cs.stanfo...](https://web.archive.org/web/20200110074014/https://cs.stanford.edu/~knuth/boss.html)
with
[https://web.archive.org/web/20200219035903/https://cs.stanfo...](https://web.archive.org/web/20200219035903/https://cs.stanford.edu/~knuth/boss.html)
I imagine most of these checks (definitely all $7 of mine) were from finding
bugs in pre-fascicles, i.e. bleeding-edge drafts he's been putting up online.
(See near the bottom of
[https://cs.stanford.edu/~knuth/news.html](https://cs.stanford.edu/~knuth/news.html))

On the other hand, while you mention Knuth and "done", TeX and METAFONT are
better examples. He declared them "done" in 1990
([https://tug.org/TUGboat/Articles/tb11-4/tb30knut.pdf](https://tug.org/TUGboat/Articles/tb11-4/tb30knut.pdf)),
but still does bug fixes:

> _I still take full responsibility for the master sources of TeX, METAFONT,
> and Computer Modern. Therefore I periodically take a few days off from my
> current projects and look at all of the accumulated bug reports. This
> happened most recently in 1992, 1993, 1995, 1998, 2002, 2007, and 2013;
> following this pattern, I intend to check on purported bugs again in the
> years 2020, 2028, 2037, etc. The intervals between such maintenance periods
> are increasing, because the systems have been converging to an error-free
> state._

(The latest round, in 2013, did surface one bug: the debug string
representation of an "empty" control sequence was missing a space.)

~~~
gaxun
Nice to see multiple of us are on here.

> I imagine most of these checks (definitely all $7 of mine)

The 0x$2.00 check I got from 10 Feb 2020 was for one typographical item in
Volume 4A and one pedagogical improvement in Volume 1, Fascicle 1. So it is
certainly possible to still get checks for material that is already published.

Since it is now 2020, anyone with bug reports from the typography stuff should
send them in soon, wouldn't want to miss the deadline.

~~~
svat
That's interesting, can you go into more detail on those two -- what was the
pedagogical improvement, and the typographical item? Just curious...

~~~
gaxun
Sure.

\- On page 715 of Volume 4A, he had something like \\`a when he meant to have
just à.

\- In Volume 1, Fascicle 1, there is a convention that the "main" entry point
of an MMIX program begins at LOC #100. The convention is established early on
and repeated throughout the text. However, at no point is it explained _why_
LOC #100 was chosen (instead of LOC #0, LOC #80, or whatever). It could be
gleaned through careful study -- LOC #0-#80 are reserved for trip/trap
handling and one more location before #100 is reserved for a special second
entry point -- but you basically had to read the entire fascicle to find /all/
of these. A naive user would be likely to try writing a program beginning at
LOC #0 and wonder why it didn't seem to behave correctly. My suggestion was to
just add a note explaining why LOC #100 was used. He agreed and you can find
the added note in the latest errata for Volume 1, Fascicle 1.

~~~
svat
Oh thank you. I looked up page 715 of my copy of Volume 4A and can see the
\\`a. :-) I also see both corrections you mentioned in the online errata,
that's cool. :-)

------
tal_berzniz
Deprecating is a weird decision as there is nothing wrong with the "request"
module. It doesn't lead to bad code, bugs or security risks.

It would be better to say this is the last version, except for security
upgrades. These upgrades can be done by other maintainers that are assigned to
the project.

~~~
coolreader18
There doesn't have to be something wrong with a solution to deprecate it,
there just has to be a better alternative.

~~~
tal_berzniz
If the alternatives are better, then devs will choose those solutions and
"request" will fade over time. It doesn't have Promise support, so new
projects will likely not choose it.

request is very simple and straightforward library that solves a very common
issue.

Deprecating it causes a lot of work for every project out there. Either using
request directly or indirectly.

I have a lot of respect for the maintainer, and he can choose to do whatever
he wants with this module. That's his privilege.

However, the fact that he got "bored" with this solution, doesn't mean he
needs to deprecate it. He can just stop working on it, and give ownership to
someone else.

If it had a security issue and he is not going to ever update it, then that
would deserve the deprecation so people should be warned.

~~~
BenoitEssiambre
>It doesn't have Promise support

That's a feature. [https://medium.com/@b.essiambre/continuation-passing-
style-p...](https://medium.com/@b.essiambre/continuation-passing-style-
patterns-for-
javascript-5528449d3070?source=friends_link&sk=976fb25ca6c15eba3a4badcf55ba698e)

~~~
hombre_fatal
While this isn't really the place to discuss this, that your most complex
example is a simple waterfall of three nested async functions doesn't do much
to sell the superiority. Start mixing in conditional async calls with
downstream async branching. And look at the Promise-based solutions to
async.js
([https://caolan.github.io/async/v3/](https://caolan.github.io/async/v3/)), a
library nobody misses. Still not sure if your blog post is a joke or not
though, frankly. If it's a serious post, then it seems troll-y to inject such
a fringe opinion any time someone casually mentions promises being good.

------
wnevets
When did maintenance mode become deprecated? Why isnt that hyperbole?

~~~
hombre_fatal
They have marked the package as deprecated on NPM.
[https://docs.npmjs.com/cli/deprecate](https://docs.npmjs.com/cli/deprecate)

See the banner on this page:
[https://www.npmjs.com/package/request](https://www.npmjs.com/package/request)

They are urging people to consider the enumerated alternatives.

~~~
tantalor
> No new changes are expected land. In fact, none have landed for some time.

That's not what "deprecated" means. That's "maintenance mode".

Deprecated means no new clients should use it, and existing clients should
migrate to library X or Y, because it's going to be deleted by 202X.

~~~
hombre_fatal
They don't want to maintain this software forever and are definitely urging
people to use other software. They even admit that they will merge fix PRs
with a disclaimer of "no promises".

I mean, the developer themself has said it's deprecated and has marked it as
such formally on NPM with a link to a post that urges people to use
alternatives, so I'm unsure of what you're arguing nor what it achieves. Seems
to satisfy your own definition, they just don't have an exact date on when
their maintenance charity will run out.

------
cloverich
For people looking for an alternative, got [1] is well written, maintained,
and as a bonus has a nice comparison chart to other libs. I started w/ node-
fetch but quickly moved to this. Its author is also prolific in the Node
community.

[1]:
[https://github.com/sindresorhus/got#comparison](https://github.com/sindresorhus/got#comparison)

------
winrid
What, why?

Edit:
[https://github.com/request/request/issues/3142](https://github.com/request/request/issues/3142)

~~~
petercooper
Specifically:

 _The first version of request was one of the first modules ever created for
the Node.js ecosystem. [..] The patterns at the core of request are out of
date. [..] A version of request written to truly embrace these new language
patterns is, effectively, a new module._

~~~
Klathmon
And IMO that's a really good way of solving this issue!

Rather than try to push a paradigm shift under a major version change in a
library, and rather than just hand the library over to someone who may or may
not be vetted enough, they are gracefully shutting it down while still
sticking around to fix any security issues that may crop up.

~~~
chadlavi
This is what semantic versioning is for, though. Breaking changes to the API
that still serve the same function in an app would not unreasonably be a new
major version of the same package. No one is obligated to upgrade to the
latest major version.

A complete rewrite would be a ship of theseus situation. It's all new code,
and the API may be different, but it still exists to serve the same purpose in
an app. Why pretend it's a new module when it's really just a retooled version
of the same one?

EDIT: Ok, I misunderstood what was going on with the request maintainers;
thought they were planning to start up a new package as a rewrite of request.
That practice specifically is what I was arguing against here -- it's not good
practice to start a new node module with a new name just because you have
breaking changes to your API. I do not in any way mean to suggest that someone
else should jump in and turn request into something new.

~~~
Klathmon
The author of that issue linked above says it better than I ever could:

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

Now view that in contrast to react-router, which has gone through 3 or 4
really major rewrites, and had their API change those few times in completely
incompatible ways, even shifting paradigms multiple times over the course of
the library until now.

They are still committed to maintaining most of the past major branches, and
the docs are still around for those versions, but each one is so different
that it adds a lot of confusion. And I don't meant to say that react-router is
bad, the reasons for the changes are damn good ones, and I actually like the
library a lot, but the confusion around it is real because the 2.x branch vs
the 3.x branch vs the current branch are all so different that they should
really be different libraries in my opinion.

If I had to choose between those 2 things, i'd choose what request is doing
both as a library author and a library user.

~~~
chadlavi
I misunderstood -- I thought the authors of request were going to keep working
on a rewritten version, but were going to start a brand new node module for
it.

Strictly speaking, react-router is doing it correctly. It's the same library,
just different versions. The normative way in the npm community to handle
breaking API changes is to increase the major version, not to completely
rename the package.

------
lootsauce
I am now looking for another library that is as expressive with http
streaming. I have enjoyed using request for complex things things like piping
file downloads while rewriting headers, adding cookies, without buffering the
entire response in memory.

~~~
mofle
“got” has support for streaming. We have a migration guide for “request”
users:
[https://github.com/sindresorhus/got/blob/master/documentatio...](https://github.com/sindresorhus/got/blob/master/documentation/migration-
guides.md)

------
tcd
I have a question:

Is it the responsibility of the package manager to keep users safe? By that, I
mean, if there was a security vulnerability that the maintainers refused to
fix, what would the process be?

Should NPM refuse to install packages marked as deprecated, perhaps after a
certain age of deprecation (say, 6 months)?

Comparing this to the browser where I believe it _is_ the expectation Firefox,
Chrome, Safari et al to keep users safe, by updating automatically if an issue
is discovered.

~~~
hombre_fatal
I don't see why NPM should be so heavy-handed as to prevent installation of
deprecated software. It already shows you a warning.

I think it's a good example of when systems over-act on information they do
know (a developer has marked their software as deprecated) in ridiculous
contrast to all the information they don't know (99% of developers not even
bothering to deprecate their package when they abandon it).

------
ruffrey
Can anyone recommend a library with the same API as request?

For those of us that would be under hardship to rewrite the node-request
portions of large stable services, but also can't/shouldn't to have deprecated
libraries?

~~~
Klathmon
This is going to sound glib, but you can just keep using what you have now.

If you take a look at [1], the maintainers of request aren't "deprecating" it
in the sense that they won't touch it ever again. It really just means that
there won't be any more active development on it, no new features or breaking
changes will be accepted, and some housekeeping had to be done to allow it to
accept security fixes without relying on one specific person to be around.

The code will still work (and probably for quite a while), and security issues
will still be addressed, it just won't be changing much if at all from now on.

[1]
[https://github.com/request/request/issues/3142](https://github.com/request/request/issues/3142)

~~~
lootsauce
I totally agree with this approach, however it seems like a good idea to use
alternatives for future work.

~~~
Klathmon
Agreed, but if you are looking for alternatives with an identical API, then it
doesn't seem like a good idea anymore (at least to me).

The main theme behind the depreciation of Request is that the API is old and
doesn't really fit with the rest of the node ecosystem. Any other API-
compatible library is going to have those same issues. So if you are going to
start something new, but want to keep an identical interface, then you might
as well just use Request.

------
manojlds
48k? Isn't github showing 4.4m?

Everyone I see seems to use axios these days.

~~~
pier25
> _Everyone I see seems to use axios these days_

Axios was somewhat abandoned a year or so ago.

A new collaborator was added in Dec 2019 which apparently is picking it up.

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

Who knows for how long though...

~~~
rffn
What would be the alternative to Axios?

~~~
pier25
On the browser I generally use fetch(). It's a bit weird at first but it's
easy to write a thin wrapper if the default behavior doesn't make sense. Eg:
throwing when you receive a 400 or 500.

On Node I've been using this lately: [https://github.com/node-fetch/node-
fetch](https://github.com/node-fetch/node-fetch)

------
LukaszWiktor
axios FTW!

------
Tomte
Real title: "Alternative libraries to request". The "deprecating" part is
simply the submitter's invention, in order to stir up drama.

~~~
masklinn
The maintainer put it in "maintenance-only" a year back, and officially
deprecated it a week ago:
[https://github.com/request/request/pull/3267](https://github.com/request/request/pull/3267)

~~~
Tomte
Okay, so not totally invented, but still not the original title (which is
perfectly descriptive), but clickbait.

------
shaggie76
I checked and one of our servers is using this; the real challenge will be
seeing if my old dev environment still works because we haven't updated this
service in years.

------
nem_pet
This little maneuver is gonna cost us 51 years.

~~~
nem_pet
I don’t see a point to give negative if you don’t get it.

~~~
jkahrs595
We get it, it just adds nothing to the conversation.

~~~
nem_pet
Was hoping to make someone laugh...

~~~
hombre_fatal
I think we all have "NPM/JS bad" fatigue.

------
EGreg
Ok, I have been known to have strong opinions on HN, and each one is open to
being changed and is rooted in extensive personal experience.

I have said that comments are a code smell.

I have written extensively in favor of decentralization and even formed two
companies to promote it in increasingly sophisticated ways (qbix.com and
intercoin.org)

So I’m gonna say something that may get me downvoted...

Package Managers are almost as bad as closed source software, which is almost
as bad as closed software in “the cloud” (the fake, centralized one) which you
don’t host.

Society today still has to rely on feudal lords for many things, just as we
used to rely on the post office, printing presses and telephone switchboard
operators.

If you _are_ going to use a package manager, you should be _at the very least_
pinning all your versions and personally vetting any changes that are pulled
from upstream. You can outsource this security check to some third parties (at
least GitHub has those alerts when vulnerabilities are found) but we need the
security audit people in the loop, signing releases. Not just pull from
upstream, MUCH LESS pulling thousands of new commits across hundreds of
packages!

We have seen this introduce security bugs all over the place, in the past.
Deprecation is not as bad as that, but you gotta vet what goes into your code.

One of many examples, how can we address this?

[https://www.theregister.co.uk/AMP/2016/03/23/npm_left_pad_ch...](https://www.theregister.co.uk/AMP/2016/03/23/npm_left_pad_chaos/)

I speak a bit flippantly but when you’re building a PLATFORM or FRAMEWORK for
apps, this matters. A lot. Linus’ rant about diffs and patches being far
better than svn are a version of what I’m talking about. At least svn is
inside an organization. This is out on the internet!

The bazaar may be better than the cathedral, but not for security and the more
power your framework have the more responsibility you have to not skip
security checks and just pull code. It’s worse than executing a shell script
downloaded from the ‘net, because you’re essentially shipping this shell
script downstream to everyone who uses your code!!

~~~
hombre_fatal
Sure, taking on dependencies introduces pros and cons. But isn't this just the
classic HN trope where you fly off the handle on a loosely related rant just
because TFA has some sort of triggering buzzword like "NPM"?

Not sure how your rant is related. In fact, that such a popular library is
being deprecated contains in itself the realization for unknowing developers a
downside of depending on large libraries.

Someone upset by this deprecation that wasn't yet aware might, in the future,
seek out a more timeless solution for making http calls like the Node
implementation of the browser's native window.fetch(). All without having to
read a rant.

~~~
UnFleshedOne
The rant might be off topic, but everything he says is reasonable. In a "this
is why we can't have nice things" way.

------
craftoman
It was about time. I did some benchmarks few years ago and the results were
disgusting compared to native lib, plus why so many dependencies for a simple
request library? I will never understand why it gained so much publicly, it
was worthless since the day one.

~~~
have_faith
Seems like a disrespectful way of describing someone else's work, regardless
of shortcomings.

~~~
craftoman
You know how many packages out there are better than request? Now compare all
the work those great developers did, gave their souls for what? 50 stars at
GitHub? Cmon, let's face the real problem here which is the balance between
good code versus popular code. I'm speaking behalf of every great developer
out there that spends hundreds of time and his project got faded
inconspicuously. I have seen hardcore projects that every tech company could
have envied get like 50 dollars of donations and projects that were made in
one day, get thousands.

~~~
UnFleshedOne
That's just Power Law. Like it or not, I don't think there is a workaround.

~~~
craftoman
Like judging a book by it's cover or the number of sales. No one said
programmers are geniuses, they're just masters of some tools that forge the
digital era, nothing more nothing less.

