Changing default case of schema properties

[stefanbartos]

Hi,

I have a question about changing the case of generated schema properties.

Our OpenApi specification is generated from .NET API. Since all exported object properties have pascal case by default, generated schemas have also pascal, which is not TS/JS convention. It can be solved by these suggestions.

• Changing the case in config.ts file. This method is not ideal, but works.

      to: async (context) => {
          const filenamePrefix = 'api';
          const { openAPIDocument: { components } } = context;
          for (const schema of Object.values(components?.schemas || {})) {
              if (!isSchemaObject(schema)) {
                  continue;
              }
              const { properties, required } = schema;
              if (properties == null) {
                  continue;
              }
              for (const propertyName of Object.keys(properties)) {
                  const stored = properties[propertyName];
                  delete properties[propertyName]
                  properties[_.camelCase(propertyName)] = stored;
              }
  
              if (required != null) {
                  for (let i = 0; i < required.length; i++) {
                      const propertyName = required[i];
                      required[i] = _.camelCase(propertyName);
                  }
              }
          }
          const { schemasFiles } = await generateSchemaTypes(context, {
              filenamePrefix,
          });
          await generateFetchers(context, {
              filenamePrefix,
              schemasFiles,
          });
      },

• Adding a new config parameter to override casings. It may look like the example below. I can make a PR for that if necessary.

  
  export type ConfigBase = {
  ...
  filenameCase?: keyof Pick<typeof c, "snake" | "camel" | "kebab" | "pascal">;
  casing?: {
  schema?: {
    property?: keyof Pick<typeof c, "snake" | "camel" | "kebab" | "pascal">;
  }
  }
  };

Which option is better? If none, how should solve this issue?

Thx for your answers.

[MbBrainz]

You'd still need a conversion from what the api returns to your casing though. I was looking for a option to set the casing to camelcase, but the api returns snake_case. If you then generate the types in CamelCase, the conversion from the snake_case json to your CamelCase types would fail.

I would love to see this problem worked out though!

[Rendez]

You'd still need a conversion from what the api returns to your casing though. I was looking for a option to set the casing to camelcase, but the api returns snake_case. If you then generate the types in CamelCase, the conversion from the snake_case json to your CamelCase types would fail.

I would love to see this problem worked out though!

And then there's the complexity of tracking fields in request bodies which are actually part of the schema, to not just blindly camelCase everything recursively, but just those keys that are part of the OAS (additionalProperties: true)