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

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.

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 1
Comments: 16 (3 by maintainers)

Most upvoted comments

For anyone who comes across this, I found a workaround. I was having a similar issue with the typescript-axios options: AxiosRequestConfig parameter conflicting with my own options parameter.

Using the --template CLI option , I was able to rename options to _requestOptions in apiInner.mustache. Template docs: https://openapi-generator.tech/docs/templating/

I’m using v5.3.1, YMMV.

Ellfish on Jan 7, 2022

I’m also seeing a similar issue in typescript-axios with a parameter named options conflicting with the options: any = {} that gets generated on all parameter creator functions.

sudall on Jan 8, 2021

Maybe related…

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

vdumitraskovic on Oct 22, 2020

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)

Adelrisk on May 26, 2020

+1 @Ellfish, this solved my problem too. To download the templates locally you can use the following command (just replace typescript-angular with the generator of your choice).

mkdir -p .openapi-generator/templates/ && cd $_
curl -L https://api.github.com/repos/OpenAPITools/openapi-generator/tarball | tar xz
mv `ls`/modules/openapi-generator/src/main/resources/typescript-angular ./typescript-angular
\rm -rf OpenAPITools-openapi-generator-*
cd typescript-angular

JeanMeche on Feb 11, 2022

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

amakhrov on Apr 12, 2020