8 ms·

Request’s Past, Present and Future

173 points by HatchedLake721 8y ago

menzoic 8y 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 8y 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 8y ago
    https://news.ycombinator.com/item?id=19604560 https://news.ycombinator.com/item?id=19604560 explains why it is not really going in to maintenance mode though.
- mort96 8y 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 8y ago
  We've reverted the title from “Node's oldest NPM package is being deprecated”.
revskill 8y ago
What's the reason for being in maintainance mode then ? I don't see it in the post though.
- Raed667 8y 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 8y 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 8y ago
https://github.com/request/request/issues/3142#issuecomment-479085436 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 8y 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 8y ago
  So... Semver? That seems like a great idea.
userbinator 8y 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".
- Sachse 8y 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".
  - sjustinas 8y ago
    As I replied to tlrobinson above, is this a problem when there is an an official package that bolts on a promise support?
- tlrobinson 8y 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.
  - matthewaveryusa 8y 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
UK-Al05 8y ago
I don't know much about the javascript ecosystem, but isn't this what major version updates are for?
- rmrfrmrf 8y 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.
- deleted 8y ago
  [deleted]
royjacobs 8y 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 8y 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 8y 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 8y 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 https://www.npmjs.com/package/got), if anyone cares to point to other alternatives, that'd be nice, if only for educational purposes.
- skrebbel 8y 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/WindowOrWorkerGlobalScope/fetch https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWor...
  - tlrobinson 8y 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 8y ago
    How come fetch hasn't been integrated directly into node, like how its integrated directly into browsers?
    - snek 8y ago
      it uses a lot of infrastructure that node doesn't have, like Request objects and Response objects and Body objects and mime checking etc etc list goes on. if someone feels like adding all those things to node and feels like arguing with our core maintainers about the duplication with http then maybe it will be added. https://github.com/nodejs/node/issues/19393 https://github.com/nodejs/node/issues/19393
    - TomMarius 8y ago
      Because Node.js already provides low level network access, while in browsers fetch() is the (second) lowest abstraction you can get to.
draw_down 8y ago
Seems like a sane bit of governance. What’s the issue?
namanyayg 8y 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 https://github.com/mikeal/bent [2] https://github.com/sindresorhus/got https://github.com/sindresorhus/got
- Raed667 8y 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 https://github.com/axios/axios
  - pier25 8y 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 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 https://github.com/bitinn/node-fetch
    - Raed667 8y ago
      I'm using axios in production for over 2 years now. Can you point me to a certain issue you had I'd need to anticipate (or check if I already have)?
      - pier25 8y ago
        I've used it in production for 3-4 years with no issues (that I know of) but it's a ticking time bomb. https://github.com/axios/axios/issues/1965 https://github.com/axios/axios/issues/1965 https://www.reddit.com/r/javascript/comments/an94xq/axios_needs_maintainers/ https://www.reddit.com/r/javascript/comments/an94xq/axios_ne...
cphoover 8y 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 https://www.npmjs.com/package/isomorphic-fetch
dap 8y ago
Is the implication that every library module with async code must be rewritten to use promises or else be obsolete?
- snek 8y 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 ;)
  - HatchedLake721 8y ago
    "easier to rewrite from scratch" is a fallacy. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
    - matt_kantor 8y ago
      "Easier to fix if they allow themselves to completely break the public API" was how I interpreted the situation with request.
      - HatchedLake721 8y ago
        That's what MAJOR stands for in semver - when you make incompatible/breaking API changes
        matt_kantor 8y ago
        Right. Are you saying that you think request should make these changes and go through a major version bump? The linked issue talks in depth about why they don't want to do that.
CSMastermind 8y 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 8y 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-class.html 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.
- snek 8y 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 https://github.com/tc39/proposal-iterator-helpers
andybak 8y 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.
- dimgl 8y ago
  `request` is mostly used on the server-side...
- s_y_n_t_a_x 8y 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.

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 8y 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 8y ago
  https://news.ycombinator.com/item?id=19604560 https://news.ycombinator.com/item?id=19604560 explains why it is not really going in to maintenance mode though.
mort96 8y 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 8y ago
We've reverted the title from “Node's oldest NPM package is being deprecated”.

revskill 8y ago

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

Raed667 8y 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 8y 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 8y ago

https://github.com/request/request/issues/3142#issuecomment-479085436 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 8y 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 8y ago
So... Semver? That seems like a great idea.

userbinator 8y 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".

Sachse 8y 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".
- sjustinas 8y ago
  As I replied to tlrobinson above, is this a problem when there is an an official package that bolts on a promise support?
tlrobinson 8y 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.
- matthewaveryusa 8y 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

UK-Al05 8y ago

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

rmrfrmrf 8y 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.
deleted 8y ago
[deleted]

royjacobs 8y 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 8y 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 8y 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 8y 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 https://www.npmjs.com/package/got), if anyone cares to point to other alternatives, that'd be nice, if only for educational purposes.

skrebbel 8y 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/WindowOrWorkerGlobalScope/fetch https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWor...
- tlrobinson 8y 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 8y ago
  How come fetch hasn't been integrated directly into node, like how its integrated directly into browsers?
  - snek 8y ago
    it uses a lot of infrastructure that node doesn't have, like Request objects and Response objects and Body objects and mime checking etc etc list goes on. if someone feels like adding all those things to node and feels like arguing with our core maintainers about the duplication with http then maybe it will be added. https://github.com/nodejs/node/issues/19393 https://github.com/nodejs/node/issues/19393
  - TomMarius 8y ago
    Because Node.js already provides low level network access, while in browsers fetch() is the (second) lowest abstraction you can get to.

draw_down 8y ago

Seems like a sane bit of governance. What’s the issue?

namanyayg 8y 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 https://github.com/mikeal/bent [2] https://github.com/sindresorhus/got https://github.com/sindresorhus/got

Raed667 8y 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 https://github.com/axios/axios
- pier25 8y 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 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 https://github.com/bitinn/node-fetch
  - Raed667 8y ago
    I'm using axios in production for over 2 years now. Can you point me to a certain issue you had I'd need to anticipate (or check if I already have)?
    - pier25 8y ago
      I've used it in production for 3-4 years with no issues (that I know of) but it's a ticking time bomb. https://github.com/axios/axios/issues/1965 https://github.com/axios/axios/issues/1965 https://www.reddit.com/r/javascript/comments/an94xq/axios_needs_maintainers/ https://www.reddit.com/r/javascript/comments/an94xq/axios_ne...

cphoover 8y 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 https://www.npmjs.com/package/isomorphic-fetch

dap 8y ago

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

snek 8y 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 ;)
- HatchedLake721 8y ago
  "easier to rewrite from scratch" is a fallacy. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
  - matt_kantor 8y ago
    "Easier to fix if they allow themselves to completely break the public API" was how I interpreted the situation with request.
    - HatchedLake721 8y ago
      That's what MAJOR stands for in semver - when you make incompatible/breaking API changes
      - matt_kantor 8y ago
        Right. Are you saying that you think request should make these changes and go through a major version bump? The linked issue talks in depth about why they don't want to do that.

CSMastermind 8y 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 8y 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-class.html 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.

snek 8y 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 https://github.com/tc39/proposal-iterator-helpers

andybak 8y 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.

dimgl 8y ago
`request` is mostly used on the server-side...
s_y_n_t_a_x 8y 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.