Openapi-generator: [BUG] Params named "default" get replaced with "_default", resulting in incompatible clients

[seanlaff]

Description

My api has a request object that contains a key called default, however when I generate client code from this spec, it gets converted to _default. Since my api expects default, the generated client code does not work.

I'm guessing this is escaping that happens in java since default is a java keyword. Is there any way around this?

Expected generated:

export interface RbacAddRoleRequest {
    default?: boolean;

Actual generated:

export interface RbacAddRoleRequest {
    _default?: boolean;

openapi-generator version

4.0.0

OpenAPI declaration file content or url

https://gist.github.com/seanlaff/d2aef0244adeeea95c1396952b28d987

Command line used for generation

docker run --rm -v ${PWD}:/local openapitools/openapi-generator-cli:v4.0.0-beta generate \
    -i /local/test.yaml \
    -g typescript-axios \
    -o /local/out/ts

[auto-labeler[bot]]

👍 Thanks for opening this issue!
🏷 I have applied any labels matching special text in your issue.

The team will review the labels and make any necessary changes.

[jmini]

related issue: #13 - even in java there is some problem with the "default" keyword.

[wing328]

@seanlaff have you tried the modelPropertyNaming option?

        Naming convention for the property: 'camelCase', 'PascalCase', 'snake_case' and 'original', which keeps the original name (Default: camelCase)

[seanlaff]

@wing328 The original option does not prevent the underscore prefix

How I tried:

docker run --rm -v ${PWD}:/local openapitools/openapi-generator-cli:v4.0.0-beta generate \
    -i /local/test.yaml \
    -g typescript-axios \
    -o /local/out/ts \
    -DmodelPropertyNaming=original

[fgravin]

Hi, same with abstract that is renamed to _abstract in Typescript.

[jmini]

Are default and abstract reserved keyword in typescript?

If not, we should have a look where the list is defined and move java-related stuff only in the java generator part.

[eseliger]

they are keywords, but can be used for property names, function names and variables 🤔

maybe it makes sense looking at all cases where they are used in templates and see if it's safe to remove some keywords from the list

[wpatter6]

@eseliger Will this fix apply to all typescript clients or just typescript-angular? And will it apply to all prefixed properties, or just the ones listed here? I've encountered an issue with the long keyword being prefixed as _long as well, using the typescript-axios client generator.

[eseliger]

this would be for all typescript clients, but it needs more investigation if that won't break with some dialects ... Since in object property names much more keywords are allowed than for function names for example. Unfortunately, I'm really busy these weeks and won't be able to continue the work on the generator. I hope I can find some spare time end of this month

[ffMathy]

@eseliger Will this fix apply to all typescript clients or just typescript-angular? And will it apply to all prefixed properties, or just the ones listed here? I've encountered an issue with the long keyword being prefixed as _long as well, using the typescript-axios client generator.

I'm hitting this exact scenario as well.

The weird part is that changing it from _long to long manually in the generated .d.ts file does not cause a compilation error - so why is this library preventing keyword usage?

I think it is allowed as properties for interfaces, so I don't know why we are trying to prevent that.

Also, if it isn't allowed, can't we use square bracket notation?

E.g.:

interface Foo {
    ["long"]: number;
}

[jfsiii]

One more data point. I found this when looking into why typescript-node & -fetch switched package to _package for interface class properties

[seanlaff]

I use a dirty sed to get around this for now gsed -i 's/_default?:/default?:/' src/models/*;