[typescript-angular] how to customize output filenames?

[softdays]

Do someone can help me to customize output files names?

Given the tag below:
My Resource
I want to obtain the output file:
my-resource.service.ts
instead of myResource.service.ts

Given the model below:
MyModel
I want to obtain the output file:
my-model.ts
instead of myModel.ts

Many thanks for your help

[wing328]

@softdays you will need to customize the code in order to achieve that:
API: https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptAngularClientCodegen.java#L454-L459
Model: https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptAngularClientCodegen.java#L466-L470

Side question: does my-resource.service.ts conform to the TS file naming convention?

[softdays]

@wing328 many thanks for the code highlights

See this guide for TypeScript/Angular conventions:
https://angular.io/guide/styleguide#service-names

Do you think this could be the subject of a feature request and/or PR?

[wing328]

Thanks for sharing more.

Yes, I think we should follow the style guide.

May I know if you've time to file a PR with the correction/enhancement?

cc @TiFu (2017/07) @taxpon (2017/07) @sebastianhaas (2017/07) @kenisteward (2017/07) @Vrolijkx (2017/09) @macjohnny (2018/01)

[softdays]

It will depend of the workload. Should the PR just be a drop-in replacement of the current camelCase strategy? Or do you prefer to implement a new option driving different strategies? I think about something similar that we already have with modelPropertyNaming for example...

[wing328]

A new option is definitely more preferable as users can easily restore the old behavior 在 2018年8月4日週六 下午1:52，Remi Patriarche <notifications@github.com> 寫道：

…

It will depend of the charge. Should the PR just be a drop-in replacement of the current camelCase strategy? Or do you prefer to setup a new option driving different strategies? I think about something similar that we already have with modelPropertyNaming for example... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#727 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA5BdLVQFQEjcb4fDEqoa2R-7ISdCx8Bks5uNTaXgaJpZM4Vt4gy> .

[softdays]

Do you have any preference for the name of the new property defining the naming strategy?
Should I use the master branch (3.2-SNAPSHOT) for this job as this will be a non-breaking change?

[wing328]

For option name, I would suggest "fileNaming".

(please add this option as a TypeScript Angular option only (not a global option))

Should I use the master branch (3.2-SNAPSHOT) for this job as this will be a non-breaking change?

Yes, please.

[softdays]

@wing328: at the moment, the names of the imported classes are deduced from their file names. This causes some trouble with the new dash-case strategy.

Let's take an example. Given the following resource tag name: MY Resource AAA.
The generated service name will be MYResourceAAAService

With default fileNaming property value (i.e. original code using camelCase) we got the following filename: mYResourceAAA.service.ts
In this case we can indeed deduce the import className from the fileName because we preserved case.

But with fileNaming=dash-case, the file name we got is: my-resource-aaa.service.ts
So we cannot deduce the right className anymore because we lost original letter case.

My proposal would be to normalize the names of the services in order to get: MyResourceAaaService.
In this way we can deduce the names of the imported classes from their files names.

What do you think?

[macjohnny]

My proposal would be to normalize the names of the services in order to get: MyResourceAaaService.
In this way we can deduce the names of the imported classes from their files names.

this could lead to potential problems. file names and class names can differ. if i remember correctly, there were PRs that explicitly introduced this feature.

[softdays]

Ok I understand.

Another way could be to extend the imports model to add a class name in addition to the import path. What do you think about it?

[softdays]

No feedback on this proposal? Maybe my proposal is not clear enough...

[wing328]

@softdays to move this forward, what about testing different API and model naming (PascalCase, snake-case, etc) with your PR? That way we can ensure the new naming option you introduced works with different cases.

[softdays]

Not sure to understand what you suggest...
Would you suggest that I should continue my PR by adding more output possibilities for filenames?

As you know I'm currently facing a structural issue with my PR concerning 'imports' generation using kebab-case and I don't have any potential solution for that...