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

41–50 of 135 posts

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

#41

Post by EGreg »

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_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!!

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

#43

Post by Klathmon »

lootsauce wrote: post #37
Klathmon wrote: post #31

Earlier quoted context omitted.

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.

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.

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

#44

Post by DougBTX »

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…

> However, the fact that he got "bored" with this solution

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

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

#45

Post by hombre_fatal »

BenoitEssiambre wrote: post #36
tal_berzniz wrote: post #29

Earlier quoted context omitted.

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

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/), 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.

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

#46

Post by thrower123 »

tcd wrote: post #13

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…

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.

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

#47

Post by chadlavi »

Klathmon wrote: post #38
chadlavi wrote: post #25

Earlier quoted context omitted.

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

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.

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

#48

Post by [deleted] »

lootsauce wrote: post #24
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?

Not identical but I am considering got because of nice docs and solid streaming support https://github.com/sindresorhus/got#comparison

[deleted]

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

#49

Post by neurobashing »

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

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

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

#50

Post by hombre_fatal »

EGreg wrote: post #41

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…

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.

Post reply on HN