Config for ignoring conditions when generating openapi schema

[chivalryq]

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

We have parameters struct like:

#Parameter:{
	a: int
	b: *"foo"|"bar"
	if b == "foo"{
		c: string
	}
	if b=="bar"{
		d: string
	}
}

We want to generate OpenAPI schema for struct like above. When generating it with cue CLI, the d: string will always be ignored because default value of b is "foo"

result of

cue eval param.cue --out=openapi

{
    # omitted...
    "components": {
        "schemas": {
            "Parameter": {
                "type": "object",
                "required": [
                    "a",
                    "c",
                    "b"
                ],
                "properties": {
                    "a": {
                        "type": "integer"
                    },
                    "c": {
                        "type": "string"
                    },
                    "b": {
                        "type": "string",
                        "enum": [
                            "foo",
                            "bar"
                        ],
                        "default": "foo"
                    }
                }
            }
        }
    }
}

As we are doing this by code, I search the Config field in encoding/openapi/openapi.go. But it doesn't seems to have related field to config this behavior. Also nothing related in encoding/openapi/openapi_test.go

I think it's a reasonable demand because the field d can be used when b is set to something else, it's just can't be set when b keeps the default value.

Describe the solution you'd like A clear and concise description of what you want to happen.

Add one config for ignoring the conditions expression (or expand them?) when generating the openapi schema.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context Add any other context or screenshots about the feature request here.

[FogDong]

This one's priority is medium. Though there's no workaround, it will not block our generator for open-api. I'll say this is a user-facing problem since we're generating docs from cue parameters for our users. No time constraint. According to the discussion with Paul offline, this seems like a bug. Looking forward to more investigation.

[mpvl]

This is best explored after the release of required fields in v0.6, which should make the distinction between schema and template clearer.