Vendor whatwg-fetch #295
Vendor whatwg-fetch #295
Conversation
Pretender uses the `whatwg-fetch` package in order to intercept `fetch` calls. However, Pretender relies implicitly on `whatwg-fetch` internals to get the `fetch` intercepting behavior working correctly. This starting causing some problems in some systems where the `whatwg-fetch` package was swapped or removed altogether, since the package is indeed a polyfill and the system determined the behavior was present and thus the polyfill wasn't needed. However, because Pretender actually relied not only on the polyfill behavior but also internal implementation details, Pretender would break in these systems. More details: The `fetch` implementation that `whatwg-fetch` provides actually delegates to `window.XMLHTTPRequest` under the hood. Since Pretender _also_ monkey patches `window.XMLHTTPRequest`, it is able to intercept `fetch` calls equally as well. But it's only due to those internals – due to the fact that the `whatwg-fetch` polyfill happens to use XMLHTTPRequest under the hood. This is not part of `whatwg-fetch`'s public API, even though it is unlikely the change. Since Pretender has been relying on observable but undocumented behavior of `whatwg-fetch`, this commit vendors the package, ensuring that `whatwg-fetch` can no longer be treated as an external dependency and hoisted or replaced.
|
Once we merge this I will make a new PR that will supercede #269. It will be easy for us now to ensure Pretender is importable in node since we have whatwg-fetch vendored – we can just wrap the module in an |
|
@xg-wang could I get your review on this? |
| @@ -1,5 +1,5 @@ | |||
| import FakeXMLHttpRequest from 'fake-xml-http-request'; | |||
| import * as FakeFetch from 'whatwg-fetch'; | |||
| import * as FakeFetch from './whatwg-fetch'; | |||
There was a problem hiding this comment.
You do not need to copy the whole file, external: Object.keys(pkg.dependencies), in rollup config is treating whatwg-fetch as external module, when you remove it from pkg.dependencies it will be imported by rollup.
You will still need whatwg-fetch in dev dependencies to let rollup find the file.
There was a problem hiding this comment.
Yah. But it would make the next step easier since we can wrap it in a check to see if window exists. Otherwise we’ll need to do what I did in the other PR and bring in cross fetch, I think.
|
Closed by #296 |
Closes #293
Pretender uses the
whatwg-fetchpackage in order to interceptfetchcalls. However, Pretender relies implicitly onwhatwg-fetchinternals to get thefetchintercepting behavior working correctly.This starting causing some problems in some systems where the
whatwg-fetchpackage was swapped or removed altogether, since the package is indeed a polyfill and the system determined the behavior was present and thus the polyfill wasn't needed. However, because Pretender actually relied not only on the polyfill behavior but also internal implementation details, Pretender would break in these systems.More details: The
fetchimplementation thatwhatwg-fetchprovides actually delegates towindow.XMLHTTPRequestunder the hood. Since Pretender also monkey patcheswindow.XMLHTTPRequest, it is able to interceptfetchcalls equally as well. But it's only due to those internals – due to the fact that thewhatwg-fetchpolyfill happens to use XMLHTTPRequest under the hood. This is not part ofwhatwg-fetch's public API, even though it is unlikely the change.Since Pretender has been relying on observable but undocumented behavior of
whatwg-fetch, this commit vendors the package, ensuring thatwhatwg-fetchcan no longer be treated as an external dependency and hoisted or replaced.