Plugin architecture

[wheresrhys]

Following the implementation of user defined matchers I'm now thinking of what would be a good way to allow others to define packages that can be plugged in to fetch-mock. I would really like to put together (or have somebody else put together) a plugin to make dealing with graphql easier

Criteria

1. should be possible to plug in to fetch-mock or fetch-mock-jest
2. maximum of 1 function call for the end user to hook up fetch-mock to the package
3. should support adding other kinds of extensions (e.g. shorthands for preconfigured mocks)

Options

1. exports an extended version of fetch-mock, and is intended to be imported instead of fetch-mock
2. extends fetch-mock, but exports nothing - fetch-mock is still the main thing to be required by the user
3. exports a function which is passed an instance of fetch-mock, and which adds the extensions
4. exports a thing which is passed into a .use() method of fetch-mock

Discussion

1. Struggles to meet criteria 1 (at least, not without being confusing)
2. Lacks transparency over what's going on
3. This delegates definition of patterns to user land - they could call their functions whatever they like, have them meddle with fech-mock in all sorts of unpredictable ways
4. Preferred option at this stage. Gives fetch-mock control over what extensions are added and how to add them, and the user full control over knowing when they've been added

Proposal

Investigate option 4, in particular

1. What does an interface for defining a shortcut method look like
2. What does an interface for defining a new option look like
3. What type of thing should .use() accept