[typescript] Append enum suffix without model suffix

[amakhrov]

Fixes#5135

I was not able to approach this problem without introducing backward-incompatible changes.
A new enumSuffix option is introduced to minimize migration efforts, though.
UPDATE: actually, backward compatibility is now ensured by having v4-compat value by default for the newly introduced option

• (breaking change) With modelNameSuffix, only append "Enum" suffix but not model suffix. So instead of ResponseModelPropNameModelEnum we now get ResponseModelPropNameEnum.
• Without modelNameSuffix, all typescript generators except typescript-angular keep the existing behavior (emit smth like ResponsePropNameEnum)
• (breaking change) typescript-angular now follows the same enum naming rules as other TS generators. It still uses its custom modelSuffix, though - so it's still possible to configure it via modelNameSuffix or modelSuffix. Both options should work the same with the updated enum naming schema.
• enumSuffix is now configurable via options. This would provide smoother migration for existing users (e.g. one can set it to "ModelEnum" to mimic the old behavior).
• (bonus) More robust model names generation. Previously it would be possible to have a spec with a model named error (note lowcase!), which would then emit a Typescript interface Error. This should not have been possible, because Error is a builtin class. Now all the sanity checks are done to a fully-transformed model (after being camelized, and adding prefix and suffix). This addresses a part of the problem described in [BUG][typescript] Models named after language-specific types generate incorrectly #5139)

PR checklist

• Read the contribution guidelines.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

@TiFu@taxpon@sebastianhaas@kenisteward@Vrolijkx@macjohnny@nicokoenig@topce@akehir@petejohansonxo

[auto-labeler]

👍 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.

[amakhrov]

This is a mapping for the OAS2 built-in file type. It's similar to the existing mapping defined in TypeScriptAngularClientCodegen.java:

typeMapping.put("file", "Blob");

Without that, the updated toModelName() logic would add a bogus import for api endpoints that deal with type:file (imageUpload endpoint in PetStore)

Frankly, I'm not sure if the old mapping in line 151 here is needed at all.

[macjohnny]

@amakhrov Thanks a lot for your PR.
If I understand it correctly, the problem is not a bug itself, but rather a naming inconvenience?

[amakhrov]

@macjohnny i guess it depends on a point of view.
I consider it a bug, because it makes modelSuffix rather unusable in typescript-angular, resulting in enum names that are called Models (assuming Model is the suffix used).

However, one can argue that since generator still emits some valid typescript, it's not a bug but a feature.

If you think it's rather a feature than a bugfix - do you think it's still valuable to be merged into the next major version?

[amakhrov]

Thinking further about introducing backward incompatible changes.... Perhaps there is a way to keep compatibility by introducing a special v4-compat value of this new enumNameSuffix option, and making it a default. This value will enforce the existing behavior for all generators. This value can then be removed in the major release if needed.
Any thoughts?

[macjohnny]

@amakhrov I think it is a good idea to have a backwards-compatible behavior by default, so we can merge it and include it in the next patch release

[macjohnny]

concerning bug or feature, since the code compiles as it is generated now, i would consider it a feature/improvement of the naming, which is, of course, favorable, too.

[amakhrov]

All right, so I'll make the change described (introduce a special v4-compat value for this option), and update the PR - all tomorrow (it's past midnight over here already)

[macjohnny]

LGTM

[florianstuerzlinger]

Is it possible to not add a suffix to enums?
i tried calling the generator with an empty parameter -
This leads to the suffix "False". Any solution for this?

[amakhrov]

Fixes#5135

I was not able to approach this problem without introducing backward-incompatible changes.
A new enumSuffix option is introduced to minimize migration efforts, though.
UPDATE: actually, backward compatibility is now ensured by having v4-compat value by default for the newly introduced option

