Interface with Id generated as optional

[oscarlagatta]

Description

When running the generation script, even that the open api specification says that the ID key is mandatory the generation shows the ID as optional, can this generation be configured for the IDs, and for all the fields as not all are optional.

Reproducible example or configuration

C# dto public class UserDto { public int UserID { get; set; } public string FullName { get; set; } public string Email { get; set; } public string PhoneNumber { get; set; } public string Address { get; set; } public string City { get; set; } public string StateOrProvince { get; set; } public string PostalCode { get; set; } public string Country { get; set; } public string JobTitle { get; set; } public string Bio { get; set; } public DateTime CreatedDate { get; set; } public DateTime LastUpdatedDate { get; set; } }

types.gen.ts

export type UserDto = { userID?: number; fullName?: string | null; email?: string | null; phoneNumber?: string | null; address?: string | null; city?: string | null; stateOrProvince?: string | null; postalCode?: string | null; country?: string | null; jobTitle?: string | null; bio?: string | null; createdDate?: string; lastUpdatedDate?: string; };

OpenAPI specification (optional)

  "UserDto": {
    "type": "object",
    "properties": {
      "userID": {
        "type": "integer",
        "format": "int32"
      },
      "fullName": {
        "type": "string",
        "nullable": true
      },
      "email": {
        "type": "string",
        "nullable": true
      },
      "phoneNumber": {
        "type": "string",
        "nullable": true
      },
      "address": {
        "type": "string",
        "nullable": true
      },
      "city": {
        "type": "string",
        "nullable": true
      },
      "stateOrProvince": {
        "type": "string",
        "nullable": true
      },
      "postalCode": {
        "type": "string",
        "nullable": true
      },
      "country": {
        "type": "string",
        "nullable": true
      },
      "jobTitle": {
        "type": "string",
        "nullable": true
      },
      "bio": {
        "type": "string",
        "nullable": true
      },
      "createdDate": {
        "type": "string",
        "format": "date-time"
      },
      "lastUpdatedDate": {
        "type": "string",
        "format": "date-time"
      }
    },

System information (optional)

No response

[mrlubos]

Hi @oscarlagatta, this is an issue with the OpenAPI specification. If you want to mark fields as required, you need to use the required keyword.

[oscarlagatta]

Thanks

On Tue, 12 Nov 2024 at 13:28, Lubos @.***> wrote:

Closed #1277 https://github.com/hey-api/openapi-ts/issues/1277 as not planned.

— Reply to this email directly, view it on GitHub https://github.com/hey-api/openapi-ts/issues/1277#event-15264716545, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABC3QELVNWVNEFU2BU2BF2D2AH66PAVCNFSM6AAAAABRTY3ANOVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJVGI3DINZRGY2TINI . You are receiving this because you were mentioned.Message ID: @.***>

[karolis-kniuksta-trimble]

Hi @oscarlagatta, this is an issue with the OpenAPI specification. If you want to mark fields as required, you need to use the required keyword.

Probably it's not question for you :). But does it make sense to add "required" attributes to response (GET) models? I'm not sure it makes sense for me to request that for API owners.

[mrlubos]

@karolis-kniuksta-trimble it depends. If the API doesn't declare them as required, that means they might not be present. The API should uphold that contract. In practice, you might find an API where they are always present but the OpenAPI specification is not accurate. I suspect that's the source of this thread above.

If you have control over the spec, you should declare them as required. If not, you might want to clean it up yourself on the client side if you want cleaner types. There should be features related to this in the future so people can fix up specs, but right now it's not a common problem enough

[karolis-kniuksta-trimble]

I mean just logically for me "required" infers a validation. But why would response need to be validated. If I would be developing that API and someone would ask me to mark them as required I would have a lot of questions.

If you have control over the spec, you should declare them as required. If not, you might want to clean it up yourself on the client side if you want cleaner types. There should be features related to this in the future so people can fix up specs, but right now it's not a common problem enough

Well, I guess the whole point of this API generation is that you don't have to do anything manually and can quickly keep it up to date.

But thanks for response! :)

[mrlubos]

@karolis-kniuksta-trimble no, required marks the properties as always present on the object https://json-schema.org/understanding-json-schema/reference/object#required

RE API generation, you need to maintain the OpenAPI specification, that's the manual step. The generated code will be only as good as the input specification provided