Orval does not support optional by default requestBody that OpenAPI 3.0 specifies

[Jon-Mallozzi]

Hi, the fix for #1111 did not support the optional by default which is in the OpenAPI 3.0 spec [1] as originally requested. It only seems to handle the required: false value.

In my project, I have in the OpenApi Spec

"requestBody": {
          "content": {
            "application/json": { "schema": { "$ref": "#/components/schemas/BodyDto" } }
          }
        }

The backend expects no body to have certain behavior happen. When the backend generates the OpenApi spec, it knows it's optional with no required field, so it always generates nothing for required.

Generating with "orval": "7.7.0" doesn't create my axios request function with an optional body:

BodyDto: BodyDto,

but if I set required: false manually in the OpenApi spec the backend provides it does generate as optional:

BodyDto?: BodyDto,

The issue is whenever the backend generates the OpenApi spec for the frontend it will overwrite the require: false so I think proper optional body support is needed.

What are the steps to reproduce this issue?

1. Do not have the required in the requestBody
2. The schema object doesn't generate as optional

What happens?

The request body is not optional.

What were you expecting to happen?

The request body to be optional.

Any logs, error output, etc?

No

Any other comments?

No

What versions are you using?

Package Version: 7.7.0

[AllieJonsson]

I think the decision was made by anymaniax to not follow the OpenAPI specification in the linked pr

[melloware]

Agree with @AllieJonsson this is by design.

[melloware]

The workaround is to explicitly add the required option in your OpenApi so it's explicit the intent.

[seschis]

@melloware I think the decision to selectively follow the openapi specification is shortsighted will cause more issues like this. There are openapi json generators that follow the specification in this regard and do not output required: false when its not needed because that is the default in the specification.
Those tools don't play well with tools that decided to diverge from the specification, like orval in this instance, and causes a waste of developer time to track down the problem to something like this issue when it never had to be an issue in the first place.
what good is a specification like openapi if people are allowed to selective choose what behaviors they want to implement?

[melloware]

@anymaniax thoughts?