Exclude oazapt’s default headers from generated function parameters

[hpohlmeyer]

The docs recommend setting defaults for commonly used parameters.
Unfortunately they are still included in the generated functions, when they are specified in the spec.

Here is an example schema:

{
  "paths": {
    "/user/{id}": {
      "get": {
        "parameters": [
          {
            "schema": {
              "type": "string"
            },
            "in": "path",
            "name": "id",
            "required": true
          },
          {
            "schema": {
              "type": "string"
            },
            "in": "header",
            "name": "x-some-info",
            "required": true
          }
        ],
        // …
      }
    }
  }
}

The x-some-info header is required on the request, which means it should also appear in the schema.
But since I want it on almost every request, I would add it to the oazapfts defaults:

import * as api from "./api.ts";

api.defaults.headers = {
  "x-some-info": "my-info",
};

When I use oazapfts now to generate my api, the resulting function looks like this:

function getUserById(id: string, xSomeInfo: string, opts?: Oazapfts.RequestOpts) {
  // ...
}

This forces me to add xSomeInfo every time, even if I know it will be supplied by the defaults.
It would be nice to pass a list of headers to oazapfts that should be ignored during code generation.

I am thinking of something like

oazapfts --default-headers=x-some-info,x-other-info

or

oazapfts --default-header=x-some-info --default-header=x-other-info

[hpohlmeyer]

I am currently using patch-package to accomplish that and would be happy to open a PR if the flag names are fine with you.

[Xiphe]

Hmm. I understand the problem, thanks for bringing this up!

That said, I'm not entirely sure if it's worth extending the api of this lib for this.
For your case, the defaultHeaders configuration would be sufficient but extending on that thought one might want to filter some other request parameters, too. Maybe also remove some parameters only on specific endpoints. And I don't see us going into that direction.

Without digging really deep into this I'd initially argue that when a header is valid and constant for each method of an API it should not be part of the endpoint-spec but instead part of a global configuration. Meaning, removing the parameter from the spec.

Even for externally provided specs I'd consider adding a "we know better"-pre-processing of the spec before feeding it into oazapfts a pattern I'd favor here.

Let me know what you think