[Angular-typescript] Regression/bug: Parameters with an _ ignore naming convention

[HermenOtter]

Description

Parameters with an _ ignore naming convention since a few days. This bug occurred a few months ago as well and has been fixed at the time.

Swagger-codegen version

master(54ce4ca and 8ae1184) are not working as expected.

Swagger declaration file content or url

/sadr/v1/soorten_adres/{code_soort_adres}:
    parameters:
    - name: "code_soort_adres"
      in: "path"
      required: true
      type: "string"

Command line used for generation

java -jar swagger-codegen-cli.jar generate -i https://api.swaggerhub.com/apis/Centric/Belastingen_Subjecten/0.2.4 -l typescript-angular -c=./SCGConf.md

SCGConf.md
{"modelPropertyNaming": "original"}

Code generation
Generates code_soort_adres as parameter for the method, but when used in that same method it is called as codeSoortAdres which obviously doesn't work.

public getSoortenAdresByCode(code_soort_adres: string,
return this.httpClient.get<any>(${this.basePath}/.../${encodeURIComponent(String(codeSoortAdres))}

Related issues/PRs

7201, regression

Suggest a fix/enhancement

I believe it is has something to do with issue 7201.

@wing328 @JFCote @kenisteward

[meisterlampe]

I have the same problem after upgrading to v2.3.0
The generated code isn't compilable

[JFCote]

@HermenOtter @meisterlampe I'm the one responsible for this regression (I think). It was fixing other stuff and it is working like the other generators but there seems to be something missing. I can assure you that it was tested against our petstore samples and it was tested by a user who had problem with that.

Anyway, I will have a look at this today and try to come up with a fix as soon as possible. I'll keep you updated here.

[JFCote]

@HermenOtter @meisterlampe
I have debugged this and I am relieved to see that my code is not responsible for this regression. This problem is created by this very weird loop:
https://github.com/swagger-api/swagger-codegen/blob/master/modules/swagger-codegen/src/main/java/io/swagger/codegen/languages/TypeScriptAngularClientCodegen.java#L268

As you can see, underscores are deleted and the camelCase naming convention is used by default, which is completely wrong I think. This explains why underscores disappear from the parameter name.

I will create a PR to fix it but I think it would be good to have the advice of @defmonk0 to understand why it was done that way.

So, PR coming very soon with what I think is a pretty good fix.

[JFCote]

@HermenOtter @meisterlampe There you go. Can you try the PR and see if it fix your problem? Your feedback appreciated.

[defmonk0]

Hey everyone. To explain the idea behind this, it helps to see the original issue I opened that prompted these changes.

The general idea is this: Angular's standard style guide uses camel case for more or less everything. As such, codegen generates the files using this by default as well, and so function parameters are converted. Because the return statements in the service files use the URI path rather than those parameters, I made it so the variables in the path would be changed as well. In all, the exact opposite of what you're experiencing now.

At the time of change, I was unaware the parameter names were configurable via modelPropertyNaming. The code changes are therefore forcing the change to camel case in the return statement when you may not want them to. I was not using this option, so the current code makes sense in that case. If it is standard for this to be configurable across all of the languages codegen supports, then changing that code block to execute appropriately based on the config would be ideal.

EDIT: To explain the loop itself, it was originally done before my changes much more simply with a single regex. I originally was going to keep using regex to find and convert the variable names, but it was complicated and very difficult to understand when looking at it. It was much simpler to iterate through the string myself, which is what you see there.

[JFCote]

@defmonk0 Thanks for the clarification.

With that in mind, can you do a review of my proposed PR and see if it makes sense? Thanks!

[meisterlampe]

I just tested this using a Snapshot of 2.4.0 and it is working perfectly fine. Thanks for the fast reaction and solution!

[wing328]

@meisterlampe thanks for confirming it's no longer an issue with the latest SNAPSHOT version of master (2.3.1)

Thanks @JFCote again for the quick fix 👍

@HermenOtter please give it another try with the latest SNAPSHOT