Openapi-generator: [typescript-angular] Bug - Parameters named "responseType" cause conflict.

[SandroBuerki]

Description

If you name a parameter responseType (or response_type etc.) the generated client method signature expects a parameter called responseType. However, the generated code of such method declares a variable responseType, which causes the compiler to throw the error message Duplicate identifier 'responseType'.

Method signature:
public authorize(responseType?: 'code', state?: string, observe: any = 'body', reportProgress: boolean = false, options?: {httpHeaderAccept?: undefined}): Observable<any> {

Variable declaration:
let responseType: 'text' | 'json' = 'json';

openapi-generator version

v4.3.0 - It jused to work with v4.2.3

OpenAPI declaration file content or url

swagger.json

{
  "swagger": "2.0",
  "info": {
    "title": "Example swagger",
    "description": "Example description",
    "version": "1.0.0"
  },
  "paths": {
    "\/oauth\/auth": {
      "get": {
        "operationId": "authorize",
        "parameters": [
          {
            "name": "response_type",
            "in": "query",
            "type": "string",
            "enum": [
              "code"
            ]
          }
        ],
        "responses": {
          "302": {
            "description": "Redirection to Authentication flow or straight to the redirect_uri if the authentication has been completed before"
          }
        }
      }
    }
  }
}

Command line used for generation

docker run --rm -v ${PWD}:/local openapitools/openapi-generator-cli generate \
-i /local/swagger.json \
-g typescript-angular \
-o /local/out \
--additional-properties modelPropertyNaming=original,ngVersion=9.0.0,npmVersion=1.0.0,npmName=@package/scope,npmRepository=https://gitlab.com/api/v4/projects/123/packages/npm/

Steps to reproduce

• Create a swagger.json with the content as shown above
• Execute the command as shown above
• See the method signature of authenticate() generated in out/api/oAuth.service.ts

Related issues/PRs

No similar issues, but the PR which changed the behavior. It swapped the logic of toVarName() and toParamName(): https://github.com/OpenAPITools/openapi-generator/pull/5427

Suggest a fix/enhancement

With 4.2.3, the method parameter kept its case. Due to a change in 4.3.0, all parameters are now camelized. I could probably fix the code myself, and I'm willing to open a PR. I'm just not sure what you guys think the best way would be:

• Should modelPropertyNaming affect the parameter name?
• Should I add responseType as a reserved word?
• Should I just rename the responseType variable inside the generated function?
• Or am I completely wrong and something else is needed?

Best regards, and thanks a lot in advance.

[auto-labeler[bot]]

👍 Thanks for opening this issue!
🏷 I have applied any labels matching special text in your issue.

The team will review the labels and make any necessary changes.

[FaKeller]

We have also stumbled into this issue and would be glad if this could be resolved. We have a parameter named response_type in our API definition.

[amakhrov]

Thanks for the detailed problem description and the suggestions!

Should modelPropertyNaming affect the parameter name?

I think that the conflict is possible regardless on that. Even if we do not camelize the param name in the generator, it's still possible that the api-spec itself has the name in camel case that matches exactly the local variable name.

Should I add responseType as a reserved word?

This would probably do the trick. I see that AbstractTypeScriptClientCodegen already lists a couple of such local variable names as reserved: https://github.com/OpenAPITools/openapi-generator/blob/e82546f342dc62f11c4afdb2a84ca9b1c96263ea/modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/AbstractTypeScriptClientCodegen.java#L116-L117

Looks like each individual typescript generator (Angular, Fetch, etc) should add to this list its own set of local var names specific to that generator's templates

Should I just rename the responseType variable inside the generated function?

Can fix your particular case, but still has a conflict potential with other api specs that can define arbitrary param names

[Adelrisk]

Should I add responseType as a reserved word?

This would probably do the trick. I see that AbstractTypeScriptClientCodegen already lists a couple of such local variable names as reserved:

I'd be interested to know if this can be achieved as an "end user" of this plugin/tool. Is there any way to configure this without forking and re-publishing code?

The query parameter response_type is a required query parameter of oauth 2.0, so dealing with this is more than a "nice to have": https://tools.ietf.org/html/rfc6749#section-3.1.1

The current workaround is to downgrade to 4.2.3 and set modelPropertyNaming to original. (Thanks to @SandroBuerki)

[orosro]

I'm encountering the same issue using @latest version (4.3.x I think). In any case, setting modelPropertyNaming=snake_case was not working. Same scenario, required param of oAuth2.

I used the same workaround as the others, downgrading to 4.2.3 and setting the modelPropertyNaming to original.

Any updates? A lot of time passed

[vdumitraskovic]

Maybe related...

Using a typescript-axios generator on a parameter named query is generating duplicate identifier. ATM I don't know any workarounds.

[jk89]

+1 seeing this issue in all modern versions of openapi cli. The only working version for me on npm is "1.0.18-4.2.3" with additional properties of "supportsES6=true", "withInterfaces=true", "modelPropertyNaming=original", "useSingleRequestParameter=true". Unfortunately this version is not capable of making an api.module.ts compatible with angular version 10.x.x. due to ModuleWithProviders needing to be post typed. Meaning the the workaround is no longer viable!

So anyone who has an angular 10+ project and wants a client for a service which implements oauth2 will not be able to use the cli tool at all.

Can the client not just have some prefix for internal variable to avoid collision in the namespace of parameters? Or some other simple defensive technique? Its comes across as very strange that this is such a systemic issue.

I also see other issues with:
error TS2552: Cannot find name 'queryParameters'. Did you mean 'VREyeParameters'
where i have an authentication type api_key query parameter apiKey:
"type": "apiKey",
"scheme": "apiKey",
"name": "api_key",
"in": "query"

So if i have a route with no query parameters but a security query parameter the codegen tool does not create the QueryParameter variable and it end up confused looking for VREyeParameters.