Transform case for generated types

[robdodson]

Transform case for generated types

[mrlubos]

Hey @robdodson, how do you currently deal with this since the package doesn't support it?

[robdodson]

@mrlubos

@OskarAsplin published the package to npm in this comment. I've been using that version to generate our types.

I looked into using other libraries like Zodios and ts-rest but haven't really committed to either of them. Since our app is quite large and several developers work on it, just getting folks to incrementally adopt generated types from OpenAPI has been as far as I've gotten.

[mrlubos]

I'm going to file this under the clients label as there's more work needed to complete this feature. Do you have an example of the middleware you use to actually transform the data?

[robdodson]

yep it's pretty simple. It uses the second argument to JSON.parse, which is a reviver function

import { camelCase } from 'lodash'

export default function camelCaseJsonBody(body: string): any {
  if (!body) {
    return {}
  }
  return JSON.parse(body, function (k, v) {
    if (('' + k).includes('_')) {
      this[camelCase(k)] = v
      return
    }

    return v
  })
}

Our network util essentially does this:

const res = fetch(...)
const data = await res.json()
return camelCaseJsonBody(data)

[mrlubos]

Thanks for all the context @robdodson! No concern about overhead added by this transform?

I'll say that this feature isn't a priority at the moment, but it's good to keep in mind when doing architectural decisions. As you already found out, transforming nested values isn't intuitive as an example..

[robdodson]

No concern about overhead added by this transform?

I certainly don't love the transform, but it was put in during the early days of the company (3-4+ years ago) before I joined and now all of the backend services are built expecting snake case, and all of the frontend SPAs expect camel case. So it's one of those things that's difficult to change at this point.

I'll say that this feature isn't a priority at the moment, but it's good to keep in mind when doing architectural decisions.

That's fair, though the work for the PR is already done (for openapi-typescript-codegen at least) and I was curious how hard it might be for me to port it over? I can at least attest to the fact that we've been using it for quite a while on pretty large OpenAPI specs and haven't run into any issues and there were a decent number of upvotes on the original PR indicating that other folks have run into this same problem.

Is your main concern the complexity it might add to the codebase or is it more of an issue around not having time to work on something like this?

[mrlubos]

@robdodson mainly a time/focus issue, it's just not the biggest lever to pull right now imo. Most of the touched files in the original pull request are quite different now, so I'm not sure we can even call it porting anymore, feels like it would have to be written almost from scratch.

A few things to think about:

• configuration. Can it be config file only? Is CLI support required? Most of the current configuration is in nested option objects and CLI doesn't support those yet.
• middleware. Both request and response middleware should be provided so people don't have to write it themselves. There's a similar flag for transforming dates into Date in types, and the feedback has been that without middleware, that functionality is useless. I want to avoid similar fate for this feature.
• implementation. I'm not loving that you have to map through models before they're printed. Wonder if you ran any benchmark tests or know the impact this has had on performance? I've recently started adding mappings which are used to deduplicate types, would love to use something like that if possible.