fix: removed NameValidations to properly show default values

[domagojk]

For stoplightio/platform-internal#9043

I couldn't find the reason why NameValidations were used for boolean types so I removed it 🤷‍♂️

Now, in case of

"defaultExample1": {
  "type": "boolean",
  "default": true
},
"defaultExample2": {
  "type": "boolean",
  "default": false
}

It shows:

Rather than displaying Default in case default: true and nothing in case of default: false.

Besides that, I noticed it also fixed the issue with some other boolean types like:

"something": {
  "type": "boolean",
  "example": true
}

Which is was previously displayed as:

@mallachari Do you remember why was NameValidations needed for booleans? Is there some cases that i'm not seeing which this PR could broke?

[P0lip]

boolean types

it's not boolean types, but boolean-ish validations, like, say

exclusiveMinimum: true

I know it's not the best example since it's draft 4, but hopefully you get the idea.

[P0lip]

you prob want to revert it and simply add default to excluded validations

[domagojk]

that excludes it both from booleanValidations and keyValueValidations but I want them to still show in keyVal ones. But I can fix that. I'm just wondering, Is there any usecase where it makes more sense to use NameValidations rather than KeyValueValidations?

Because, if the value is true or false I think it makes more sense to display it using KeyValueValidations, so it says default: true rather than Default. Same for example or even for exclusiveMinimum (which wont be shown here because it falls in numberValidations)

[P0lip]

Is there any usecase where it makes more sense to use NameValidations rather than KeyValueValidations?

That's a good question... I'm not really sure whether we actually have any booleanish validations left now that we filter out default, readOnly, writeOnly, and everything related to numbers is handled separately.

I think it makes more sense to display it using KeyValueValidations, so it says default: true rather than Default

I agree

[mallachari]

We used NameValidations before because some of they sounded better this way (the property name was enough) it ie. deprecated, readOnly, writeOnly etc. Default can be any type, but agree that as boolean it might look weird. If it makes more sense to change it given those validations are represented differently now then go ahead, I think it's fine.

[domagojk]

Gotcha. Yea I think most of them are handled differently now (all those mentioned included)

[domagojk]

Ok @P0lip @mallachari then my suggestion is to leave the PR as is, which means, in case we missed any "booleanish validation" it will just be represented with KeyValueValidations rather than NameValidations.

And in case there is some we are missing, we can bring it back, but I would do it explicitly this time (not by default like now)

Approve if you agree 😄

[P0lip]

ajmo

[stoplight-bot]

🎉 This PR is included in version 4.3.6 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