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.
"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).
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.
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.
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
That's a feature. https://medium.com/@b.essiambre/continuation-passing-style-p...
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.
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.
And there are more modern alternatives like axios that do have this promises interface.
// fetch with cookies:
const fetch = require('fetch-cookie/node-fetch')(require('node-fetch'));