Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Request Node lib used by 48k modules is now deprecated

github.com

Post reply on HN
Print view View original

31–40 of 135 posts

Re: Request Node lib used by 48k modules is now deprecated

#31

Post by Klathmon »

ruffrey wrote: post #20

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.

[1] https://github.com/request/request/issues/3142

Re: Request Node lib used by 48k modules is now deprecated

#32

Post by hombre_fatal »

wnevets wrote: post #23

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

They have marked the package as deprecated on NPM. https://docs.npmjs.com/cli/deprecate

See the banner on this page: https://www.npmjs.com/package/request

They are urging people to consider the enumerated alternatives.

Re: Request Node lib used by 48k modules is now deprecated

#34

Post by lootsauce »

Tomte wrote: post #26

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

not stirring anything up, its the first headline on the readme. https://github.com/request/request#deprecated

Re: Request Node lib used by 48k modules is now deprecated

#35

Post by hombre_fatal »

Ididntdothis wrote: post #30
coolreader18 wrote: post #18

Earlier quoted context omitted.

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.

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.

Re: Request Node lib used by 48k modules is now deprecated

#36

Post by BenoitEssiambre »

tal_berzniz wrote: post #29
coolreader18 wrote: post #18

Earlier quoted context omitted.

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, a…

>It doesn't have Promise support

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

Re: Request Node lib used by 48k modules is now deprecated

#37

Post by lootsauce »

Klathmon wrote: post #31
ruffrey wrote: post #20

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 rely…

I totally agree with this approach, however it seems like a good idea to use alternatives for future work.

Re: Request Node lib used by 48k modules is now deprecated

#38

Post by Klathmon »

chadlavi wrote: post #25
Klathmon wrote: post #12

Earlier quoted context omitted.

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 pret…

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.

Re: Request Node lib used by 48k modules is now deprecated

#39

Post by cipherboy »

chadlavi wrote: post #25
Klathmon wrote: post #12

Earlier quoted context omitted.

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 pret…

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... :-)

Re: Request Node lib used by 48k modules is now deprecated

#40

Post by nikanj »

dpedu wrote: post #16

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

I wouldn’t mind if most of the software I used was deprecated like this.
Post reply on HN