Support for property name amendment

[moltar]

It'd be great to be able to filter the property names and rename them too.

Our API returns snake_case property names, but JS/TS world is mostly operating in camelCase.

I'd like to be able to convert these before output.

Thanks.

[horiuchi]

@moltar Thank you for using this!

That can convert type name to use the dtsgenerator as a library.
https://github.com/horiuchi/dtsgenerator#usage-for-library

[moltar]

Thank you for replying so quickly!

I saw that type renames are possible via library.

But my use case is to rename the property names, not types.

E.g.

Interface foo {
some_prop: string
}

To

Interface foo {
someProp: string
}

_{Sent with GitHawk}

[horiuchi]

Oh sorry, I'm mistaken.

But in a normal case, we use it for converting the API response or request definition to TypeScript definition.
If it changes the property name, the TypeScript definition may not fit together API's JSON.

Do you want it in any situation?

[moltar]

It is not a problem that it will not match, because I will convert the responses too to match camelCase.

[adriengibrat]

Did you consider to align naming convention between API producer & consumer?
It would be a great move, IMHO ;)

[amoshydra]

Off-topic:

Did you consider to align naming convention between API producer & consumer?
It would be a great move, IMHO ;)

I am curious how is this usually done, especially when API producer and consumer are written in different languages that following different casing convention. Do you still try to set a casing convention between API producer and consumer?

---

In our situation producer (our API server) is written in ruby (which uses snake_case), whereas consumer uses JS/TS (camelCase). Trying to use a foreign casing will often trigger our linter.

Most of our consumer will do a snake_case --> camelCase in the response, and camelCase --> snake_case in the request.

[horiuchi]

It is now possible to convert property names using the plugin's post process.
Please consider it.