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"?
TL;DR: at over a decade old it's a primordial Node lib which has become increasingly difficult to evolve as the platform introduces new features, so rather than break every user with a massively disruptive new version that embraces modern features it's going to attempt to quietly sunset to free up the oxygen in the room so that new libs can grow.
I'd agree if it wasn't for it having to remain compatible with future node releases. If it was (and I don't know if it is) part of the node.js testsuite then it seems like the ideal way to end active development on a library.
The annoying thing is, since it is marked as deprecated, everyone installing a package that relies on it will get a deprecation notice. I already had some users opening issues on some of my projects for this.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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!!
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.
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.
As a user of Request for the past couple of years, it has made my life absolutely simple. I never had to worry about making HTTP requests and catching all those errors because it did this and a lot lot more.
I've worked on several projects and not all of them ever sat down and wondered the benchmarks at a very high scale and the number of dependencies it needed.
It's not a criteria for all the projects in the world.
I have utmost respect for the maintainers and contributors of Request and so should you.
[+] [-] floatingatoll|6 years ago|reply
[+] [-] dpedu|6 years ago|reply
> 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|6 years ago|reply
when's the last time Knuth wrote a check for TAOCP? Is it "dead"?
[+] [-] djsumdog|6 years ago|reply
[+] [-] hoorayimhelping|6 years ago|reply
It seems like you meant it more in the sense of this library is "complete." Just in case anyone was confused.
[+] [-] nikanj|6 years ago|reply
[+] [-] kibwen|6 years ago|reply
TL;DR: at over a decade old it's a primordial Node lib which has become increasingly difficult to evolve as the platform introduces new features, so rather than break every user with a massively disruptive new version that embraces modern features it's going to attempt to quietly sunset to free up the oxygen in the room so that new libs can grow.
[+] [-] SahAssar|6 years ago|reply
[+] [-] kabes|6 years ago|reply
[+] [-] tal_berzniz|6 years ago|reply
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|6 years ago|reply
[+] [-] JMTQp8lwXL|6 years ago|reply
[+] [-] outside1234|6 years ago|reply
And there are more modern alternatives like axios that do have this promises interface.
[+] [-] wnevets|6 years ago|reply
[+] [-] cloverich|6 years ago|reply
[1]: https://github.com/sindresorhus/got#comparison
[+] [-] winrid|6 years ago|reply
Edit: https://github.com/request/request/issues/3142
[+] [-] petercooper|6 years ago|reply
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.
[+] [-] lootsauce|6 years ago|reply
[+] [-] tcd|6 years ago|reply
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.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] ruffrey|6 years ago|reply
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|6 years ago|reply
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
[+] [-] lootsauce|6 years ago|reply
[+] [-] manojlds|6 years ago|reply
Everyone I see seems to use axios these days.
[+] [-] pier25|6 years ago|reply
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
Who knows for how long though...
[+] [-] Narretz|6 years ago|reply
[+] [-] LukaszWiktor|6 years ago|reply
[+] [-] Tomte|6 years ago|reply
[+] [-] masklinn|6 years ago|reply
[+] [-] lootsauce|6 years ago|reply
[+] [-] shaggie76|6 years ago|reply
[+] [-] nem_pet|6 years ago|reply
[+] [-] EGreg|6 years ago|reply
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...
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|6 years ago|reply
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.
[+] [-] craftoman|6 years ago|reply
[+] [-] kaushikt|6 years ago|reply
As a user of Request for the past couple of years, it has made my life absolutely simple. I never had to worry about making HTTP requests and catching all those errors because it did this and a lot lot more.
I've worked on several projects and not all of them ever sat down and wondered the benchmarks at a very high scale and the number of dependencies it needed.
It's not a criteria for all the projects in the world.
I have utmost respect for the maintainers and contributors of Request and so should you.
[+] [-] have_faith|6 years ago|reply