Request Node lib used by 48k modules is now deprecated
github.com
github.com
> 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".
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,
Do you have a source for this? Is this audio compression for music production people or in general? I just can't see mp3 being out.
If you have a suggestion for an encoding+container that is will work out of the box both natively and in every major browser, across every major OS (Windows MacOS, Android, iOS and GNU/Linux, specifically distros like Fedora or Trisquel that don't ship nonfree codecs in their default repos), I will gladly switch to it.
when's the last time Knuth wrote a check for TAOCP? Is it "dead"?
Those numbers across the bottom are your bank's routing number and your account number. I'm honestly surprised I don't hear more about e-check theft done using those numbers.
Those aren't secrets, are they? Isn't your bank account protected by separate secrets and or physical authentication tokens? You can't just take money out at a bank by giving a bank account number, surely?
You can seriously just say a bank account number at a bank in the US and walk away with a bag of cash from it, with no other security checks at all?
In the UK they’d make you enter a password or PIN or use 2FA.
You can use the numbers to request a wire transfer from the account. In fact, when you're setting up an ACH transaction for bills and such, they tell you to get the numbers from a check.
You can deposit without a pin bit to withdraw you need photo id and a verbal password or pin in every bank I've ever been in
We recently lost a book of checks and the bank totally wigged out. They demanded that we close the account immediately and it took a decent amount of back and forth to talk them into waiting a week (we wanted existing checks to clear). To my mind, this implied that they did no validation on checks.
I do know that I keep the numbers off a check from my checkbook I received when originally opening my bank account like 10 years ago in Lastpass. When sites that don't accept credit need payment information (my student loans mainly) I just copy/paste the numbers into their payment form and the money gets taken out of my account. No verification whatsoever, Nelnet is able to just withdraw the money from my account using those numbers.
I assume anybody with a debit processing backend or service can do the same if they have the routing/account #. It's kind of a wonder peoples money doesn't just disappear all the time really.
That's exactly what a check is. It's a legal document that says "I give you X dollars from account Y." You can use a napkin instead of a the pre-filled sheets of paper your bank sends you, and it's still the same legal document.
Typically your signature is checked against one on file, but only for large transactions, and of course handwriting signatures can be forged. And, if you are writing checks against other people's bank account, you'll probably go to prison. That is the check on the system.
(It's no different than signing a contract. I'll do this work and you'll pay me when it's done. What happens if they don't pay you? You sue them. The root of trust is the judicial system.)
They're allowed to, but have no (legal or socially expected) requirement to do so. I've never heard of a bank doing so for small (<$10k or so) amounts, and then only if fraud alerts are already present.
There's no serious jail time for it in the UK because the system doesn't let you do it in the first place!
Pretty recently. I just got one in the mail today.
Got one in the mail yesterday (check was written Feb 10). In fact you can figure out how many checks were written in the last month, roughly: compare https://web.archive.org/web/20200110074014/https://cs.stanfo... with https://web.archive.org/web/20200219035903/https://cs.stanfo... I imagine most of these checks (definitely all $7 of mine) were from finding bugs in pre-fascicles, i.e. bleeding-edge drafts he's been putting up online. (See near the bottom of https://cs.stanford.edu/~knuth/news.html)
On the other hand, while you mention Knuth and "done", TeX and METAFONT are better examples. He declared them "done" in 1990 (https://tug.org/TUGboat/Articles/tb11-4/tb30knut.pdf), but still does bug fixes:
> I still take full responsibility for the master sources of TeX, METAFONT, and Computer Modern. Therefore I periodically take a few days off from my current projects and look at all of the accumulated bug reports. This happened most recently in 1992, 1993, 1995, 1998, 2002, 2007, and 2013; following this pattern, I intend to check on purported bugs again in the years 2020, 2028, 2037, etc. The intervals between such maintenance periods are increasing, because the systems have been converging to an error-free state.
(The latest round, in 2013, did surface one bug: the debug string representation of an "empty" control sequence was missing a space.)
> I imagine most of these checks (definitely all $7 of mine)
The 0x$2.00 check I got from 10 Feb 2020 was for one typographical item in Volume 4A and one pedagogical improvement in Volume 1, Fascicle 1. So it is certainly possible to still get checks for material that is already published.
Since it is now 2020, anyone with bug reports from the typography stuff should send them in soon, wouldn't want to miss the deadline.
- On page 715 of Volume 4A, he had something like \`a when he meant to have just à.
- In Volume 1, Fascicle 1, there is a convention that the "main" entry point of an MMIX program begins at LOC #100. The convention is established early on and repeated throughout the text. However, at no point is it explained why LOC #100 was chosen (instead of LOC #0, LOC #80, or whatever). It could be gleaned through careful study -- LOC #0-#80 are reserved for trip/trap handling and one more location before #100 is reserved for a special second entry point -- but you basically had to read the entire fascicle to find /all/ of these. A naive user would be likely to try writing a program beginning at LOC #0 and wonder why it didn't seem to behave correctly. My suggestion was to just add a note explaining why LOC #100 was used. He agreed and you can find the added note in the latest errata for Volume 1, Fascicle 1.
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.
It seems like you meant it more in the sense of this library is "complete." Just in case anyone was confused.
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.
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.
That's a feature. https://medium.com/@b.essiambre/continuation-passing-style-p...
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
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.
What stdlib module supersedes `http`? Browsers have `fetch` and there's `node-fetch` and `axios` modules, but it's sad that core node hasn't updated the core http module.
"A better alternative" is not enough of a reason to not use another alternative, because "better" is not an absolute value and choices tend to have many axis to balance (for example, prior experience).
Deprecated functions within a module will surely stop working in the near future, but deprecated modules probably won't. It's not great that we see the same warning for both, and we should not treat both the same.
And there are more modern alternatives like axios that do have this promises interface.
// fetch with cookies:
const fetch = require('fetch-cookie/node-fetch')(require('node-fetch'));See the banner on this page: https://www.npmjs.com/package/request
They are urging people to consider the enumerated alternatives.
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.
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.
Fair enough, the OP link didnt actually mention deprecated anywhere.
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.
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.
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.
> 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.
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.
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... :-)
I'm a library maintainer, and it doesn't make any sense to me to create totally different packages with different names just to handle a breaking change. This is what semantic versioning exists for.
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.
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).
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.
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?
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.
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.
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...
On Node I've been using this lately: https://github.com/node-fetch/node-fetch
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!!
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.
That we should use less dependencies? Sure.
That we should review changes in our dependencies? Sure.
But If I were to take a nodejs app and move it from ubuntu version X to ubuntu version Y, node version Z to node version A, and update npm dependencies the code review itself would take me a year.
Is your point that we should only do this to npm dependencies?
Is this a wider problem with how we think about software development as never being finished instead of solving a problem and moving on to the next? Yes.
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.