feat: Add NullableFromType option

[candiduslynx]

Instead of #106.

Allows to define property nullability based on the field type instead of the jsonschema:"nullable" tag.
Useful when the types included are referenced from 3rd party packages.

Consider the following example:

type TestNullableField struct {
	A *string `json:"a"`
}

The following JSON is a perfectly valid value for Go:

{
  "a": null
}

The schemas produced for the TestNullableField struct are:

Old behavior (`NullableFromType:false`)

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://github.com/invopop/jsonschema/test-nullable-field",
  "$ref": "#/$defs/TestNullableField",
  "$defs": {
    "TestNullableField": {
      "properties": {
        "a": {
          "type": "string"
        }
      },
      "additionalProperties": false,
      "type": "object",
      "required": [
        "a"
      ]
    }
  }
}

New behavior (`NullableFromType:true`)

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://github.com/invopop/jsonschema/test-nullable-field",
  "$ref": "#/$defs/TestNullableField",
  "$defs": {
    "TestNullableField": {
      "properties": {
        "a": {
          "oneOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ]
        }
      },
      "additionalProperties": false,
      "type": "object",
      "required": [
        "a"
      ]
    }
  }
}

In both cases a is required, but the old behavior will fail for {"a":null} whereas the new one will succeed.

[candiduslynx]

@samlown this is a less intrusive implementation for #106.
It will kick in the new logic only if the NullableFromType option is used.

[candiduslynx]

@samlown I hope you're doing well in these uneasy days.

I've implemented the changes in #109 & #110 & tested them via a fork at github.com/cloudquery/jsonschema@cqmain.

The results of using the updated code along with NullableFromType: true, RequiredFromJSONSchemaTags: true is something I'm quite satisfied with.
You can find an example in schema.json file. It includes both the nullable properties based on the field type & the clashing types (you can easily find them searching for -1" suffix)).

Could you please give an estimate when these PRs (#109 & #110) could be merged? It'll be far easier to pin an upstream version instead of maintaining a fork for these 2 changes.

[kop]

Highly interested in this PR as well. Is there anything I can help with to get this merged?

[candiduslynx]

Highly interested in this PR as well. Is there anything I can help with to get this merged?

@kop I really hope @samlown has time to review/merge that.
In the meantime, we use a fork at github.com/cloudquery/jsonschema. It has cqmain default branch, that has the following PRs merged:

• fix: Proper handling of clashing types case #109
• feat: Add NullableFromType option #110
• fix: Don't limit the explicit format #111
• fix: Key construction in ExtractGoComments #112

[samlown]

Sorry for the delay there! This looks good to me, thanks! I do think there should be some extra tests for those non-pointer reflection types though.

[samlown]

I do think there should be specific tests for these types. I also wonder if Interface and UnsafePointer are really necessary, if so, there should be a test to show it ;-)

[candiduslynx]

@samlown I've added the tests in be77f3d

I can see the appeal to remove both Interface & UnsafePointer as well, so I can update the code accordingly, if you insist.

I also updated the code to actually handle a more varied cases like map[string]*int or *[]*int & included that in tests.

[candiduslynx]

@samlown thanks for the review!

I have an additional question here: currently the library uses oneOf to make schema nullable.
In my opinion, a better way would be anyOf:
If the schema is already nullable (e.g., it already is {"oneOf":[{...}, {"type":"null"}]}) then adding another oneOf layer will effectively make null value to fail validation, as the oneOf requires one & only one variant to be valid:

{
  "oneOf": [
    {
      "oneOf": [
        {},
        {
          "type": "null"
        }
      ]
    },
    {
      "type": "null"
    }
  ]
}

If we use anyOf this is lifted to at least one of the variants.

I can raise this as a separate issue & address it in a follow-up PR.
WDYT?

[elise-prequel]

Hi! Echoing interest in this PR -- happy to help if there's anything outstanding to get it in.