[BUG][typescript-axios] index.ts: Module "./api" has already exported a member named 'Configuration'

[scscgit]

Bug Report Checklist

• [ ] Have you provided a full/minimal spec to reproduce the issue?
• [x] Have you validated the input using an OpenAPI validator (example)?
• [ ] Have you tested with the latest master to confirm the issue still exists?
• [x] Have you searched for related issues/PRs?
• [x] What's the actual output vs expected output?

Description

In the generated index.ts for typescript-axios, there is always the following content:

export * from "./api";
export * from "./configuration";

When our API includes an interface named Configuration in api.ts, it conflicts with the export of Configuration in configuration.ts. This causes the second line to report error TS2308: Module "./api" has already exported a member named 'Configuration'. Consider explicitly re-exporting to resolve the ambiguity.. There is no way to directly resolve the issue without manually editing the files after each code generation, or without hard-coding custom scripts.

Same applies to api.ts where import { Configuration } from './configuration'; causes error Import declaration conflicts with local declaration of 'Configuration'. ts(2440). Here it also causes conflicts in the code, so we aren't able to just find-and-replace.

openapi-generator version

5.4.0

OpenAPI declaration file content or url

Any yaml with Configuration type, for example having:

    Configuration:
      required:
        - name
        - type
        - value
      type: object
      properties:
        type:
          type: string
        name:
          type: string
        value:
          type: object

under

components:
  schemas:

along with all references: $ref: '#/components/schemas/Configuration'

Generation Details

npx @openapitools/openapi-generator-cli generate -i schemas/configurationapi.yaml -g typescript-axios -o generated/configurationapi --type-mappings DateTime=Date

Steps to reproduce

Perform the generation and build any TypeScript project (for example using Nuxt/Vue template npx create-nuxt-app <project-name>)

Related issues/PRs

No results when searching for the error message.

Suggest a fix

• When there is a naming conflict between exported declarations, the configuration.ts could automatically rename its own exports.
  • Alternatively, at least there should be a way using some CLI parameters to disable the generation of index.ts altogether.
• The api.ts could rename the imported variable using any "reserved" keyword that isn't part of the valid output. For example, something like a leading underscore could be enough: import { Configuration as _Configuration } from './configuration';. This needs to be changed in all occurrences, but without renaming the real Configuration.
  • Is there any reason not to also use the same convention for the exported class?
    • (I don't know this code base, but maybe this can be reused?) https://github.com/OpenAPITools/openapi-generator/blob/683984896e0438762bc97caa43e9cf1eb1860d01/modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/AbstractTypeScriptClientCodegen.java#L314
• The issue could be acknowledged by suggesting an official workaround for CLI automation, so that we don't have to research cross-platform options like npx replace-in-file or a safe file removal.
  • Even though it's relatively feasible to rename $ref: '#/components/schemas/Configuration' using replace-in-file, I can't imagine how to replace the Configuration: without some dedicated YAML parser to avoid risking side-effects.
    • Update: here is a workaround that seems to be sufficient; using /m multiline mode to match $ end of line so that this doesn't have a risk of accidentally replacing any unrelated text content, and using /g global mode to allow replacing multiple occurrences:
      • npx replace-in-file "/ Configuration:$/m" " ConfigurationType:" schemas/configurationapi.yaml --isRegex && npx replace-in-file "/\$ref: '#\/components\/schemas\/Configuration'/g" "$ref: '#/components/schemas/ConfigurationType'" schemas/configurationapi.yaml --isRegex
      • or when escaped as part of npm script: "npx replace-in-file \"/ Configuration:$/m\" \" ConfigurationType:\" schemas/configurationapi.yaml --isRegex && npx replace-in-file \"/\\$ref: '#\\/components\\/schemas\\/Configuration'/g\" \"$ref: '#/components/schemas/ConfigurationType'\" schemas/configurationapi.yaml --isRegex"

[fetis]

still an issue with version 6.0

[hiddenist]

Related: having a parameter named configuration in your api spec generates a conflicting shadowed parameter (as tested in typescript)

{
  "openapi": "3.0.1",
  "info": {
    "title": "ConfigurationBugRepro",
    "version": "v1"
  },
  "paths": {
    "/update-configuration": {
      "post": {
        "operationId": "UpdateConfiguration",
        "parameters": [
          {
            "name": "configuration",
            "in": "query",
            "schema": {
              "type": "string"
            }
          }
        ]
      }
    }
  }
}

/**
 * DefaultApi - functional programming interface
 * @export
 */
export const DefaultApiFp = function(configuration?: Configuration) {
    //                               ^^^^^^^^^^^^^
    const localVarAxiosParamCreator = DefaultApiAxiosParamCreator(configuration)
    return {
        /**
         * 
         * @param {string} [configuration] 
         * @param {*} [options] Override http request option.
         * @throws {RequiredError}
         */
        async updateConfiguration(configuration?: string, options?: AxiosRequestConfig): Promise<(axios?: AxiosInstance, basePath?: string) => AxiosPromise<void>> {
            //                    ^^^^^^^^^^^^^
            const localVarAxiosArgs = await localVarAxiosParamCreator.updateConfiguration(configuration, options);
            return createRequestFunction(localVarAxiosArgs, globalAxios, BASE_PATH, configuration);
            //                                                                      ^^^^^^^^^^^^^
            //                     Passing in a string, but supposed to be of type "Configuration"
        },
    }
};

[rruzicka-inno]

Hi are there any updates on this issue? We are having the same problem and there just isn't a nice fix for this, except for manually changing the Configuration type in the generated file, which is not something we would like to do 😕

[majid-rafei]

As a workaround: There are CLI additional properties "withInterfaces" and "prefixParameterInterfaces" that when are set to true, the interfaces of a service are generated in a separate file with the (service) class name as a prefix of interfaces, hence no conflict with interfaces with the same name in other services! please have a look at this mustache file:

• typescript-angular: https://github.com/OpenAPITools/openapi-generator/blob/2bc0e5f7457615f175ba936a0093f8fc5f7ff1d2/modules/openapi-generator/src/main/resources/typescript-angular/api.service.mustache#L19