allow reverting to native Promise

I was quite surprised that on Chrome I saw that window.Promise was changed from the native one when I use this library as I intentionally didnt call the polyfill method. Then i saw the code:

Object.prototype.toString.call(P.resolve()) === '[object Promise]' && !P.cast)

and realized the issue as in Chrome this test fails (as reported multiple times #139 #136 #132 …)

Normally I wouldnt care this much but Im working on a project in which my code is inserted into other websites and I dont wish to change anything on the global level and unfortunately using this library violates this rule.

Its my opinion that the explanation that the native imp may have issues/bugs is irrelevant for cjs/amd environments. The library shouldnt touch the global object unless explicitly requested., But if you still wish to leave it as it is, please give us the ability to revert back to the original/native Promise. a long the lines of noConflict.

Thanks! Yoav

[nazrhyn]

As I just had a run-in with this module, I’d like to quote @yoavniran, from above (emphasis mine):

From one of the posts here I think a different version/flavor of this lib without the aggressive override is less preferable as it means that if this library is a dependency of another library you’re using, you wont be able to change the default behavior even if you wanted.

I had already done…

global.Promise = require('bluebird');

…but, when I required the dropbox module, and it required es6-promise, bluebird was overwritten by the polyfill. Luckily, we don’t actually intend to interact with Dropbox at this time; but, if we needed to in the future, how would we prevent this behavior? My only option would be to do something crazy like this:

let p = require('bluebird');
Object.defineProperty(global, 'Promise', {
    get: function () {
        return p;
    },
    set: function () {}
});

[dlong500]

It’s been a while without any activity here. When is the 4.0 release that doesn’t auto-polyfill supposed to come out?