use native Promise if available

[jonathanong]

No description provided.

[lovell]

Thank you. Looks like there's a clash with one of the other PRs that prevents auto-merge. Are you able to rebase from upstream/master first?

[jonathanong]

there you go

[lovell]

Marvellous, thank you.

[petkaantonov]

What's the rationalization for this? This silences uncaught errors, breaks code that use features other than .then and is much slower (and always will be)

[lovell]

Hi @petkaantonov, firstly and most importantly, your bluebird library is a joy to use and has proven itself to be high-performance, hence its selection for this module. Thank you for all the time you continue to devote to it!

I am interested to learn more about why V8 native Promises will always be slower.

Contributor @jonathanong may have comments on this, but I believe this module (with its own, bold "fastest" claims) would be silly not to use the fastest Promises implementation.

(For now, global.Promise is "hidden" behind the --harmony flag and I believe this will continue to be the case in Node.js 0.12.)

[petkaantonov]

I am interested to learn more about why V8 native Promises will always be slower.

Because they need to support sub classing and overridden local properties (they currently dont). The spec also defines only .all and .then and other features cannot use internals. It's a lot like the situation with .bind.

Contributor @jonathanong may have comments on this, but I believe this module (with its own, bold "fastest" claims) would be silly not to use the fastest Promises implementation.

The native promises in node 11.13 are currently one of the slowest promises implementation.

[jonathanong]

meh i don't care. i just don't like deps

[petkaantonov]

This doesn't remove dependency

[lovell]

Gents, thanks to your inspiration I've read a little more about V8 optimisation and also how it handles Promises natively. Searching for a file named promises.cc in the V8 source I instead found promise.js so now understand @petkaantonov's comments about "native" performance and (lack of) features.

Modifying sharp to accept an optional (require-time?) parameter of a Promises implementation, defaulting to bluebird, feels like the way to go here.

[charmander]

Why? Promises implementations, done correctly, are compatible (they operate on thenables, not instances of their own types).

In the case of extensions specific to certain implementations, SomePromise.resolve(sharp.…) should be enough to perform a conversion, and is far less fragile.

[lovell]

Yes, good point @charmander, do people really want to inject their own/favourite Promises library into third-party modules. Thanks for reminding me of the need to keep it simple.