Typescript-Fetch add option to have parameters put in an Object

[jawa-the-hutt]

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh and ./bin/security/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\.
• Filed the PR against the correct branch: 3.0.0 branch for changes related to OpenAPI spec 3.0. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.
  @TiFu @taxpon @sebastianhaas @kenisteward @Vrolijkx @macjohnny

Description of the PR

Directly address issue: #7595 and provides an example of how to address issue #3620

This PR essentially adds the ability to give you the option to revert to how the Typescript-Fetch client handled parameters in 2.2.3 and below. This was changed in #6130. This PR attempts to arrive at a happy medium that allows a flag to be set on the generator at runtime that will put the parameters back into an Object. As an example:

public createUser(params: { body: User }, options?: any) {
    return UserApiFp(this.configuration).createUser(params, options)(this.fetch, this.basePath);
}

versus what it is now

public createUser(body: User, options?: any) {
    return UserApiFp(this.configuration).createUser(body, options)(this.fetch, this.basePath);
}

This can be useful for a variety of cases, the most common being when you might have several parameters on a class, it would help reduce the amount of code generated.

The other major use case would be to avoid breaking changes with client code already generated in 2.2.3 and below being updated with the new format for parameters in 2.3.0 and above. Developers could now take advantage of fixes and enhancements in 2.3.0 and above without having to worry about changing any downstream code being utilized.

[edvald]

Thanks for pushing this @jawa-the-hutt. Any updates on progress? Having optional parameters in a list of positional arguments is basically a disaster for backwards compatibility in a number of scenarios, so something like this would make the codegen usable again for TS.

[jawa-the-hutt]

@edvald - Will be a 2-3 weeks before I get back on this. I'm leaving tomorrow for a 10 day holiday and then it will take me a few days to get back into this code and figure out what can be done about the concerns you have mentioned.

[agongdai]

@jawa-the-hutt Still going to take care of this PR? I think it's a great feature.

[amakhrov]

Would love to see it shipped!
What does it take to finish this PR?
Looks like the build has failed in CircleCI - but it probably means to need to update from the upstream first (the upstream no longer uses circleci at all!)

[amakhrov]

Looks like typescript support is abandoned here.

openapi-generator seems to be more actively supported.
A similar feature request there is still not resolved, though: OpenAPITools/openapi-generator#865

[ccbrown]

I can confirm that OpenAPITools/openapi-generator does now support this for their typescript-fetch generator. It works great and the generated code is much safer and less of a maintenance nightmare. Since this PR seems to be going nowhere, I would highly recommend anyone using swagger-codegen for Typescript switch to openapi-generator before you learn this lesson the hard way.