Request’s Past, Present and Future

https://github.com/request/request/issues/3142

173 71 7 years ago

menzoic• 7 years ago

Clickbait title on HN? He said it's one of the first, not the very first one. Also just say "request". Anyone interested in an old npm package being deprecated will probably know this module. "request is being deprecated on NPM" is eye catching enough.

scrollaway• 7 years ago

On top of this it's not being deprecated, although it seems they considered that option. It's just going into maintenance mode, which makes sense for a library which is essentially done (and why wouldn't it be, if it's been around for 10 years?).

bryanrasmussen• 7 years ago

https://news.ycombinator.com/item?id=19604560 explains why it is not really going in to maintenance mode though.

mort96• 7 years ago

Ironically, I found the title to have the opposite effect; I read that "Node's oldest NPM package is being deprecated", and didn't think much of it; I imagine the oldest package in a repo is often just some kind of test package or some boring utility which isn't relevant anymore. It was first after clicking and reading that it's talking about requests that I thought, "oh, that's actually a kind of big deal".

sctb• 7 years ago

We've reverted the title from “Node's oldest NPM package is being deprecated”.

revskill• 7 years ago

What's the reason for being in maintainance mode then ? I don't see it in the post though.

Raed6673• 7 years ago

I have followed the twitter discussions and tl;dr is "the package needs a major rewrite and breaking changes for it to adopt Promises async/await and if anyone wants those there are more adapted projects already"

staticvoidmaine• 7 years ago

I because think maintenance mode is a responsible alternative to abandoning the package altogether as it has (from the post) ~41k packages that depend on it.

garou• 7 years ago

https://github.com/request/request/issues/3142#issuecomment-...

mikeal commented 6 days ago:

Let’s just bump the major version when we deprecate. That way most people depending on the project won’t see this error until they try to upgrade to a new major, which means they are actively developing it and really should look for an alternative.

novaleaf• 7 years ago

I don't think that's a good idea.

The problem is that most of replacements are of lower quality than request.

I just moved to request from axios about a week ago. Axios has multi-year persistent bugs around proxy support, modifying https agents, and unhandled promise exceptions. Probably due to low contributions (the code base is quite complex). You only find these out after investing into axios heavily.

To new users axios looks superficially as good as request (similar number of users, promises by design, etc)

yjftsjthsd-h• 7 years ago

So... Semver? That seems like a great idea.

userbinator• 7 years ago

request will stop considering breaking changes.

Does the JS community seem to consider that a bad thing...? To me, this sounds more like "is becoming stable" than "is being deprecated".

tlrobinson3• 7 years ago

“requests” doesn’t support (or apparently want to support) Promises which are now widely used in the JavaScript community, thus it’s obsolete. Promises work best when all the async operations in your code use them, especially with async/await.

Interestingly early versions of Node had a limited form of Promises but they were quickly removed.

matthewaveryusa2• 7 years ago