• (breaking change) With modelNameSuffix, only append "Enum" suffix but not model suffix. So instead of ResponseModelPropNameModelEnum we now get ResponseModelPropNameEnum.
• Without modelNameSuffix, all typescript generators except typescript-angular keep the existing behavior (emit smth like ResponsePropNameEnum)
• (breaking change) typescript-angular now follows the same enum naming rules as other TS generators. It still uses its custom modelSuffix, though - so it's still possible to configure it via modelNameSuffix or modelSuffix. Both options should work the same with the updated enum naming schema.
• enumSuffix is now configurable via options. This would provide smoother migration for existing users (e.g. one can set it to "ModelEnum" to mimic the old behavior).
• (bonus) More robust model names generation. Previously it would be possible to have a spec with a model named error (note lowcase!), which would then emit a Typescript interface Error. This should not have been possible, because Error is a builtin class. Now all the sanity checks are done to a fully-transformed model (after being camelized, and adding prefix and suffix). This addresses a part of the problem described in [BUG][typescript] Models named after language-specific types generate incorrectly #5139)

PR checklist

• Read the contribution guidelines.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

@TiFu@taxpon@sebastianhaas@kenisteward@Vrolijkx@macjohnny@nicokoenig@topce@akehir@petejohansonxo

[auto-labeler]

👍 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.

[amakhrov]

This is a mapping for the OAS2 built-in file type. It's similar to the existing mapping defined in TypeScriptAngularClientCodegen.java:

typeMapping.put("file", "Blob");

Without that, the updated toModelName() logic would add a bogus import for api endpoints that deal with type:file (imageUpload endpoint in PetStore)

Frankly, I'm not sure if the old mapping in line 151 here is needed at all.

[macjohnny]

@amakhrov Thanks a lot for your PR.
If I understand it correctly, the problem is not a bug itself, but rather a naming inconvenience?

[amakhrov]

@macjohnny i guess it depends on a point of view.
I consider it a bug, because it makes modelSuffix rather unusable in typescript-angular, resulting in enum names that are called Models (assuming Model is the suffix used).

However, one can argue that since generator still emits some valid typescript, it's not a bug but a feature.

If you think it's rather a feature than a bugfix - do you think it's still valuable to be merged into the next major version?

[amakhrov]

Thinking further about introducing backward incompatible changes.... Perhaps there is a way to keep compatibility by introducing a special v4-compat value of this new enumNameSuffix option, and making it a default. This value will enforce the existing behavior for all generators. This value can then be removed in the major release if needed.
Any thoughts?

[macjohnny]

@amakhrov I think it is a good idea to have a backwards-compatible behavior by default, so we can merge it and include it in the next patch release

[macjohnny]

concerning bug or feature, since the code compiles as it is generated now, i would consider it a feature/improvement of the naming, which is, of course, favorable, too.

[amakhrov]

All right, so I'll make the change described (introduce a special v4-compat value for this option), and update the PR - all tomorrow (it's past midnight over here already)

[macjohnny]

LGTM

[florianstuerzlinger]

Is it possible to not add a suffix to enums?
i tried calling the generator with an empty parameter -
This leads to the suffix "False". Any solution for this?

[amakhrov]

Fixes#5135

I was not able to approach this problem without introducing backward-incompatible changes.
A new enumSuffix option is introduced to minimize migration efforts, though.
UPDATE: actually, backward compatibility is now ensured by having v4-compat value by default for the newly introduced option

• (breaking change) With modelNameSuffix, only append "Enum" suffix but not model suffix. So instead of ResponseModelPropNameModelEnum we now get ResponseModelPropNameEnum.
• Without modelNameSuffix, all typescript generators except typescript-angular keep the existing behavior (emit smth like ResponsePropNameEnum)
• (breaking change) typescript-angular now follows the same enum naming rules as other TS generators. It still uses its custom modelSuffix, though - so it's still possible to configure it via modelNameSuffix or modelSuffix. Both options should work the same with the updated enum naming schema.
• enumSuffix is now configurable via options. This would provide smoother migration for existing users (e.g. one can set it to "ModelEnum" to mimic the old behavior).
• (bonus) More robust model names generation. Previously it would be possible to have a spec with a model named error (note lowcase!), which would then emit a Typescript interface Error. This should not have been possible, because Error is a builtin class. Now all the sanity checks are done to a fully-transformed model (after being camelized, and adding prefix and suffix). This addresses a part of the problem described in [BUG][typescript] Models named after language-specific types generate incorrectly #5139)

