Generated client with typescript-fetch generator is very different from swagger-codegen-2.2.3

[megaboich]

The problem: When using latest openapi-generator there is a lot of differences in generated client codebase.

We have quite a big code base generated automatically using swagger-codegen-2.2.3. There are some 35 of different REST controllers and we have build automation script that generates typescript-fetch API clients for them during the build process and in general it works very well and everyone is happy.

But I think in version 3 of swagger codegen there were introduced lots of changes.
The most annoying change is switching from object-structured parameters to plain parameters.
Compare this code which invokes generated api:
Before

    await this.api.getWorkspacePermissions({
        authorization: this.apiHelper.authToken,
        workspaceId: workspaceId
    })

After

    await this.api.getWorkspacePermissions(this.apiHelper.authToken, workspaceId)

I do not like that names of parameters are not presented now. In some cases we have lots of string parameters and here I see several disadvantages in this approach:

1. When I do not see the names then it is not readable anymore.
2. Error could be easily added when I put them in wrong order.
3. Also if someone at backend decide to change parameter name and order (like remove something called projectId and add different required parameter called parentObjectId) then new generated client will still be compatible because there is just a bunch of string parameters in API call without information about the name.

Any ideas why this change was introduced? Probably I just do not see the benefits from it?

[macjohnny]

@megaboich I agree this change caused issues for quite some people, see swagger-api/swagger-codegen#7595

Maybe @jawa-the-hutt would like to port swagger-api/swagger-codegen#7930 to OpenAPI Generator? Having an option would allow to choose and therefore to fit both approaches.
This could also be extended to all typescript-based generators, maybe @TiFu would like to consider this when reworking the typescript generators?

[Place1]

I've created a fork of the typescript-fetch generator over at https://github.com/Place1/swagger-codegen-typescript-browser

I'd be very interested in using it as the foundation for a rework of typescript-fetch over here. It follows the params object as api method argument and fixes a bunch of other issues present in the generator related to form data and model naming conversions (camelCase), additionally, it supports middleware.

[macjohnny]

@Place1 thanks for sharing!
@TiFu could you have a look at this?

[TiFu]

Ah that's a very good idea. I'll look into it.

I didn't have any time to start working on it yet (due to another project running sideways) but my schedule should become more relaxed now.

[macjohnny]

@TiFu if the parameters of the api methods are to be combined into a single object (maybe as an option), swagger-api/swagger-codegen#8435 of @sschoeb could also be considered. maybe @sschoeb would want to help?

[aaronbeall]

Where can I find documentation on the template variables that swagger-codegen produces in the latest version? We are using a custom template based on TypeScript-Fetch (in order to fix/modify some things about it) and similar to the OP after trying to upgrade I found that the differences are quite substantial...

[TiFu]

I'm not sure if there's documentation for it, but you can print the available template variables. See
https://github.com/openapitools/openapi-generator/wiki/Mustache-Template-Variables for more information. If you search the code base for debugOperations you can also find the other debug switches.

[macjohnny]

with #3351 by @JFCote one can choose the method signature style.