Tests are needed to demonstrate why this feature is needed. I need to know the use case for this to be honest.

Tests are needed to demonstrate why this feature is needed. I need to know the use case for this to be honest.

@bitinn There's a use case explained here: #668 (comment)

Before doing something like this i would want to start on crating a constructor to get a new fetch instance that don't conflict with others middleware hooks

new FetchInstance()

Also useful for using automatic follow redirect but in the end get all the redirect that there were in the middle.
That's the use-case for me.

This is more of hooks and not a middle-ware design. To be honest I don't see a reason why would someone need such things when it comes to sending requests, then comes the after hook which is imo is useless, fetch returns a promise so you already can execute things after fulfilling your request.

I agree with @JefferyHus, and would like to add that I think that global hooks like this are quite messy. If someone uses this to e.g. parse errors returned from an api, it can easy interfere with any other responses being returned from other parts of the code...

Also, should we really add features that aren't present in the official fetch specification? 🤔

Also, should we really add features that aren't present in the official fetch specification? 🤔

@LinusU The main reason why we want to introduce a middleware functionality/hooks is to allow users to set up things like caching/cookies, which are in the spec, but can't be added to node-fetch in an unopinionated way.

We can allow the consumer to specify separate hooks as an option like from got.

@xxczaki thanks for the clarification, I still think that it shouldn't be global though. I think that gots approach is quite good!

@LinusU Yeah, I also really like got hooks and I think we can take some inspiration from them.

This PR have been idle for to long (created 2019) and never merged and perhaps outdated as well?. with some consideration i think FetchEvent #370 is better suited - so closing this...