Allow onRequest middleware to add headers that the schema requires

[jnatmorris]

To my understanding, if one has multiple protected routes, say /auth/*, which are specified in the schema and require an Authorization header, currently it is required to set the header with each request.

const authRequest1 = await client.GET("/auth/sample1", {
	params: {
		header: {
			authorization: `Bearer ${await someAuthFunc()}`
		}
	}
});

const authRequest2 = await client.GET("/auth/sample2", {
	params: {
		header: {
			authorization: `Bearer ${await someAuthFunc()}`
		}
	}
});

While the current implementation of middleware allows for setting a request header, TS still requires an authorization to be set with each individual request. So doing the following becomes not possible.

import createClient, { type Middleware } from "openapi-fetch";
import type { paths } from "./my-openapi-3-schema";

const authMiddleware: Middleware = {
  async onRequest({ request }) {
    request.headers.set("authorization", `Bearer ${await someAuthFunc()}`);
    return request;
  },
};

const client = createClient<paths>({ baseUrl: "https://myapi.dev/v1/" });
client.use(authMiddleware);

// TS errors as no authorization header is added
const authRequest1 = await client.GET("/auth/sample1");
const authRequest2 = await client.GET("/auth/sample2");

While this does not invalidate many of the use cases for middleware, which are great, this use case would be a welcome addition.

[drwpow]

This is tricky because there’s no way to store that information in a way that’s currently-accessible by the static types. You’ve stated a clear problem that all users of this library have, and would be a good improvement! But your description doesn’t outline enough of a proposal here to describe exactly how to solve this problem. I’d love to see this expanded into more of a complete solution that describes how we could achieve this—how can static typing “peer into” what you have or have not done in middleware?

As an aside, I’ve added a new “openapi-fetch-codegen” label to this issue, because I’m not sure that this would even be possible without having some sort of intermediary codegen step for openapi-fetch. But perhaps it is, and I’m just not thinking of it! Either way, there are a number of related issues that currently don’t have known solutions for. Like everything, it‘s a tradeoff—openapi-fetch relies on no codegen, and some of the absolute fastest performance possible by its design. But this is one of the tradeoffs—repetition in runtime code like this. If users are willing to sacrifice a little more memory usage, and a little more footprint, and a codegen step, we could come up with solutions.