12 ms·

Request Node lib used by 48k modules is now deprecated

150 points by lootsauce 7y ago

winrid 7y ago
What, why? Edit: https://github.com/request/request/issues/3142 https://github.com/request/request/issues/3142
- petercooper 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
        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 7y ago
        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.
      - cipherboy 7y ago
        Yeah but think of it from an (Linux OS) maintainer perspective: if you don't have a supported way to install parallel versions of the same package, you're stuck creating it under a new name (e.g., request999) because packages won't update. This is the solution in, e.g., Fedora where "junit" means junit4 and "junit5" is a separate package. Over time, junit might become deprecated and be removed from Fedora when all deps have moved on and junit5 takes over the junit package name, perhaps a junit6 will emerge. Or junit4 gets recreated for the last two legacy apps using junit to live on. Who knows! But from a maintainer perspective, better to have a separate name than a new breaking version... :-)
manojlds 7y ago
48k? Isn't github showing 4.4m? Everyone I see seems to use axios these days.
- Narretz 7y ago
  Github shows which repositories use request. 48k is the number of modules on npm.
- pier25 7y ago
  > 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 7y ago
    What would be the alternative to Axios?
    - pier25 7y ago
      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
    - deleted 7y ago
      [deleted]
craftoman 7y ago
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 7y ago
  Seems like a disrespectful way of describing someone else's work, regardless of shortcomings.
  - craftoman 7y ago
    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 7y ago
      That's just Power Law. Like it or not, I don't think there is a workaround.
      - craftoman 7y ago
        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.
- kaushikt 7y ago
  There is no reason to be disrespectful. 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.
nem_pet 7y ago
This little maneuver is gonna cost us 51 years.
- nem_pet 7y ago
  I don’t see a point to give negative if you don’t get it.
  - jkahrs595 7y ago
    We get it, it just adds nothing to the conversation.
    - nem_pet 7y ago
      Was hoping to make someone laugh...
      - hombre_fatal 7y ago
        I think we all have "NPM/JS bad" fatigue.
- deleted 7y ago
  [deleted]
floatingatoll 7y ago
Previously on HN (72 comments): https://news.ycombinator.com/item?id=19604148 https://news.ycombinator.com/item?id=19604148
lootsauce 7y ago
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 7y ago
  “got” has support for streaming. We have a migration guide for “request” users: https://github.com/sindresorhus/got/blob/master/documentation/migration-guides.md https://github.com/sindresorhus/got/blob/master/documentatio...
tcd 7y ago
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 7y ago
  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).
- thrower123 7y ago
  Are they being paid to do so? If not, then you've got to do your own looking of the gift-horse in the mouth, and not expect the giver to do it for you.
- SahAssar 7y ago
  It is the responsibility of the developer who added the dependency, or the person who reviewed the PR that added the dependency. If neither of those are around it is the responsibility of the person who took over either of those responsibilities or the person who now maintains that package. If that person isn't around then it is unmaintained, and should not be used. If that sounds complicated it is because it is. In any given package you might have 1-100ish people with responsibilities, but they also have sub-responsibles that they might not know about. The package management system has no responsibility except to serve the exact version of the exact package you requested. If you expect anything more from them you are not looking for "package management" and npm is probably not the right place to look. This is one of the reasons I try to not have transitive dependencies in JS projects.
dpedu 7y ago
> 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".
- djsumdog 7y ago
  Yea, makes me think of how every news blog reported mp3 as "dead" when the patent expired, when they should have been saying mp3 is now license free.
  - MadWombat 7y ago
    Also, "mp3 is license free" rhymes :)
    - Waterluvian 7y ago
      License free mp3 is good to see. But what we need, according to me, is for AAC to become license free.
      - DyslexicAtheist 7y ago
        People don't wanna pay for CDs Now every other house holds got PCs They download MP3s, People please be reasonable (yeah) How am I gonna make my g's, If you got my album before the release, The quality's rubbish and there ain't no sleaves,
  - loeg 7y ago
    I don't think anyone really uses mp3 for audio compression anymore, though. There's FLAC, mp4 (AAC), and free Vorbis (which claims to be competitive with both); and DVDs and whatnot are still using AC3, EAC3, and various other Dolby Digital audio formats. Given that landscape, I don't know why you'd pick mp3.
    - anthony_doan 7y ago