PR checklist

• Read the contribution guidelines.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

@TiFu@taxpon@sebastianhaas@kenisteward@Vrolijkx@macjohnny@nicokoenig@topce@akehir@petejohansonxo

[auto-labeler]

👍 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.

[amakhrov]

This is a mapping for the OAS2 built-in file type. It's similar to the existing mapping defined in TypeScriptAngularClientCodegen.java:

typeMapping.put("file", "Blob");

Without that, the updated toModelName() logic would add a bogus import for api endpoints that deal with type:file (imageUpload endpoint in PetStore)

Frankly, I'm not sure if the old mapping in line 151 here is needed at all.

[macjohnny]

@amakhrov Thanks a lot for your PR.
If I understand it correctly, the problem is not a bug itself, but rather a naming inconvenience?

[amakhrov]

@macjohnny i guess it depends on a point of view.
I consider it a bug, because it makes modelSuffix rather unusable in typescript-angular, resulting in enum names that are called Models (assuming Model is the suffix used).

However, one can argue that since generator still emits some valid typescript, it's not a bug but a feature.

If you think it's rather a feature than a bugfix - do you think it's still valuable to be merged into the next major version?

[amakhrov]

Thinking further about introducing backward incompatible changes.... Perhaps there is a way to keep compatibility by introducing a special v4-compat value of this new enumNameSuffix option, and making it a default. This value will enforce the existing behavior for all generators. This value can then be removed in the major release if needed.
Any thoughts?

[macjohnny]

@amakhrov I think it is a good idea to have a backwards-compatible behavior by default, so we can merge it and include it in the next patch release

[macjohnny]

concerning bug or feature, since the code compiles as it is generated now, i would consider it a feature/improvement of the naming, which is, of course, favorable, too.

[amakhrov]

All right, so I'll make the change described (introduce a special v4-compat value for this option), and update the PR - all tomorrow (it's past midnight over here already)

[macjohnny]

LGTM

[florianstuerzlinger]

Is it possible to not add a suffix to enums?
i tried calling the generator with an empty parameter -
This leads to the suffix "False". Any solution for this?

[amakhrov]

Fixes#5135

I was not able to approach this problem without introducing backward-incompatible changes.
A new enumSuffix option is introduced to minimize migration efforts, though.
UPDATE: actually, backward compatibility is now ensured by having v4-compat value by default for the newly introduced option

• (breaking change) With modelNameSuffix, only append "Enum" suffix but not model suffix. So instead of ResponseModelPropNameModelEnum we now get ResponseModelPropNameEnum.
• Without modelNameSuffix, all typescript generators except typescript-angular keep the existing behavior (emit smth like ResponsePropNameEnum)
• (breaking change) typescript-angular now follows the same enum naming rules as other TS generators. It still uses its custom modelSuffix, though - so it's still possible to configure it via modelNameSuffix or modelSuffix. Both options should work the same with the updated enum naming schema.
• enumSuffix is now configurable via options. This would provide smoother migration for existing users (e.g. one can set it to "ModelEnum" to mimic the old behavior).
• (bonus) More robust model names generation. Previously it would be possible to have a spec with a model named error (note lowcase!), which would then emit a Typescript interface Error. This should not have been possible, because Error is a builtin class. Now all the sanity checks are done to a fully-transformed model (after being camelized, and adding prefix and suffix). This addresses a part of the problem described in [BUG][typescript] Models named after language-specific types generate incorrectly #5139)

PR checklist

• Read the contribution guidelines.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

