Made a sketch for
unmock-fetch, a package that would define a fetch interceptor by overriding
window.fetch and, for Unmock's use, would also export
fetch that would work like
fetch but use Unmock behind the scenes. unmock/unmock-js#312
I think the package could be generally useful in the same way as
node-mitm, so probably the "unmock algorithm" should not be part of the package.
If we go with a package structure like this, I would see additional packages like
unmock-react-native that implements "Backend" with
unmock-fetch as interceptor and
unmock-node doing the same thing with
node-mitm. Also possibly
unmock-types would be needed if
unmock-fetch did not depend on the "core".
I did not yet think about monkey patching XMLHttpRequest, is someone still using that? I also understood that
fetch API is independent of
XMLHttpRequest in modern environments so that
fetch cannot be patched by patching
fetchso one would also need to patch
XMLHttpRequest. But isomorphic fetch packages like "cross-fetch" and "isomorphic-fetch" are very popular as well so we'd cover a lot of ground already by patching
fetch. But yep, I can see us then also releasing
unmock-xml-http-requestthat provides a simple API to intercept and mock XMLHttpRequest. And for example
unmock-browserwould then wrap both
XMLHttpRequestinterceptors as one interceptor.
node-fetchfrom a dependency in
unmock-core(https://github.com/unmock/unmock-js/blob/dev/packages/unmock-core/src/index.ts). I had originally created
unmock-fetchin case we eventually wanted to link testing to production traffic, but no one seems to dig the idea, so it's probably best to just get rid of it. That means that we'll have to update our examples to use
unmock.fetch, but the API is the same.
Added all of your notes about telemetry to the initial doc, thanks!
Also @ksaaskil question for you re: some of our tests. I'm running with this idea of adding more meaningful placeholders and stumbled across this test in the unmock-node package: https://github.com/unmock/unmock-js/blob/dev/packages/unmock-node/src/__tests__/index.test.ts#L38-L44
What is this testing for exactly? I'm trying to think of a better replacement for "foo" (maybe var, data, whatever) but also curious about whether or not we actually need this test.
unmock-serverbranch - it is pretty cool stuff! If the project develops further, I wonder if/when a
libunmockwill be in order? It makes sense to start with NodeJS as that is our most developed library, but at a certain point, having the whole stack in TypeScript seems like a disadvantage if the goal is to deploy it as a stand-alone or embedded entity. I'm wondering how we could test that out 🤔