Some sort of middleware support

[djMax]

Description

The request interception, response interception, etc is quite useful and I wouldn't think would add much to the library. Is there a way to simulate this on top of the library? (I don't see an obvious one)

Proposal

Add a single pre-flight and post-flight hook argument to the methods.

Checklist

• I’m willing to open a PR for this (see CONTRIBUTING.md)

[drwpow]

I like the idea in general. But one difficulty to adding this is the type inference. The library gives you types that 100% match your schema, so any middleware transforms would have to basically not transform your types, otherwise your types are unreliable (if you overrode any response types generated by this library, then I’d argue this library isn’t doing anything for you).

Or should the middleware not be transform-based (and if not, what would be a good example)?

[djMax]

Yeah, it's an interesting question. I'd think some well placed generic type args probably do what's needed, but it's often more about "fetch like things." i.e. we currently do request timing and telemetry, header manipulation, generic retry handling, and oauth retry handling (got a 401 saying token expire? go run this async function and then try again. got a 403? return the error). It very well may be that this can all be done different ways (for example being able to pass in a fetch function), but if that's the case then the feature is examples/docs.

[brandonp-ais]

Just here to say that we use middleware in the same way: for metrics etc., which don't "care" about the types.

Of course it would always be nice to have types available in the middleware, but not imo a hard requirement.

[drwpow]

I still want to track this! But since I’m merging this repo in with openapi-typescript I’ve moved the discussion here.