@TiFu@taxpon@sebastianhaas@kenisteward@Vrolijkx@macjohnny@nicokoenig@topce@akehir@petejohansonxo

[auto-labeler]

👍 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.

[amakhrov]

This is a mapping for the OAS2 built-in file type. It's similar to the existing mapping defined in TypeScriptAngularClientCodegen.java:

typeMapping.put("file", "Blob");

Without that, the updated toModelName() logic would add a bogus import for api endpoints that deal with type:file (imageUpload endpoint in PetStore)

Frankly, I'm not sure if the old mapping in line 151 here is needed at all.

[macjohnny]

@amakhrov Thanks a lot for your PR.
If I understand it correctly, the problem is not a bug itself, but rather a naming inconvenience?

[amakhrov]

@macjohnny i guess it depends on a point of view.
I consider it a bug, because it makes modelSuffix rather unusable in typescript-angular, resulting in enum names that are called Models (assuming Model is the suffix used).

However, one can argue that since generator still emits some valid typescript, it's not a bug but a feature.

If you think it's rather a feature than a bugfix - do you think it's still valuable to be merged into the next major version?

[amakhrov]

Thinking further about introducing backward incompatible changes.... Perhaps there is a way to keep compatibility by introducing a special v4-compat value of this new enumNameSuffix option, and making it a default. This value will enforce the existing behavior for all generators. This value can then be removed in the major release if needed.
Any thoughts?

[macjohnny]

@amakhrov I think it is a good idea to have a backwards-compatible behavior by default, so we can merge it and include it in the next patch release

[macjohnny]

concerning bug or feature, since the code compiles as it is generated now, i would consider it a feature/improvement of the naming, which is, of course, favorable, too.

[amakhrov]

All right, so I'll make the change described (introduce a special v4-compat value for this option), and update the PR - all tomorrow (it's past midnight over here already)

[macjohnny]

LGTM

[florianstuerzlinger]

Is it possible to not add a suffix to enums?
i tried calling the generator with an empty parameter -
This leads to the suffix "False". Any solution for this?

[amakhrov]

Fixes#5135

I was not able to approach this problem without introducing backward-incompatible changes.
A new enumSuffix option is introduced to minimize migration efforts, though.
UPDATE: actually, backward compatibility is now ensured by having v4-compat value by default for the newly introduced option

• (breaking change) With modelNameSuffix, only append "Enum" suffix but not model suffix. So instead of ResponseModelPropNameModelEnum we now get ResponseModelPropNameEnum.
• Without modelNameSuffix, all typescript generators except typescript-angular keep the existing behavior (emit smth like ResponsePropNameEnum)
• (breaking change) typescript-angular now follows the same enum naming rules as other TS generators. It still uses its custom modelSuffix, though - so it's still possible to configure it via modelNameSuffix or modelSuffix. Both options should work the same with the updated enum naming schema.
• enumSuffix is now configurable via options. This would provide smoother migration for existing users (e.g. one can set it to "ModelEnum" to mimic the old behavior).
• (bonus) More robust model names generation. Previously it would be possible to have a spec with a model named error (note lowcase!), which would then emit a Typescript interface Error. This should not have been possible, because Error is a builtin class. Now all the sanity checks are done to a fully-transformed model (after being camelized, and adding prefix and suffix). This addresses a part of the problem described in [BUG][typescript] Models named after language-specific types generate incorrectly #5139)

PR checklist

• Read the contribution guidelines.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

@TiFu@taxpon@sebastianhaas@kenisteward@Vrolijkx@macjohnny@nicokoenig@topce@akehir@petejohansonxo

[auto-labeler]

👍 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.

[amakhrov]

This is a mapping for the OAS2 built-in file type. It's similar to the existing mapping defined in TypeScriptAngularClientCodegen.java:

typeMapping.put("file", "Blob");

Without that, the updated toModelName() logic would add a bogus import for api endpoints that deal with type:file (imageUpload endpoint in PetStore)

Frankly, I'm not sure if the old mapping in line 151 here is needed at all.

