Allow ES6 native Promises and other promise implementations

[analog-nico]

As suggested by @silverbp in issue #64 users of Request-Promise probably would like to use ES6 native Promises instead of Bluebird or even other promise implementations.

Waiting for +1's with the preferred promise implementation.

[vgoloviznin]

+1 for native

[mikeal]

While Bluebird is still faster than native promises they lack the features we've added to core for global error handling in promises. If people still want Bluebird on the frontend they'll get them injected by their compile toolchain.

[analog-nico]

Hi @mikeal good point regarding the compile toolchain. I assume from that that native promises - and not Bluebird - lack the features? (Sorry, the grammar of your first sentence confuses me non-native speaker.;)

Which features in core are you actually referring to?

[mikeal]

Here's the first one https://iojs.org/api/process.html#process_event_unhandledrejection and there may be another one eventually for a totally unhandled promise. These are only features in native promises as these require low level vm hooks.

[analog-nico]

Thanks for the pointer! Also offering native promise support seems unquestionable to me now.

[MarkHerhold]

+1 for native, so long as we can override with our own version of Bluebird/whatever.

The native-or-bluebird module would also be an attractive option (instead of any-promise) and would align more with the history of this project.

request-promise is on bluebird 2, where bluebird 3 is now out so I am in favor of decoupling in order to make selecting the promise implementation more flexible.

[analog-nico]

Thanks for the pointer to native-or-bluebird @MarkHerhold ! Indeed, the next version will at least support native and Bluebird.

[gillesdemey]

+1 for using native-or-bluebird, but many developers will probably want to choose which one specifically.

[tonylukasavage]

+1 for native, as I would have pulled this into our project immediately if it supported native Promises.

[hildjj]

native-or-bluebird works for me. Note to @mikeal 's point about unhandledRejection, that seems to work on bluebird 3.1.1, not sure when it was added:

var bb = require('bluebird');
process.on('unhandledRejection', e => console.log('unhandled', e));
new bb.Promise((res,rej) => rej('foo'));

Output:

unhandled foo

[iggycoloma]

+1 for native support, along with the caveats above about letting people choose which Promise implementation they wish to use.

[sherdeadlock]

any-promise
It supports es6-promise, bluebird, rsvp, when, q.

[eilgin]

👍 for having native promises supported.

[analog-nico]

@jonathanong kindly informed us that they deprecated native-or-bluebird in favor of any-promise. So I checked out any-promise yesterday and @kevinbeaty even did a little update.

IMHO any-promise would be perfect for request-promise. Any thoughts?

[hildjj]

any-promise is fine. Go for it.

[massimocode]

Hey I'm wondering if there has been any progress on this?

We have an issue where bluebird promises are not playing nicely with our JS Clock override (zurvan) so we can't deterministically know when there are no more bluebird promises being processed by the event loop.

It would be great if users could choose which promise library they wanted to use (i.e. bluebird / es6 / etc)

For an idea you might want to look at durandaljs which allows users to override promises by overriding the default implementation of a function called system.deferred:
https://github.com/BlueSpire/Durandal/blob/master/src/durandal/js/system.js#L232

It would be cool if we could do something like require('request-promise').deferred = function .... or something like that to override the type of promise it uses.

Thanks!

[analog-nico]

Hi @massimocode the idea is to use any-promise. Then you can use any promise implementation. Which one would solve your problem?

[niftylettuce]

I started to use native promises and the new ES6 fetch() HTTP method here https://github.com/glazedio/frisbee.

[raitucarp]

what is status of this issue?

[analog-nico]

Half done. There will be request-promise-native and request-promise-any.

Since I already implemented request-promise-native I can already say that it will be nearly identical to request-promise except the Bluebird specific parts of course (.finally(...) and continuation-local-storage support). If you plan to use native promises in all your environments this library is the right choice. You may use request-promise right now and later just replace it with request-promise-native without any other changes needed.

If you want to inject different promise implementations depending on the environment you'll have to wait for request-promise-any for which I can't yet say how the usage will look like.

[raitucarp]

OK. Thank you for confirmation

[analog-nico]

Hey buddies, I just released request-promise@4.0.0 and along with it request-promise-native and request-promise-any.

All three libraries share the same core and will be maintained in parallel. The migration is straight forward so feel free to choose the Promise implementation you like best.

Thanks everyone for contributing to this discussion. Cheers!