OpenAPITools / OpenAPITools/openapi-generator
[REQ] Render Spring Boot @Schema Validation Annotations in TypeScript as JSDOC
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 26.8k
- Forks
- 7.7k
- PR merge metrics
- PR metrics pending
Description
Is your feature request related to a problem? Please describe.
Problem Explanation:
When using the typescript-fetch generator from OpenAPI Generator, validation annotations from Spring Boot’s @Schema (such as minLength, maxLength, minimum, maximum, pattern, and format) are not rendered in the generated TypeScript models. These annotations are present in the OpenAPI specification generated from Spring Boot, but they are not included in the TypeScript code.
Currently, the typescript-fetch generator only includes basic JSDoc annotations like @type and @memberof, but it does not render validation-related annotations such as minLength, maxLength, minimum, maximum, pattern, and format. These constraints are important for ensuring proper input validation on the client side, and without them, the TypeScript models lack critical information for developers working with the API.
Example:
In the Spring Boot code, the @Schema annotation defines validation rules, such as:
minLengthandmaxLengthfor string length constraintsminimumandmaximumfor numerical value rangespatternfor regex validationformatfor specific value formats (e.g., date-time, email)
However, when OpenAPI Generator generates the TypeScript client using the typescript-fetch generator, this information is missing from the generated models. The validation annotations should be rendered in the TypeScript code as JSDoc comments to make the constraints visible and usable for developers working with the client code.
Environment:
I am using OpenAPI Generator CLI via Docker, and I pulled the latest version of the Docker image, which is 7.12.0-SNAPSHOT.
Describe the solution you'd like
Describe the solution you'd like:
Spring Boot DTO class example:
public class ExampleDTO {
@NotNull
private Long exampleId;
@Schema(
format = "date",
description = "Date in the format dd/MM/yyyy",
example = "31/01/2025",
pattern = "^\\d{2}/\\d{2}/\\d{4}$", // Keep as is in the schema
defaultValue = "21/12/1989"
)
@NotNull
private String date;
}
Generated example using the typescript-fetch generator from the above DTO class:
export interface ExampleDTO {
/**
*
* @type {number}
* @memberof ExampleDTO
*/
exampleId: number;
/**
*
* @type {string}
* @memberof UniEngineerDTO
* @format date
* @pattern ^\\d{2}/\\d{2}/\\d{4}$
* @default 21/12/1989
*/
date: string;
}
I have managed to render the validation fields (minLength, maxLength, minimum, maximum, pattern, and format) in the TypeScript models by modifying the corresponding template (modelGenericInterfaces.mustache). I added the following lines inside the {{#vars}} block of the template to include these annotations as JSDoc comments:
{{#minLength}}
* @minLength {{minLength}}
{{/minLength}}
{{#maxLength}}
* @maxLength {{maxLength}}
{{/maxLength}}
{{#minimum}}
* @minimum {{minimum}}
{{/minimum}}
{{#maximum}}
* @maximum {{maximum}}
{{/maximum}}
{{#pattern}}
* @pattern {{pattern}}
{{/pattern}}
{{#format}}
* @format {{format}}
{{/format}}
However, I was unable to render the @format annotation using this method. It would be great if the OpenAPI Generator could natively support rendering these validation fields, including @format, as part of the TypeScript models.
Describe alternatives you've considered
I have also considered the possibility of writing a post-processing script to inject the missing annotations into the generated TypeScript code after the OpenAPI Generator runs, but this approach feels like a workaround rather than an elegant, native solution.
Additional context
Should I submit a pull request to modify the modelGenericInterfaces.mustache template to include the missing validation annotations? I’ve already modified the template locally to render annotations such as minLength, maxLength, minimum, maximum, pattern, and format as JSDoc comments, but I was unable to make the @format annotation work properly.
Would it be possible to implement a more robust solution to handle the @format option correctly, or would you recommend another approach? Let me know how you would like to proceed regarding this matter.
This version poses the question clearly while also addressing your approach and concerns about the @format option. Let me know if you'd like any further changes!
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the typescript-fetch generator and its modelGenericInterfaces.mustache template, then inspect how schema format and validation fields reach the template variables. Run generation using the Spring Boot-derived example specification and compare the generated model comments; done means minLength, maxLength, minimum, maximum, pattern, and format appear correctly as JSDoc annotations.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- spring-boot, typescript
- Domain
- api, tooling
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100