tal_berzniz 7y ago
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 7y ago
  There doesn't have to be something wrong with a solution to deprecate it, there just has to be a better alternative.
  - tal_berzniz 7y ago
    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 7y ago
      >It doesn't have Promise support That's a feature. https://medium.com/@b.essiambre/continuation-passing-style-patterns-for-javascript-5528449d3070?source=friends_link&sk=976fb25ca6c15eba3a4badcf55ba698e https://medium.com/@b.essiambre/continuation-passing-style-p...
      - hombre_fatal 7y ago
        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.
ruffrey 7y ago
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?
- lootsauce 7y ago
  Not identical but I am considering got because of nice docs and solid streaming support https://github.com/sindresorhus/got#comparison https://github.com/sindresorhus/got#comparison
  - deleted 7y ago
    [deleted]
- Klathmon 7y ago
  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 7y ago
    I totally agree with this approach, however it seems like a good idea to use alternatives for future work.
    - Klathmon 7y ago
      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.
wnevets 7y ago
When did maintenance mode become deprecated? Why isnt that hyperbole?
- hombre_fatal 7y ago
  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 7y ago
    > 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 7y ago
      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.
  - wnevets 7y ago
    >They have marked the package as deprecated on NPM. Fair enough, the OP link didnt actually mention deprecated anywhere.
- outside1234 7y ago
  They don't expect maintenance mode to last forever and they don't want new developers to use it.
Tomte 7y ago
Real title: "Alternative libraries to request". The "deprecating" part is simply the submitter's invention, in order to stir up drama.
- lootsauce 7y ago
  not stirring anything up, its the first headline on the readme. https://github.com/request/request#deprecated https://github.com/request/request#deprecated
- masklinn 7y ago
  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 7y ago
    Okay, so not totally invented, but still not the original title (which is perfectly descriptive), but clickbait.
EGreg 7y ago
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_chaos/ 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 7y ago
  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.
shaggie76 7y ago
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.
LukaszWiktor 7y ago
axios FTW!
cloverich 7y ago
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
deleted 7y ago
[deleted]

150 points by lootsauce 7y ago

winrid 7y ago

What, why? Edit: https://github.com/request/request/issues/3142 https://github.com/request/request/issues/3142

petercooper 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
        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.
    - cipherboy 7y ago
      Yeah but think of it from an (Linux OS) maintainer perspective: if you don't have a supported way to install parallel versions of the same package, you're stuck creating it under a new name (e.g., request999) because packages won't update. This is the solution in, e.g., Fedora where "junit" means junit4 and "junit5" is a separate package. Over time, junit might become deprecated and be removed from Fedora when all deps have moved on and junit5 takes over the junit package name, perhaps a junit6 will emerge. Or junit4 gets recreated for the last two legacy apps using junit to live on. Who knows! But from a maintainer perspective, better to have a separate name than a new breaking version... :-)

manojlds 7y ago

48k? Isn't github showing 4.4m? Everyone I see seems to use axios these days.

Narretz 7y ago
Github shows which repositories use request. 48k is the number of modules on npm.
pier25 7y ago
> 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 7y ago
  What would be the alternative to Axios?
  - pier25 7y ago
    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
  - deleted 7y ago
    [deleted]

craftoman 7y ago

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 7y ago
Seems like a disrespectful way of describing someone else's work, regardless of shortcomings.
- craftoman 7y ago
  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 7y ago
    That's just Power Law. Like it or not, I don't think there is a workaround.
    - craftoman 7y ago
      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.
kaushikt 7y ago
There is no reason to be disrespectful. 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.

nem_pet 7y ago

This little maneuver is gonna cost us 51 years.

nem_pet 7y ago
I don’t see a point to give negative if you don’t get it.
- jkahrs595 7y ago
  We get it, it just adds nothing to the conversation.
  - nem_pet 7y ago
    Was hoping to make someone laugh...
    - hombre_fatal 7y ago
      I think we all have "NPM/JS bad" fatigue.
