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

[Jare]

"Deprecated" to me means the author says you shouldn't use it, or with more nuance, that "you shouldn't start using it now, and you should switch out of it ASAP if you already are a user, because it will very possibly stop working within the lifetime of you own project".

"A better alternative" is not enough of a reason to not use another alternative, because "better" is not an absolute value and choices tend to have many axis to balance (for example, prior experience).

[marcosdumay]

Well, looks like your only difference is on that ASAP part.

Deprecated functions within a module will surely stop working in the near future, but deprecated modules probably won't. It's not great that we see the same warning for both, and we should not treat both the same.

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

[DougBTX]

> However, the fact that he got "bored" with this solution

That's a horrible mischaracterisation. There's a clear ecosystem-wide shift to async/await instead of nested callbacks, putting a project that depends heavily on callbacks into maintenance mode rather than releasing a new, entirely incompatible version that uses async/await is completely reasonable.

Also worth pointing out is that the same person who posted the maintenance mode announcement also released a request library that does use async/await: https://github.com/mikeal/bent

[BenoitEssiambre]

>It doesn't have Promise support

That's a feature. https://medium.com/@b.essiambre/continuation-passing-style-p...

[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/), 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.

[mekster]

What's wrong with, https://github.com/request/request-promise-native

[Ididntdothis]

Why is an alternative needed? To me it sounds like the library is “done” and has all the features it needs. I wish more code was in that stable state.

[hombre_fatal]

fwiw they actually did mark their package as deprecated on NPM which means that all installations will see a warning that urges the user to consider other software.

It's kind of like if you were to maintain your own promise implementation, then the Promise is added to stdlib. You wouldn't say that your project is "done", you'd want to encourage your users to use the native promise.

Request was created back when all we had was the stdlib `http` module.

[seniorsassycat]

> Request was created back when all we had was the stdlib `http` module.

What stdlib module supersedes `http`? Browsers have `fetch` and there's `node-fetch` and `axios` modules, but it's sad that core node hasn't updated the core http module.

[sli]

Node has an http2 module as well, but it's still pretty low level. I don't think there's anything wrong with the stdlib module being lower level than the third-party ones.

[Ididntdothis]

Makes sense.

[JMTQp8lwXL]

The maintainers claim that the community would be better off without the package. Someone has to stick around to do security fixes for it, and that's time that could be spent making more innovative contributions to the Node.js package ecosystem.

[tal_berzniz]

Wouldn't it make more sense to ask the community what they want to do? Without taking time from the original maintainers

[outside1234]

It is slightly archaic in that it mostly uses a callback convention, when most of the node community has moved on to promises.

And there are more modern alternatives like axios that do have this promises interface.

[11235813213455]

node-fetch above all, it's standard, and works in the browser https://github.com/node-fetch/node-fetch/blob/master/package...

[rezonant]

This, I use it for all Node.js backend requests. Personally I think we need to move to isomorphic solutions and work to unify backend and frontend JS development as much as we can. This one's a no-brainer

[mekster]

I don't get why it doesn't support cookies but says to parse Set-Cookie header manually and implement it yourself.

[11235813213455]

there's https://www.npmjs.com/package/fetch-cookie for node

  // fetch with cookies:
  const fetch = require('fetch-cookie/node-fetch')(require('node-fetch'));