[BUG] [typescript-fetch] Request Parameter Interfaces Conflict with remove-operation-id-prefix
Created by: bradenmacdonald
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.