deleted 7y ago
[deleted]

floatingatoll 7y ago

Previously on HN (72 comments): https://news.ycombinator.com/item?id=19604148 https://news.ycombinator.com/item?id=19604148

lootsauce 7y ago

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 7y ago
“got” has support for streaming. We have a migration guide for “request” users: https://github.com/sindresorhus/got/blob/master/documentation/migration-guides.md https://github.com/sindresorhus/got/blob/master/documentatio...

tcd 7y ago

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 7y ago
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).
thrower123 7y ago
Are they being paid to do so? If not, then you've got to do your own looking of the gift-horse in the mouth, and not expect the giver to do it for you.
SahAssar 7y ago
It is the responsibility of the developer who added the dependency, or the person who reviewed the PR that added the dependency. If neither of those are around it is the responsibility of the person who took over either of those responsibilities or the person who now maintains that package. If that person isn't around then it is unmaintained, and should not be used. If that sounds complicated it is because it is. In any given package you might have 1-100ish people with responsibilities, but they also have sub-responsibles that they might not know about. The package management system has no responsibility except to serve the exact version of the exact package you requested. If you expect anything more from them you are not looking for "package management" and npm is probably not the right place to look. This is one of the reasons I try to not have transitive dependencies in JS projects.

dpedu 7y ago

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

djsumdog 7y ago
Yea, makes me think of how every news blog reported mp3 as "dead" when the patent expired, when they should have been saying mp3 is now license free.
- MadWombat 7y ago
  Also, "mp3 is license free" rhymes :)
  - Waterluvian 7y ago
    License free mp3 is good to see. But what we need, according to me, is for AAC to become license free.
    - DyslexicAtheist 7y ago
      People don't wanna pay for CDs Now every other house holds got PCs They download MP3s, People please be reasonable (yeah) How am I gonna make my g's, If you got my album before the release, The quality's rubbish and there ain't no sleaves,
- loeg 7y ago
  I don't think anyone really uses mp3 for audio compression anymore, though. There's FLAC, mp4 (AAC), and free Vorbis (which claims to be competitive with both); and DVDs and whatnot are still using AC3, EAC3, and various other Dolby Digital audio formats. Given that landscape, I don't know why you'd pick mp3.
  - anthony_doan 7y ago

tal_berzniz 7y ago

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 7y ago
There doesn't have to be something wrong with a solution to deprecate it, there just has to be a better alternative.
- tal_berzniz 7y ago
  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 7y ago
    >It doesn't have Promise support That's a feature. https://medium.com/@b.essiambre/continuation-passing-style-patterns-for-javascript-5528449d3070?source=friends_link&sk=976fb25ca6c15eba3a4badcf55ba698e https://medium.com/@b.essiambre/continuation-passing-style-p...
    - hombre_fatal 7y ago
      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.

ruffrey 7y ago

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?

lootsauce 7y ago
Not identical but I am considering got because of nice docs and solid streaming support https://github.com/sindresorhus/got#comparison https://github.com/sindresorhus/got#comparison
- deleted 7y ago
  [deleted]
Klathmon 7y ago
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 7y ago
  I totally agree with this approach, however it seems like a good idea to use alternatives for future work.
  - Klathmon 7y ago
    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.

wnevets 7y ago

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

hombre_fatal 7y ago
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 7y ago
  > 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 7y ago
    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.
- wnevets 7y ago
  >They have marked the package as deprecated on NPM. Fair enough, the OP link didnt actually mention deprecated anywhere.
outside1234 7y ago
They don't expect maintenance mode to last forever and they don't want new developers to use it.

Tomte 7y ago

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

lootsauce 7y ago
not stirring anything up, its the first headline on the readme. https://github.com/request/request#deprecated https://github.com/request/request#deprecated
masklinn 7y ago
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 7y ago
  Okay, so not totally invented, but still not the original title (which is perfectly descriptive), but clickbait.

EGreg 7y ago

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_chaos/ 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 7y ago
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.

shaggie76 7y ago

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.

LukaszWiktor 7y ago

axios FTW!

cloverich 7y ago

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

deleted 7y ago

[deleted]