Rhys Evans

Allow 'transparent spy'

1

i.e. fallback to network but don't record calls

Esm 4 realz

3

Waiting for node 14 to be released and gain market share

Inconsistent fallback [to network] logging and behaviour

1

As exemplified by this table | approach | result|appliedLast| |--|--|--| |`catch()` | call logged as `unmatched: true` | yes| |`catch(response)` | call logged as `unmatched: true` | yes| |`fallbackToNetwork: true`|...

Poor experience inspecting based on body

1

these do not work ```js fetchMock.called({body: myObject}) fetchMock.called('*', {body: myObject}) fetchMock.called('*', {body: JSON.stringify(myObject)}) ``` What does? ```js JSON.parse(fetchMock.lastCall('*').options.body) ~= myObject ``` Not a very nice API

TODO - [ ] Tests that methods behave basically the same as existing methods - [ ] Test that inspection based on passing in routes basically works - [ ]...

Next generation route manipulation

2

#460 is about improving the api for naming routes in order to facilitate clearer inspection APIs (#523 #527 #545), with knock on benefits, due to the ease of referencing a...

Might be a more intuitive way to overwriteRoutes to explicitly unmock first then remock after. Could also have a replaceMock() method, or maybe allow a third/fourth parameter to specify that...

e.g. `{begin: 'http://blah', end: '/path'}`

implement easier naming using just a string

1

closes #460

Feedback wanted: Syntactic sugar for naming mocks

2

For advanced matching it's beneficial - for determinism and clarity - to add an explicit name to a route via the options parameter: ```js fetchMock .mock(matcherFunc, 200, {name: 'test1'}) .mock(matcherFunc2,...