OpenAPITools / OpenAPITools/openapi-generator
[BUG][typescript-fetch] Name convention of generated request type is different from spec file.
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 26.8k
- Forks
- 7.7k
- PR merge metrics
- PR metrics pending
Description
Bug Report Checklist
- Have you provided a full/minimal spec to reproduce the issue?
- Have you validated the input using an OpenAPI validator (example)?
- Have you tested with the latest master to confirm the issue still exists?
- Have you searched for related issues/PRs?
- What's the actual output vs expected output?
- [Optional] Sponsorship to speed up the bug fix or feature request (example)
Description
When I generated typescript-fetch client with YAML file and command below, the code below will be generated.
/* tslint:disable */
/* eslint-disable */
/**
* ts-snake-case-params
* ts-snake-case-params
*
* The version of the OpenAPI document: 0.0.1
*
*
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
* https://openapi-generator.tech
* Do not edit the class manually.
*/
import * as runtime from '../runtime';
export interface TestGetRequest {
pageNum?: number;
}
/**
*
*/
export class DefaultApi extends runtime.BaseAPI {
/**
* description
* summary
*/
async testGetRaw(requestParameters: TestGetRequest): Promise<runtime.ApiResponse<void>> {
const queryParameters: runtime.HTTPQuery = {};
if (requestParameters.pageNum !== undefined) {
queryParameters['page_num'] = requestParameters.pageNum;
}
const headerParameters: runtime.HTTPHeaders = {};
const response = await this.request({
path: `/test`,
method: 'GET',
headers: headerParameters,
query: queryParameters,
});
return new runtime.VoidApiResponse(response);
}
/**
* description
* summary
*/
async testGet(requestParameters: TestGetRequest): Promise<void> {
await this.testGetRaw(requestParameters);
}
}
As you can see, request parameter on spec file is like this.
paths:
/test:
get:
summary: summary
description: description
operationId: testGet
parameters:
- name: page_num
in: query
schema:
type: number
responses:
'200':
description: OK
One of request parameter page_num is snake case.
But request parameter on generated code is camel case.
export interface TestGetRequest {
pageNum?: number;
}
I tried most of option to make name convention of generated code as same as YAML file, but finally I couldn't find such an option...
In my opinion, even if default behavior is like this, there should be option to specify name convention for request parameter.
Because web frontend engineer will see API spec generated from YAML file, but generated client's parameter is different from spec.
It'll be a little bit confusing.
openapi-generator version
v4.3.1 (via Docker image)
OpenAPI declaration file content or url
You can see here
Generation Details
The command I executed is below(Docker command is omitted to simplify command).
Without any config file.
generate -g typescript-fetch \
-pnpmName='${TAG_NAME}' \
-psupportsES6=true \
-ptypescriptThreePlus=true \
-i /local/spec.yml \
-o /local/dist
Steps to reproduce
- Write YAML file and add query request parameter with snake case
- Generate client
that's all
Related issues/PRs
I can't find any related / similar issue.
Suggest a fix
If we want to avoid breaking changes, adding new option to specify naming convention for request parameter is the best way I think.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the linked sandbox spec.yml and reproduce the typescript-fetch generation using the command shown in the issue. Compare the snake_case page_num in the specification with the generated TestGetRequest interface, then trace the naming behavior and determine how an option could preserve the specified parameter name without changing existing defaults.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- openapi, typescript
- Domain
- api, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100