Docs: don’t rely on global variable about isomorphic-fetch

[matthew-andrews]

I've written up some notes on this here:-
#31 (comment)

The goal of this module is to provide the same API on the client as is provided on the server — it does that at the moment by defining fetch globally that's how I would like to encourage this library to be used (this is how the client side version of fetch works — and that's the API we're trying imitate here). If developers care about what's being defined globally I think they should just use node-fetch directly…

[gajus]

The goal of this module is to provide the same API on the client as is provided on the server — it does that at the moment by defining fetch globally that's how I would like to encourage this library to be used (this is how the client side version of fetch works — and that's the API we're trying imitate here). If developers care about what's being defined globally I think they should just use node-fetch directly…

No library should write anything into a global state. This is in effect memory leaking. There is no way to dereference use of isomorphic-fetch after importing it. (Other than looking into the source code to tell which global variables you set.)

Conceptual principals aside, this is just bad design. In Node.js, you are promoting use of global variables. In Browser, you are tricking the environment to think that fetch is present. This would break an application that preforms feature checking to plan progressive enhancement.

On the bright side, you did address this in the documentation and suggested an alternative. Thumbs up for that. 👍

For ease-of-maintenance and backward-compatibility reasons, this library will always be a polyfill. As a "safe" alternative, which does not modify the global, consider fetch-ponyfill.