Added implicit headers property to TypeScriptAxiosClientCodegen

[chrispaynter]

When generating a Typescript Axios client, by default all header params are being added as method parameters for each API endpoint.

This causes a problematic developer experience, as you have to continuously pass through header values that should be able to be configured at the HTTP client level (sdk keys, other special custom headers).

Taking inspiration from the Spring code gen, I've added an implicit headers property to the code gen for Typescript Axios - TypeScriptAxiosClientCodegen.java

The prop can be used as such:

java -jar openapi-generator-cli.jar generate -i swagger.json -g typescript-axios -o dist --additional-properties implicitHeaders=true

I'm not a Java guy, so did my best by following the existing Spring code generator file.

Companion PR to - #11187

@TiFu (2017/07) @taxpon (2017/07) @sebastianhaas (2017/07) @kenisteward (2017/07) @Vrolijkx (2017/09) @macjohnny (2018/01) @topce (2018/10) @akehir (2019/07) @petejohansonxo (2019/11) @amakhrov (2020/02)

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package 
  ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh
  

  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master (5.3.0), 6.0.x
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

[chrispaynter]

A large number of files are changed in the PR after running the above scripts.

The only file I changed was TypeScriptAxiosClientCodegen.java

[amakhrov]

@chrispaynter thanks for you contribution.
Could you please provide some example use case demonstrating what you want to achieve?

[hlascelles]

If it's the same as us, it's that we have this in our OpenAPI definition:

  parameter(
    name: :"User-Agent",
    in: :header,
    required: true,
    schema: {
      type: :string,
    },
    description: "A string that identifies your client to us to aid in development and " \
                 "debugging. It can just be your company name."
  )

But that means all the generated ruby bindings look like this:

    /**
     * Retrieve bar details.
     * @summary Show
     * @param {string} userAgent A string that identifies your client to aid in development and debugging. It can just be your company name.
     * @param {string} id The id for the bar
     * @param {*} [options] Override http request option.
     * @throws {RequiredError}
     * @memberof UsersApi
     */
    public fooBarIdGet(userAgent: string, id: string, options?: any) {
        return ..... <snip>
    }

As you can see, calling the generated Get has 2 mandatory args. Only one of those will ever change. This means that everywhere we want to do a simple get with an id, we have to pass in the (same) userAgent string absolutely everywhere, as it is a mandatory first arg.

I want to do this:

userAgent = "foo"

fooBarIdGet(1)
fooBarIdGet(2)
fooBarIdGet(3)

Not this:

fooBarIdGet("foo", 1)
fooBarIdGet("foo", 2)
fooBarIdGet("foo", 3)

@chrispaynter is that the same as you?

[Daguima-dag]

This means that everywhere we want to do a simple get with an id, we have to pass in the (same) userAgent string absolutely everywhere, as it is a mandatory first arg.

I want to do this:

userAgent = "foo"

fooBarIdGet(1)
fooBarIdGet(2)
fooBarIdGet(3)

Not this:

fooBarIdGet("foo", 1)
fooBarIdGet("foo", 2)
fooBarIdGet("foo", 3)

@chrispaynter is that the same as you?

I agree, that's what I want to do using typescript-axios, the current behaviour is really undesirable. Is there any workaround we can use for now, at least for the Authorization headers?
I'd really prefer using a generated client but not being able to configure auth in a single place is a dealbreaker for me.

[danielkumor]

Like my predecessors, I am eagerly awaiting this change. Is there a chance that this change will be merged?

[wing328]

Like my predecessors, I am eagerly awaiting this change. Is there a chance that this change will be merged?

@danielkumor please file a new one based on this one with resolved merge conflicts. thank you.