Understanding the opinionated nature of this library

[JaredCE]

Checklist

• Validation: I believe my source definition is valid OpenAPI 3.0.x but the validator complains

Detailed Description

I'm trying to understand the opinionated nature of the validator library. It seems like it forces some things on to you like:

{
  anyOf: [
    { type: 'array', items: { type: 'string' } },
    {
      type: 'object',
      additionalProperties: { enum: [ 'commonjs', 'module' ] }
    }
  ],
  default: [ 'cjs', 'mjs', 'js' ]
}

will fail because it is missing a type field, even though the specs don't seem to suggest it's required. Equally if i try to massage an if/then/else into a valid draft-04 from:

"if": {
        "properties": {
            "country": {
                "const": "United States of America"
            }
        }
    },
    "then": {
        "properties": {
            "postal_code": {
                "pattern": "[0-9]{5}(-[0-9]{4})?"
            }
        }
    },
    "else": {
        "properties": {
            "postal_code": {
                "pattern": "[A-Z][0-9][A-Z] [0-9][A-Z][0-9]"
            }
        }
    }

to

oneOf: [
  {
  allOf: [
    {
       "properties": {
            "country": {
                "const": "United States of America"
            }
        }
    },
    "properties": {
            "postal_code": {
                "pattern": "[0-9]{5}(-[0-9]{4})?"
            }
        }
  ]
  },
  {
  allOf: [
    {
      not: {
        "properties": {
            "country": {
                "const": "United States of America"
            }
        }
      }
    },
    "properties": {
            "postal_code": {
                "pattern": "[A-Z][0-9][A-Z] [0-9][A-Z][0-9]"
            }
        }
  ]
  }
]

it will complain that

"properties": {
            "postal_code": {
                "pattern": "[0-9]{5}(-[0-9]{4})?"
            }
        }

needs to be in its own schema components reference.

Other stuff

[MikeRalphson]

Are you sure it's not indentation / { [ mismatches (as above in red) which are causing your issues. This project isn't opinionated about type being present AFAIR.

[JaredCE]

Hey @MikeRalphson. I don't believe there are any mismatches there, if i copy and paste the first example into runkit.com as:

const a = {
  anyOf: [
    { type: 'array', items: { type: 'string' } },
    {
      type: 'object',
      additionalProperties: { enum: [ 'commonjs', 'module' ] }
    }
  ],
  default: [ 'cjs', 'mjs', 'js' ]
}

It doesn't complain about mismatching brackets.

I'm seeing a similar issue from a user of my library here: JaredCE/serverless-openapi-documenter#89

Where type is not defined in the object but in the allOf. Running the as-is schema here https://www.jsonschemavalidator.net/s/EexTxvSB shows it to be valid, but it seems your openAPI validator claims the schema is invalid.

I'm messing about right now, but if i get time later i'll try and put together a small reproducible...

[MikeRalphson]

I wonder if it's the presence of default without a direct sibling type that is triggering a rule for OAS 3.0 that defaults must be of the right type. What version of the library are you using?

[JaredCE]

"oas-validator": "^5.0.8",

[JaredCE]

this is a reproducible, but runkit.com is terrible at outputting the error, so you might want to run it locally:

https://runkit.com/jaredce/openapi-scenario

[MikeRalphson]

I've corrected the OpenAPI syntax and confirmed that it is the presence of default that is triggering the error. In this case you/the OP should move the default into the anyOf subschemas.

https://runkit.com/mikeralphson/63f2530128ff200008363ec7

[MikeRalphson]

One thing you could do is set options.laxDefaults to true, as per https://github.com/Mermade/oas-kit/blob/main/docs/options.md#options-documentation