Export fetch function

Exporting the fetch function through module.exports would allow me to use the polyfill instead of buggy browser implementations. For example, current Chrome Canary incorrectly throws on 504 response, without any sensible way of detecting the cause of error in the catch handler.

[bamsebjrn]

excitera me sir but what? im jusing tor o chrome

Skickat från min iPhone

8 aug. 2018 kl. 09:19 skrev Jarek Rencz <[e-mail]:[e-mail]>:

@mislavhttps://github.com/mislav thanks for a hint 😃

Any faulty browser implementation of fetch is that browser vendor’s problem and should be taken with them.

To a certain extent it’s not always on the browser vendor’s side. E.g.: In a project of mine, where I use fetchI experience a strange behaviour in Firefox <54 where using native fetch it produces POST requests without payload. I was able to reproduce it with 1/500-1000 ratio but I see it in production so it’s a fact.

Enforcing polyfill allows me to make my app usable for such users (those are mostly Firefox 52 users)

And now to the point: Firefox 52 is the last one on Win XP and Win Vista. I don’t have a comfort of telling my users to update their PCs’ OS just because at some point Mozilla did something bad in fetch implementation and then they fixed it (to my best knowledge either silently or accidentally because I found no bug report about such behaviour in Bugzilla)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/github/fetch/issues/180#issuecomment-411311099, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AoPVRO_Qst3Il-tU9tCvRCIkVLxcnGCDks5uOpD2gaJpZM4Fblbf.

[mislav]

@jpochyla Here is how to force the polyfill.

<script>window.fetch = undefined</script>
<script src=fetch.js></script>

@runn1ng We don’t feel that a module pattern is worth maintaining for this simple polyfill. Any faulty browser implementation of fetch is that browser vendor’s problem and should be taken with them.