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

[wing328]

Would you suggest that I should continue my PR by adding more output possibilities for filenames?

Sorry, that's not what I meant.

Your PR add an option to choosing the naming convention: camelCase, dash-case, which is good.

My question is have you test both to ensure the issue mentioned by @macjohnny does not occur:

file names and class names can differ.

If both options (camelCase, dash-case) have been tested to ensure there's no discrepancy between the two and the code is compilable, then we can move forward with your PR.

[softdays]

The issue mentioned by @macjohnny is related to my proposal concerning class names normalization.
But as you can see in the code below the model names of imports are already deduced from file names, at least for the typescript-angular generator. So I don't understand how file names and class names can differ given that imported model names of a service will be resolved from their file names:

openapi-generator/modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptAngularClientCodegen.java

Line 377 in 37fd426

im.put("classname", getModelnameFromModelFilename(im.get("filename").toString()));

[wing328]

@softdays as discussed, there's a way to retrieve the "original" model/class name. Using that will fix the import issue.

[wing328]

cc @TiFu as we may also need this feature/option in the refactored TS generator.