[macjohnny]

@amakhrov Thanks a lot for your PR.
If I understand it correctly, the problem is not a bug itself, but rather a naming inconvenience?

[amakhrov]

@macjohnny i guess it depends on a point of view.
I consider it a bug, because it makes modelSuffix rather unusable in typescript-angular, resulting in enum names that are called Models (assuming Model is the suffix used).

However, one can argue that since generator still emits some valid typescript, it's not a bug but a feature.

If you think it's rather a feature than a bugfix - do you think it's still valuable to be merged into the next major version?

[amakhrov]

Thinking further about introducing backward incompatible changes.... Perhaps there is a way to keep compatibility by introducing a special v4-compat value of this new enumNameSuffix option, and making it a default. This value will enforce the existing behavior for all generators. This value can then be removed in the major release if needed.
Any thoughts?

[macjohnny]

@amakhrov I think it is a good idea to have a backwards-compatible behavior by default, so we can merge it and include it in the next patch release

[macjohnny]

concerning bug or feature, since the code compiles as it is generated now, i would consider it a feature/improvement of the naming, which is, of course, favorable, too.

[amakhrov]

All right, so I'll make the change described (introduce a special v4-compat value for this option), and update the PR - all tomorrow (it's past midnight over here already)

[macjohnny]

LGTM

[florianstuerzlinger]

Is it possible to not add a suffix to enums?
i tried calling the generator with an empty parameter -
This leads to the suffix "False". Any solution for this?

[amakhrov]

Fixes#5135

I was not able to approach this problem without introducing backward-incompatible changes.
A new enumSuffix option is introduced to minimize migration efforts, though.
UPDATE: actually, backward compatibility is now ensured by having v4-compat value by default for the newly introduced option

• (breaking change) With modelNameSuffix, only append "Enum" suffix but not model suffix. So instead of ResponseModelPropNameModelEnum we now get ResponseModelPropNameEnum.
• Without modelNameSuffix, all typescript generators except typescript-angular keep the existing behavior (emit smth like ResponsePropNameEnum)
• (breaking change) typescript-angular now follows the same enum naming rules as other TS generators. It still uses its custom modelSuffix, though - so it's still possible to configure it via modelNameSuffix or modelSuffix. Both options should work the same with the updated enum naming schema.
• enumSuffix is now configurable via options. This would provide smoother migration for existing users (e.g. one can set it to "ModelEnum" to mimic the old behavior).
• (bonus) More robust model names generation. Previously it would be possible to have a spec with a model named error (note lowcase!), which would then emit a Typescript interface Error. This should not have been possible, because Error is a builtin class. Now all the sanity checks are done to a fully-transformed model (after being camelized, and adding prefix and suffix). This addresses a part of the problem described in [BUG][typescript] Models named after language-specific types generate incorrectly #5139)

PR checklist

• Read the contribution guidelines.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

@TiFu@taxpon@sebastianhaas@kenisteward@Vrolijkx@macjohnny@nicokoenig@topce@akehir@petejohansonxo

[auto-labeler]

👍 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.

[amakhrov]

This is a mapping for the OAS2 built-in file type. It's similar to the existing mapping defined in TypeScriptAngularClientCodegen.java:

typeMapping.put("file", "Blob");

Without that, the updated toModelName() logic would add a bogus import for api endpoints that deal with type:file (imageUpload endpoint in PetStore)

Frankly, I'm not sure if the old mapping in line 151 here is needed at all.

[macjohnny]

@amakhrov Thanks a lot for your PR.
If I understand it correctly, the problem is not a bug itself, but rather a naming inconvenience?

[amakhrov]

@macjohnny i guess it depends on a point of view.
I consider it a bug, because it makes modelSuffix rather unusable in typescript-angular, resulting in enum names that are called Models (assuming Model is the suffix used).

However, one can argue that since generator still emits some valid typescript, it's not a bug but a feature.

