This little maneuver is gonna cost us 51 years.
[deleted]
Request Node lib used by 48k modules is now deprecated
21–30 of 135 posts
Re: Request Node lib used by 48k modules is now deprecated
#22I 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…
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).
Re: Request Node lib used by 48k modules is now deprecated
#23When did maintenance mode become deprecated? Why isnt that hyperbole?
Re: Request Node lib used by 48k modules is now deprecated
#24Can 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?
Not identical but I am considering got because of nice docs and solid streaming support https://github.com/sindresorhus/got#comparison
Re: Request Node lib used by 48k modules is now deprecated
#25Earlier quoted context omitted.
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.
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.
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.
Re: Request Node lib used by 48k modules is now deprecated
#26Real title: "Alternative libraries to request". The "deprecating" part is simply the submitter's invention, in order to stir up drama.
Re: Request Node lib used by 48k modules is now deprecated
#27> 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".
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.
Re: Request Node lib used by 48k modules is now deprecated
#2848k? Isn't github showing 4.4m? Everyone I see seems to use axios these days.
> 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
Who knows for how long though...
Re: Request Node lib used by 48k modules is now deprecated
#29Deprecating 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.
There doesn't have to be something wrong with a solution to deprecate it, there just has to be a better alternative.
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.
Re: Request Node lib used by 48k modules is now deprecated
#30Deprecating 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.
There doesn't have to be something wrong with a solution to deprecate it, there just has to be a better alternative.
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.