Add unmock-fetch.

[ksaaskil]

• Adds unmock-fetch package for intercepting calls to global.fetch or window.fetch
• Also provides buildFetch that takes in a callback function of type OnSerializedRequest
• Used either via const fetch = buildFetch(onSerializedRequest) or with UnmockFetch.on(onSerializedRequest); ... UnmockFetch.off();. The latter patches global.fetch or window.fetch.
• Move OnSerializedRequest to interfaces.ts in unmock-core so it can imported

TODO:

• Get rid of hackish imports from unmock-core/dist/interfaces. Importing from unmock-core is not possible at the moment as it imports a lot of Node.js related stuff and that would break in React Native

[codecov-io]

Codecov Report

❗ No coverage uploaded for pull request base (dev@1e07444). Click here to learn what that means.
The diff coverage is 90.62%.

@@          Coverage Diff           @@
##             dev     #312   +/-   ##
======================================
  Coverage       ?   84.95%           
======================================
  Files          ?       55           
  Lines          ?     2220           
  Branches       ?      564           
======================================
  Hits           ?     1886           
  Misses         ?      334           
  Partials       ?        0

Impacted Files	Coverage Δ
packages/unmock-core/src/interfaces.ts	100% <ø> (ø)
packages/unmock-core/src/backend/index.ts	84.31% <ø> (ø)
packages/unmock-fetch/src/types.ts	100% <100%> (ø)
packages/unmock-fetch/src/fetch.ts	100% <100%> (ø)
packages/unmock-fetch/src/serialize.ts	85.71% <85.71%> (ø)
packages/unmock-fetch/src/index.ts	87.5% <87.5%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1e07444...4b8ec14. Read the comment docs.

[idantene]

Looks good;

Just out of curiosity - couldn't we have used cross-fetch immediately instead of fetch?

[idantene]

Should debug and its @types be part of the dependencies? (and not dev dependencies?)

[ksaaskil]

Yes, a library should include the types it uses.

[idantene]

Of course, but debug is not a dependency. The code doesn't need it to function properly, so shouldn't it be part of dev dependencies?

[ksaaskil]

But debug is a dependency of unmock-fetch :) It's true that user's type-checking probably would pass fine even if @types/debug wasn't part of the dependencies, but I think it's generally just bad practice to leave out the types. We've had two breakages in releases already because of leaving out types for sinon and node-fetch, requiring users to manually add the types.

[idantene]

Is this the same mitm we have in the backend?

[ksaaskil]

No, the Mitm is a new class defined in the same file.

[idantene]

I see that, but it seems you tried to maintain the same interface, hence the question. It's a bit misleading IMO to have two Mitm classes with different purposes.

[ksaaskil]

Yeah I can rename it if it makes development simpler for us. But in general users of this would not know anything about node-mitm and its API so I just picked a short name that makes it clear what it does. I can call it FetchInterceptor or something.

[ksaaskil]

Hmm, I don't see what you mean by "couldn't we have used cross-fetch"? Do you mean patching crossFetch.fetch instead of patching global.fetch or window.fetch? I tried something like that but could not figure out how to actually do it.

[ksaaskil]

Or if you mean the unmock.fetch included in the package export, it would indeed probably be better if it was indeed set to cross-fetch instead of node-fetch.

[idantene]

Or if you mean the unmock.fetch included in the package export, it would indeed probably be better if it was indeed set to cross-fetch instead of node-fetch.

Yup, meant this :)