Just to give a little bit more context, in contemporary javascscript you can write something like this (wrapped in a try-catch:

    async function http_request_new(url) { return new Promise(...) }
    const http_response = await http_request_new("https://www.google.com")
    ...

The await signals that the asynchronous http_request function is non-blocking, and we should continue execution once the non-blocking return value (promise) has resolved. Previously idiomatic javascript would have looked like this:

    function http_request_old(url, cb) { return ... }
    http_request_old("https://www.google.com", function(error, http_response) { ... })

Luckily node.js provides util.promisify that converts any old callback-style async function into one that returns a promise, so that await can be used:

    http_request_new = util.promisify(http_request_old)
    const http_response = await http_request_new("https://www.google.com")
    ...

Unless I'm mistaken, it's fairly trivial to promisify the old-style code

sjustinas2• 7 years ago

There is an [official] additional package "request-promise" that adds Promise support. I don't dabble in Node much, but is this a bad thing? Although on the other hand, most other libraries support promises out of the box (e.g. using the "pass no callback to get a Promise back" pattern).

Sachse• 7 years ago

No, but `request` does not implement modern JS features such as promises and async/await which generally have become commonplace. So what this announcement means is that such features won't ever be added, and that people should look to another library for HTTP requests in "modern JS".

sjustinas2• 7 years ago

As I replied to tlrobinson above, is this a problem when there is an an official package that bolts on a promise support?

Klathmon6• 7 years ago

As the post explains, Javascript has changed significantly since request was first created, and that left them with 3 real options:

1. Try to make massive breaking changes to the request module to make it more easy to work with in the current javascript landscape (promises, new streams, async generators, etc...). This is a problem because then the millions of blog posts, comments, stack overflow answers, and more are all now outdated and wrong. And as the author explained, it would basically be a completely new library.

2. ignore it and become a thorn in the side of devs everywhere (oh, i can use new streams and promises in 99% of my codebase, except for a few old modules that we still use or have to code around until they get removed as they are difficult to work with)

3. Deprecate request, and make a new module under a new name which can adapt to the current landscape.

So if you value non-breaking changes over developer experience and complexity of integration, then it's a good thing for you. If you value tools which work with the language as it exists now rather than against it, it's also a good thing for you since the new "request by a different name" will work much better in current javsascript.

This is the opposite of what Angular did. Angular 1 vs 2+ were basically different libraries. Rather than take the angular route and just increment the number and keep the name, they are trying something different. They are throwing away the name and starting fresh.

HatchedLake7213• 7 years ago

I'll start from bottom options:

3) "deprecate request and start new" - and discard 10 years of commits, stability and tests? Wouldn't be a rational way to go.

2) "ignore it and become a thorn in the side of devs everywhere" - it wouldn't become a thorn more than it is now, would it? It's a 10 year old package that's downloaded 14 million times a week. It doesn't feel a thorn with those numbers. You can also `util.promisify` it if a callback is a "thorn" for you as a developer. (but see https://news.ycombinator.com/item?id=19604867)

1) "there are a lot of google results with solutions that the new breaking changes will make obsolete" - that's what semver and major versions are for. "We'll break Stack Overflow answers" doesn't feel like a valid reason. jQuery has had its fair share of breaking changes in the last 12 years, and we know the numbers if we compare `jQuery` vs `request` questions on Google/Stack Overflow, so again, it doesn't feel like a valid reason.

pbreit• 7 years ago

Wouldn't there be a 4th option of adding support for the newer patterns without breaking the old?

UK-Al05• 7 years ago

I don't know much about the javascript ecosystem, but isn't this what major version updates are for?

rmrfrmrf• 7 years ago

There's precedent for outright deprecating a package when others exist that do a better job of meeting current development needs. With Promises and node/browser cross compatibility being the biggest ecosystem shifts, there are a few newer choices that already meet those needs. Also, `request` in particular would be gross to upgrade since so many people rely on additional dependencies that add compatibility for things like Promises, retry strategies, etc., all with varying degrees of active maintenance.

royjacobs• 7 years ago

Hmm, so there are 41K packages depending on 'request' but from now on everything that is merged into master is immediately going to be published?

Sounds like a recipe for disaster not unlike what happened with event-stream.

taspeotis• 7 years ago

At least they're trying to manage it responsibly:

We’re going to have to remove inactive collaborators and enforce 2fa, because commit rights will effectively become npm publish rights.

zamadatix• 7 years ago

"Let’s just bump the major version when we deprecate. That way most people depending on the project won’t see this error until they try to upgrade to a new major, which means they are actively developing it and really should look for an alternative."

You won't be able to enter the "recipe for disaster" without at least seeing the warning when you update your dependencies. At that point it's your prerogative if you want to continue with a deprecated package.

VeejayRampay• 7 years ago

I think a comment in this thread should be visible to highlight any alternatives to request.

I've been mentions to got (https://www.npmjs.com/package/got), if anyone cares to point to other alternatives, that'd be nice, if only for educational purposes.

skrebbel• 7 years ago