If you think it's rather a feature than a bugfix - do you think it's still valuable to be merged into the next major version?

[amakhrov]

Thinking further about introducing backward incompatible changes.... Perhaps there is a way to keep compatibility by introducing a special v4-compat value of this new enumNameSuffix option, and making it a default. This value will enforce the existing behavior for all generators. This value can then be removed in the major release if needed.
Any thoughts?

[macjohnny]

@amakhrov I think it is a good idea to have a backwards-compatible behavior by default, so we can merge it and include it in the next patch release

[macjohnny]

concerning bug or feature, since the code compiles as it is generated now, i would consider it a feature/improvement of the naming, which is, of course, favorable, too.

[amakhrov]

All right, so I'll make the change described (introduce a special v4-compat value for this option), and update the PR - all tomorrow (it's past midnight over here already)

[macjohnny]

LGTM

[florianstuerzlinger]

Is it possible to not add a suffix to enums?
i tried calling the generator with an empty parameter -
This leads to the suffix "False". Any solution for this?

[amakhrov]

Fixes#5135

I was not able to approach this problem without introducing backward-incompatible changes.
A new enumSuffix option is introduced to minimize migration efforts, though.
UPDATE: actually, backward compatibility is now ensured by having v4-compat value by default for the newly introduced option

• (breaking change) With modelNameSuffix, only append "Enum" suffix but not model suffix. So instead of ResponseModelPropNameModelEnum we now get ResponseModelPropNameEnum.
• Without modelNameSuffix, all typescript generators except typescript-angular keep the existing behavior (emit smth like ResponsePropNameEnum)
• (breaking change) typescript-angular now follows the same enum naming rules as other TS generators. It still uses its custom modelSuffix, though - so it's still possible to configure it via modelNameSuffix or modelSuffix. Both options should work the same with the updated enum naming schema.
• enumSuffix is now configurable via options. This would provide smoother migration for existing users (e.g. one can set it to "ModelEnum" to mimic the old behavior).
• (bonus) More robust model names generation. Previously it would be possible to have a spec with a model named error (note lowcase!), which would then emit a Typescript interface Error. This should not have been possible, because Error is a builtin class. Now all the sanity checks are done to a fully-transformed model (after being camelized, and adding prefix and suffix). This addresses a part of the problem described in [BUG][typescript] Models named after language-specific types generate incorrectly #5139)

PR checklist

• Read the contribution guidelines.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

@TiFu@taxpon@sebastianhaas@kenisteward@Vrolijkx@macjohnny@nicokoenig@topce@akehir@petejohansonxo

[auto-labeler]

👍 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.

[amakhrov]

This is a mapping for the OAS2 built-in file type. It's similar to the existing mapping defined in TypeScriptAngularClientCodegen.java:

typeMapping.put("file", "Blob");

Without that, the updated toModelName() logic would add a bogus import for api endpoints that deal with type:file (imageUpload endpoint in PetStore)

Frankly, I'm not sure if the old mapping in line 151 here is needed at all.

[macjohnny]

@amakhrov Thanks a lot for your PR.
If I understand it correctly, the problem is not a bug itself, but rather a naming inconvenience?

[amakhrov]

@macjohnny i guess it depends on a point of view.
I consider it a bug, because it makes modelSuffix rather unusable in typescript-angular, resulting in enum names that are called Models (assuming Model is the suffix used).

However, one can argue that since generator still emits some valid typescript, it's not a bug but a feature.

If you think it's rather a feature than a bugfix - do you think it's still valuable to be merged into the next major version?

[amakhrov]

Thinking further about introducing backward incompatible changes.... Perhaps there is a way to keep compatibility by introducing a special v4-compat value of this new enumNameSuffix option, and making it a default. This value will enforce the existing behavior for all generators. This value can then be removed in the major release if needed.
Any thoughts?

[macjohnny]

@amakhrov I think it is a good idea to have a backwards-compatible behavior by default, so we can merge it and include it in the next patch release

