Hello! I love the codegen so far, we use it in our large scale serverless project in the following scenario:
Typescript Backend with TSOA Controllers
generated OpenApi3 Spec with rich documentation and validations
generated frontend typescript client (and other language clients)
Generated code matches the initial structure really well, preserving complex union types (Dog | Cat), understanding interface extension, etc. What it doesn't (obviously) do, is help with validation rules such as min/maxLengths.
It would be non-intrusively helpful if we could optionally preserve the JSDoc structure that we used in the original code to generate OpenAPI rich spec. Or, more closely, generate rich JSDoc from the OpenAPI descriptions.
Our initial annotations (as well as the "target" JSDoc we'd like to have in the generated client).
If data from OpenAPI spec, such as example, minLength, pattern, description from both Schemas and Operations, could be mapped in the output to JSDoc comments above interfaces, services, properties, etc, we could preserve rich information about the proper data structure and see it in IntelliSense-like way in the IDEs.
Hello! I love the codegen so far, we use it in our large scale serverless project in the following scenario:
Typescript Backend with TSOA Controllers
generated OpenApi3 Spec with rich documentation and validations
generated frontend typescript client (and other language clients)
Generated code matches the initial structure really well, preserving complex union types (Dog | Cat), understanding interface extension, etc. What it doesn't (obviously) do, is help with validation rules such as min/maxLengths.
It would be non-intrusively helpful if we could optionally preserve the JSDoc structure that we used in the original code to generate OpenAPI rich spec. Or, more closely, generate rich JSDoc from the OpenAPI descriptions.
Our initial annotations (as well as the "target" JSDoc we'd like to have in the generated client).
which corresponds to the following in the OpenApi.json
If data from OpenAPI spec, such as
example
,minLength
,pattern
,description
from both Schemas and Operations, could be mapped in the output to JSDoc comments above interfaces, services, properties, etc, we could preserve rich information about the proper data structure and see it in IntelliSense-like way in the IDEs.