Document how to use in Browserify about fetch

[matthew-andrews]

A reduced example of how to use Browserify with fetch loaded via npm:-
https://github.com/matthew-andrews/fetch-browserify-demo

And another with fetch loaded via bower (and debowerify):-
https://github.com/matthew-andrews/fetch-browserify-bower-demo

[dgraham]

@matthew-andrews This is great. Could you create a pull request for the fetch readme that links to your examples with a little context around it? Maybe a "Using with npm" section.

[matthew-andrews]

Yup, sure — just wanted to get them working first.

[jacobrask]

If I understand correctly, using it with browserify will still expose it as a global. What I am concerned about is: I ship some software with github/fetch, the WHATWG Fetch API is changed, and then implemented in a browser.

Problem: if (window.fetch) return makes my code use the native API, which is not compatible with the code I wrote.
Preferred: My code uses the version of github/fetch I had downloaded, and continues to work until I can update it to the new API. When the API is implemented in my target browsers, I can just remove my require.

Am I missing some way of accomplishing this, or are they invalid concerns for some other reason?

[matthew-andrews]

That's a very valid point and no I don't think there's any way of accomplishing this without maintaining a fork.

I had similar feedback for https://github.com/matthew-andrews/Promise.prototype.finally, which was “if you modify the global, you'll make it harder for it to become a standard method”. I argued against it at the time: https://twitter.com/andrewsmatt/status/520987196757934080 but now I'm not so sure.

Fetch API has sort of already been implemented in browsers — although admittedly I've only seen this behind a flag in Chrome, and only via Service Workers so maybe that doesn't count.

[josh]

@jacobrask since the entire spec is very alpha right now, I would suggest you just not use this library until things settle down.

[josh]

Resolved by #29