[macjohnny]

concerning bug or feature, since the code compiles as it is generated now, i would consider it a feature/improvement of the naming, which is, of course, favorable, too.

[amakhrov]

All right, so I'll make the change described (introduce a special v4-compat value for this option), and update the PR - all tomorrow (it's past midnight over here already)

[macjohnny]

LGTM

[florianstuerzlinger]

Is it possible to not add a suffix to enums?
i tried calling the generator with an empty parameter -
This leads to the suffix "False". Any solution for this?

[amakhrov]

Fixes#5135

I was not able to approach this problem without introducing backward-incompatible changes.
A new enumSuffix option is introduced to minimize migration efforts, though.
UPDATE: actually, backward compatibility is now ensured by having v4-compat value by default for the newly introduced option

• (breaking change) With modelNameSuffix, only append "Enum" suffix but not model suffix. So instead of ResponseModelPropNameModelEnum we now get ResponseModelPropNameEnum.
• Without modelNameSuffix, all typescript generators except typescript-angular keep the existing behavior (emit smth like ResponsePropNameEnum)
• (breaking change) typescript-angular now follows the same enum naming rules as other TS generators. It still uses its custom modelSuffix, though - so it's still possible to configure it via modelNameSuffix or modelSuffix. Both options should work the same with the updated enum naming schema.
• enumSuffix is now configurable via options. This would provide smoother migration for existing users (e.g. one can set it to "ModelEnum" to mimic the old behavior).
• (bonus) More robust model names generation. Previously it would be possible to have a spec with a model named error (note lowcase!), which would then emit a Typescript interface Error. This should not have been possible, because Error is a builtin class. Now all the sanity checks are done to a fully-transformed model (after being camelized, and adding prefix and suffix). This addresses a part of the problem described in [BUG][typescript] Models named after language-specific types generate incorrectly #5139)

PR checklist

• Read the contribution guidelines.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

@TiFu@taxpon@sebastianhaas@kenisteward@Vrolijkx@macjohnny@nicokoenig@topce@akehir@petejohansonxo

[auto-labeler]

👍 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.

[amakhrov]

This is a mapping for the OAS2 built-in file type. It's similar to the existing mapping defined in TypeScriptAngularClientCodegen.java:

typeMapping.put("file", "Blob");

Without that, the updated toModelName() logic would add a bogus import for api endpoints that deal with type:file (imageUpload endpoint in PetStore)

Frankly, I'm not sure if the old mapping in line 151 here is needed at all.

[macjohnny]

@amakhrov Thanks a lot for your PR.
If I understand it correctly, the problem is not a bug itself, but rather a naming inconvenience?

[amakhrov]

@macjohnny i guess it depends on a point of view.
I consider it a bug, because it makes modelSuffix rather unusable in typescript-angular, resulting in enum names that are called Models (assuming Model is the suffix used).

However, one can argue that since generator still emits some valid typescript, it's not a bug but a feature.

If you think it's rather a feature than a bugfix - do you think it's still valuable to be merged into the next major version?

[amakhrov]

Thinking further about introducing backward incompatible changes.... Perhaps there is a way to keep compatibility by introducing a special v4-compat value of this new enumNameSuffix option, and making it a default. This value will enforce the existing behavior for all generators. This value can then be removed in the major release if needed.
Any thoughts?

[macjohnny]

@amakhrov I think it is a good idea to have a backwards-compatible behavior by default, so we can merge it and include it in the next patch release

[macjohnny]

concerning bug or feature, since the code compiles as it is generated now, i would consider it a feature/improvement of the naming, which is, of course, favorable, too.

[amakhrov]

All right, so I'll make the change described (introduce a special v4-compat value for this option), and update the PR - all tomorrow (it's past midnight over here already)

[macjohnny]

LGTM

[florianstuerzlinger]

Is it possible to not add a suffix to enums?
i tried calling the generator with an empty parameter -
This leads to the suffix "False". Any solution for this?