Consider any-promise.

[jamestalmage]

I'm really impressed with it. However, it throws on Node <= 0.12 if an implementation is not registered.

It might be interesting to make pinkie-promise a wrapper around any-promise that loads pinkie instead of throwing. Like any-promise, but it always gives you a promise implementation.

[floatdrop]

Why? If you need specific implementation, you can do global.Promise = require('bluebird'); in you application.

[jamestalmage]

any-promise offers any-promise/implementation (returns a string identifying which implementation was loaded). You can create optimized code paths based on that.

It has a well tested solution for browsers.

It avoids global.Promise on 0.12 (because it had problems? I don't know what they were).

Finally, it's just become a hugely popular way to provide customizeable Promise implementations.

[floatdrop]

You can create optimized code paths based on that.

@jamestalmage in readme they say opposite thing – you should not optimize your module code based on specific implementation.

From my point of view – best way to customize Promise implementation in application is to set global Promise object. I honestly do not see point of switching on it.

[sindresorhus]

I don't think it's worth doing a breaking change here at this point. Node.js 0.12 is out of active LTS anyways. So it's going away.

[jamestalmage]

Last argument. any-promise protects against multiple attempts to set the implementation, something you can't do with globals.