Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• What's the version of OpenAPI Generator used?
• Have you search for related issues/PRs?
• What's the actual output vs expected output?
• [Optional] Bounty to sponsor the fix (example)

Description

When an API spec contains two similarly named operations that differ only in prefix:

      operationId: tag_new_create
...
      operationId: unit_new_create

then generating the typescript-fetch client with the --remove-operation-id-prefix option will result in an error like:

apis/index.ts:2:1 - error TS2308: Module './TagApi' has already exported a member named 'NewCreateRequest'. Consider explicitly re-exporting to resolve the ambiguity.

openapi-generator version

This is in 4.0.0beta. The same error did not occur with the old 3.x typescript-fetch, though this new implementation is generally much better.

OpenAPI declaration file content or url

https://gist.github.com/bradenmacdonald/061c37b42af22832a14574e4aeaa5c59

Command line used for generation

java -jar openapi-generator-cli-4.0.0-beta.jar generate \
    --input-spec api-spec.yaml \
    --generator-name typescript-fetch \
    --output api_client \
    --config openapi-generator-config.json \
    --remove-operation-id-prefix

Steps to reproduce

Simply generate the typescript-fetch client using the sample gist and the command above, then run cd api_client; npm install; npm run build

Related issues/PRs

I couldn't find any existing reports of this issue.

Suggest a fix

Ideally just never omit the prefixes when generating the request parameter interfaces, so that the interface is still called e.g. TagNewCreateRequest (instead of interface NewCreateRequest) regardless of the --remove-operation-id-prefix option (the main reason I use that option is for nicer method names; the names of the parameter interfaces aren't often used directly so it's fine if they're more verbose).

Alternately, put each module's interfaces into a namespace for that module, so that one must use e.g. TagApi.NewCreateRequest to get the interface after importing the overall API.