I'm in the process of moving a project to ESM, and as a part of that I'm now able to move to node-fetch V3 (as it's ESM only).
V3 also brings behavioural changes to make it more spec compliant - a notable one being that body parse failures now return SyntaxError instead of FetchError. As the latest cross-fetch version still depends on node-fetch V2 (presumably for CJS compatibility - which I understand), this means that the behaviour of our tests won't match what will happen in production.
As a flexible (yet hopefully simple to implement) solution, could we add an optional 2nd argument to createFetchMocker called something like overrides, that would be an object optionally containing fetch, Response, Headers and Request (all the values that createFetchMocker uses from cross-fetch)?
This would allow someone to pass whatever fetch implementation they want, which could be node-fetch V3, or thinking to the future, the built-in fetch values that are now a part of Node and are stable in Node 22.
I'm in the process of moving a project to ESM, and as a part of that I'm now able to move to
node-fetch
V3 (as it's ESM only).V3 also brings behavioural changes to make it more spec compliant - a notable one being that body parse failures now return
SyntaxError
instead ofFetchError
. As the latestcross-fetch
version still depends onnode-fetch
V2 (presumably for CJS compatibility - which I understand), this means that the behaviour of our tests won't match what will happen in production.As a flexible (yet hopefully simple to implement) solution, could we add an optional 2nd argument to
createFetchMocker
called something likeoverrides
, that would be an object optionally containingfetch
,Response
,Headers
andRequest
(all the values thatcreateFetchMocker
uses fromcross-fetch
)?This would allow someone to pass whatever
fetch
implementation they want, which could benode-fetch
V3, or thinking to the future, the built-infetch
values that are now a part of Node and are stable in Node 22.