fetch() has an excellent API. It's native in browsers and it has a good Node implementation called node-fetch.

https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWor...

tlrobinson3• 7 years ago

I agree “fetch” is good enough in many cases. It doesn’t have all the conviences many clients do, but sometimes those can be added with a simple wrapper function tailored to your use case.

ihuman• 7 years ago

How come fetch hasn't been integrated directly into node, like how its integrated directly into browsers?

bostonvaulter2• 7 years ago

I don't think fetch provides progress indicators yet which can hamper its usage if you want good UX for certain operations like uploads.

namanyayg2• 7 years ago

Mikeal is working on `bent` [1] but I'm not sure I like how it results in a few lines extra over a `request` like library. Can anyone explain why this syntax?

[1] https://github.com/mikeal/bent

013a• 7 years ago

Axios (https://www.npmjs.com/package/axios) is probably one of the most popular.

namanyayg2• 7 years ago

What's the alternative to Request? I see Mikeal has made Bent [1], but I'm not sure if the new, alien syntax is worth it? Also found got [2], thoughts?

[1] https://github.com/mikeal/bent [2] https://github.com/sindresorhus/got

Raed6673• 7 years ago

bent seems too "bare-bones" for my daily usage. If you like that good for you, but I have been using axios[0] which is more heavy weight.

https://github.com/axios/axios

pier252• 7 years ago

Problem with Axios is that it has almost 500 open issues and not enough maintainers.

We've moved to fetch, which is not as handy, but is the standard lib in the browser. Actually we use wretch which adds a more convenient API on top of fetch.

https://github.com/elbywan/wretch

For Node we use node-fetch which mimics the fetch API using the native HTTP module in the background:

https://github.com/bitinn/node-fetch

cphoover• 7 years ago

I use this package... which mirrors the whatwg fetch API and has support for promises baked in:

https://www.npmjs.com/package/isomorphic-fetch

dap• 7 years ago

Is the implication that every library module with async code must be rewritten to use promises or else be obsolete?

snek3• 7 years ago

it's not just promises. as the maintainers of request continue trying to try to fix architectural bugs they are finding it would be easier to rewrite it from scratch rather than continue modifying the current one. this is said in about as many words in the linked issue too, so make sure you read before commenting ;)

HatchedLake7213• 7 years ago

"easier to rewrite from scratch" is a fallacy. https://www.joelonsoftware.com/2000/04/06/things-you-should-...

CSMastermind• 7 years ago

As someone who's tried to switch off of `request` recently, I'm worried about this. I didn't find any of the alternatives to be particularly viable.

spion• 7 years ago

Node really doesn't pay attention to nice API design. If all readable streams had

`Stream<T>.toBufferAsync(): Promise<Buffer>`

`Stream<T>.toStringAsync(): Promise<string>`

`Stream<T>.toArrayAsync():Promise<T[]>`

then you could quickly collect any stream you want into a promise, including the stream returned by request.

Here is how you do a Stream API properly.

https://api.dartlang.org/stable/2.2.0/dart-async/Stream-clas...

Has first, last, toList(), map, reduce, filter, takeWhile, skipWhile, Stream.periodic and other great goodies that make stream usage nice and easy.

Too bad Google never invested this amazing API designer power into JS, they could've been the "apache commons" of node.

snek3• 7 years ago

We're getting there. I made both node and web streams into async iterables, and have now proposed this for js standardisation: https://github.com/tc39/proposal-iterator-helpers

andybak• 7 years ago

Gosh. I was rather hoping the days of Javascript churn were over but reading this reminds me of why I lost interest in front-end web development.

dimgl2• 7 years ago

`request` is mostly used on the server-side...

s_y_n_t_a_x• 7 years ago

You still use xhr requests (or the easier fetch api) on the frontend. This is for the backend.

Most languages have multiple 3rd party libraries for HTTP requests, and I'm sure some a lot get deprecated.

Request’s Past, Present and Future

Related Stories