Support swapping out Promise library

[wheresrhys]

Support swapping out Promise library

[wheresrhys]

I'm inclined to be quite dogmatic about only supporting Promise defined as a global because that's what the spec says it should be (and encourage users to polyfill it globally if it's not natively available).

Is there some reason you can't/don't want to do this?

[zachlysobey]

OK, it looks like I was operating under some false assumptions.

It does look like isomorphic-fetch's author wants to explicitly support the pattern I described above, but it is not in the library yet (so that approach does not work)

matthew-andrews/isomorphic-fetch#43

I am currently patching Promise globally which resolves my issue.

I would suggest that if isomorphic-fetch decides to merge in that PR, it would make sense to revisit this, since you explicitly support mocking that library.

In any case, that thank you for your extremely useful tool!

[pimterry]

I would use this. We're using fetch-mock to mock our promises, but moving from isomorphic-fetch to fetch-ponyfill at the moment, looking using the new fetch-mock sandbox functionality.

We're using bluebird promises (both for performance and all the extra features), and fetch-ponyfill takes that promise implementation as an option when it's loaded. That implementation all works fine, giving us fetch and Promise working everywhere without touching any globals at all, but we can't easily test it because of this issue.

@wheresrhys Any enthusiasm for reopening this, especially given that you're now looking at supporting the fetch-ponyfill use case?

[wheresrhys]

I'll consider accepting a PR, but don't have any particular enthusiasm for implementing it myself. There are lots of points in the code and the tests where native Promise is assumed, so adding support isn't straightforward and will arguably clutter the code base.

Given that bluebird implements the Promise spec, would it be an option for you to force using native Promise instead of bluebird in your tests?

[pimterry]

Given that bluebird implements the Promise spec, would it be an option for you to force using native Promise instead of bluebird in your tests?

I don't think so, we use bluebird methods (like .timeout) internally, assuming that fetch returns a bluebird promise. We could manually convert it, but with fetch-ponyfill we can guarantee that we don't normally need to at runtime, so it feels messy to have to do that just for the tests.

I've had a look, doesn't seem that tricky I think. I need somewhere to pass in the promise implementation - I'm thinking that actually doing this as part of the sandbox setup is probably sensible, since they're a very similar use case? If you want to do everything with globals you just use fetch-mock as is, if you don't you call sandbox, provide the promises you want locally, and get a working fetch back, with no globals. E.g.

var fetchMock = require('fetch-mock').sandbox({ Promise: bluebirdPromise })

Does that sound ok? I'll put in a PR a little later today if so.

[wheresrhys]

Yep, good call making it part of the sandbox setup. I'd go for just accepting Promise as the first parameter. Less future proof, but more user friendly. I'll probably regret saying this, but I can't see there ever being a need to pass in any other config to sandbox(), or, more seriously, duck-typing coudl be used to deal with that if it ever happens