(#3839) - Use lie as promise polyfill everywhere

[daleharvey]

No description provided.

[nolanlawson]

If we're going to do this, then we should also 1) update the documentation that mentions bluebird, and 2) do a similar PR on mapreduce.

[daleharvey]

ok, will take a shot at helping out with #3903 so its easier to switch mapreduce at the same time

[nolanlawson]

I'm also on the fence about whether this should be a breaking change or not. We did document it, so there might be codebases out there that only run in Node and that depend on the Bluebird-specific APIs.

[daleharvey]

Yeh we have only ever documented that we use bluebird and never suggested or documented using its extended functionality plus that would have never works outside node, I would vote to say its an bugfix but not fussy

[nolanlawson]

After some thought, I am -1 on this change, because it doesn't simplify our code much, it might break people's code if they were depending on our (documented!) use of bluebird in Node, and it's just one more thing we have to remember moving forward. Plus bluebird has crazy good debug tools in Node (e.g. logging an uncaught error as a warning), so that may help people out when they are trying to debug PouchDB. (They get that in the browser as well, assuming they are using Chrome, since we default to Chrome native Promises.)

I would also like some input from @calvinmetcalf on this. He has a library called pouchdb-promise which is based on the assumption that we want bluebird in Node and lie everywhere else (the same assumption that a lot of plugins make).

[daleharvey]

We use native promises by default everywhere and in future we will remove both lie and bluebird to just use native Promises, the issue is by using bluebird as a polyfill now we are exposing non standard promises functionality that will work in old versions of node and break in the browser and newer versions of node which is fairly confusing (#3839)

Users still have the option to override native promises and use bluebird in node when they want to but I think this gets us one step closer to using no polyfills which is the ultimate goal, so still think its worth doing so more users dont start using finally etc in their code and get burned when upgrading node.

In general we have tried pretty hard to ensure that any of the exposed API works across all adapters / envs (hence dropping allDbs etc), this seems like a bit of a blemish on that

[nolanlawson]

You make good points. I tend to be really conservative about stuff like this, though, since it could potentially break user code. This definitely needs to be a major version change IMO.

I also think @calvinmetcalf should either deprecate or change pouchdb-promise if we're going to do this, and the hoodies should be notified since they are probably using the extras/promise API. cc @janl @zoepage @gr2m.

[gr2m]

I don't know all details about the upcoming Hoodie server side implementation, but so far we only use the PouchDB Promises in the front-end with browserify. But thanks a lot fro keeping us in the loop

[daleharvey]

ok cool I can live with a major version change, will rerun to make sure nothing has broken since the last test run and get it landed

[daleharvey]

ok, next release is a major bump :) Cheers

09ce6c8

[NickColley]

On top of this: Should we allow users to be able to swap in their own promise implementation? Just thinking if people are depending on bluebird's extra features I'm not sure how they'd easily migrate their code?

[daleharvey]

Yup, people can easily override global.Promise and use whichever implementation they like

[janl]

just to wrap this up: Backend Hoodie doesn’t care either way yet, so all good :)