Support for property name amendment about dtsgenerator HOT 7 CLOSED

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

from dtsgenerator.

@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

from dtsgenerator.

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}

from dtsgenerator.

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?

from dtsgenerator.

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

from dtsgenerator.

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.

from dtsgenerator.

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

from dtsgenerator.