Openapi-generator: [BUG][Typescript] Incorrect types generated due to case/naming differences

[affanshahid]

I have a schema, which types such as:

This generates a typescript interface like:

/**
 * 
 * @export
 * @interface VDN
 */
export interface VDN {
    /**
     * 
     * @type {string}
     * @memberof VDN
     */
    vdnExtension?: string;
    /**
     * 
     * @type {string}
     * @memberof VDN
     */
    vdnName?: string;
    /**
     * 
     * @type {Array<string>}
     * @memberof VDN
     */
    skills?: Array<string>;
    /**
     * 
     * @type {number}
     * @memberof VDN
     */
    acdEngineId?: number;
    /**
     * 
     * @type {number}
     * @memberof VDN
     */
    lobId?: number;
    /**
     * 
     * @type {string}
     * @memberof VDN
     */
    lobName?: string;
    /**
     * 
     * @type {string}
     * @memberof VDN
     */
    programId?: string;
}

The structure is technically correct, even the property names have been converted from snake-case to camelCase. However this is just for the type, when I actually use the generated client, the property names are same as the original, so really the converted property names in the response are all undefined. Am I doing something wrong?

Generator: typescript-axios
OpenAPI-Generator version: 0.0.11-4.0.0-beta3

[macjohnny]

@ affanshahid which backend do you use? did you inspect the response?

[affanshahid]

I'm using node.js, i did inspect the response. For example: lobId was undefined and lob_id had the value

[dbusacca]

I've got the same issue using Swagger OAS 3 and Jersey as backend

[macjohnny]

there is a configuration option modelPropertyNaming, which could be set to snake_case. This might solve your issue. See https://openapi-generator.tech/docs/generators/typescript-axios

[dkushner]

@macjohnny: This seems kind of counter-intuitive. If I'm dictating the casing of the properties in my generated models, the code generator should be capable of mapping the OpenAPI properties to the generated ones, no?

[affanshahid]

Completely agree @dkushner. The generator should perhaps be able to map properties to the required case?

[macjohnny]

the naming strategy of the backend and frontend generated code should be the same, otherwise it can't match.
the client does not do any conversion but simply maps a field received from the backend to a field with the very same name in the frontend.

[msegers]

I've encountered the same behaviour with a spring boot backend, we had one property in our yml files where the property name was snake case e.g. some_var.

In the TS code it's converted to someVar but the backend still uses some_var.

I looked through our project, we don't have any config files :-).

[macjohnny]

@msegers you can pass config options --additional-properties e.g. like this:

openapi-generator generate -i api-definition.yml -g typescript-angular -o frontend-client --additional-properties=npmName=demo-api,npmVersion=1.2.3

[msegers]

Thanks for the response, no way to have a file? Because I don't want a team member to forget to apply a config option or make a typo, nor change the current jenkins configs.

That said, this bug should just be resolved, we can work around it by changing the param in our yml for now, but it seems like this could be a real nuisance for others :-).

[macjohnny]

@msegers the configuration options can also be put in a file and passed with -c my-config.json. Or you could add them to the pom.xml if you use the maven plugin to generate the code.

[JasonBristol]

I have also encountered this issue using the typescript-rxjs generator. While adjusting the property naming to snake case resolves the issue, it poses a problem for those of us trying to conform to typescript naming conventions

[Hardtack]

@macjohnny

OpenAPI spec itself should be independent of the implementations. But, according to your comment, You seem like to say the schema definition in OpenAPI can be override by the implementation.

In this case of issue, @affanshahid defined a schema with _snake_case_ naming. But, If someone implement server / client with _camelCase_ naming, the definition of schema be overridden by implementation.

This is so unintuitive.
In my case, I implemented my server with OpenAPI spec without any generator, and used _snake_case_ as written in my OpenAPI spec. And I implemented my client with _openapi-generator_ with _camelCase_ naming, which is default, and it did not convert the naming of properties. I think, no one expect this kind of implementation from generated code.

IMHO, if you want to add an option for naming property, you should implement the converter. Or, we should remove this option if don't want to implement the converter.

[amakhrov]

@Hardtack that's totally correct.
The existing behavior is clearly a bug - it should use "original" by default, while currently it's set to "camelCase".

Note, however, that a few typescript generators (e.g. typescript-fetch) implement runtime conversion between the generated property names and the original names as per spec. For them it's totally ok to produce property names different from the spec.

The plan is to clean this up and set proper defaults to each typescript generator