-
-
Notifications
You must be signed in to change notification settings - Fork 29
Add json-schema support #118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: 4.x
Are you sure you want to change the base?
Conversation
|
Hello @kerwanp The high-level approach looks fine to me. However, I will have a few changes.
Also, once we merge this PR, Vine will support JSON schema as a first-class citizen and all custom schema types must implement the |
|
Also, we should write some tests for the |
|
Thanks for the feedback! I added support for Concerning the I also started the implementation of integration tests that validate values against the generate json-schema using ajv. This can help use spot issues with the complexity of some generated schemas (tuples, records, etc). What do you think? I we are good with the implementation I will start expanding the test cases, cleaning up my work and add some comments |
Yeah, this seems like a great strategy.
I will be okay with a more generic approach. However, the issue is, how do we know which properties to merge with the JSON schema? |
LIbraries like Zod provide a |
Cool, let's go with that. Maybe people can rely on the JSONschema properties for their other needs as well. |
|
@kerwanp What are the next steps for this PR? Do you need any feedback from me? |
Hi, I am currently in vacations, will be back the 8th to finish this PR and I think I have all the information required |
|
I've implemented the different integration tests, it helped me identify a lot of different edge cases. I will now start updating the existing tests as some of them now contain the JSON schema (286 of them...). We could either avoid using deep equal or simply bring the json schema in the expected results. Also it seems that the reference ids are now calculated in different orders with my changes, what is the impact? Object {
"conditions": Array [
Object {
- "conditionalFnRefId": "ref://2",
+ "conditionalFnRefId": "ref://1",
"schema": Object {
"allowNull": true,
"bail": true,
"fieldName": "*",
"isOptional": false,
+ "jsonSchema": Object {
+ "type": "null",
+ },
"parseFnId": undefined,
"propertyName": "*",
"subtype": "null",
"type": "literal",
"validations": Array [],
},
},
Object {
- "conditionalFnRefId": "ref://3",
+ "conditionalFnRefId": "ref://2",
"schema": Object {
"allowNull": false,
"bail": true,
"fieldName": "*",
"isOptional": false,
+ "jsonSchema": Object {
+ "enum": Array [
+ "1",
+ 1,
+ "true",
+ true,
+ "on",
+ "0",
+ 0,
+ "false",
+ false,
+ ],
+ },
"parseFnId": undefined,
"propertyName": "*",
"subtype": "boolean",
"type": "literal",
"validations": Array [
Object {
"implicit": false,
"isAsync": false,
"name": "boolean",
- "ruleFnId": "ref://4",
+ "ruleFnId": "ref://3",
},
],
},
},
Object {
- "conditionalFnRefId": "ref://5",
+ "conditionalFnRefId": "ref://4",
"schema": Object {
"allowNull": false,
"bail": true,
- "dataTypeValidatorFnId": "ref://6",
+ "dataTypeValidatorFnId": "ref://5",
"fieldName": "*",
"isOptional": false,
+ "jsonSchema": Object {
+ "type": "string",
+ },
"parseFnId": undefined,
"propertyName": "*",
"subtype": "string",
"type": "literal",
"validations": Array [],
},
},
],
- "elseConditionalFnRefId": "ref://1",
+ "elseConditionalFnRefId": "ref://6",
"fieldName": "*",
+ "jsonSchema": Object {
+ "anyOf": Array [
+ Object {
+ "type": "null",
+ },
+ Object {
+ "enum": Array [
+ "1",
+ 1,
+ "true",
+ true,
+ "on",
+ "0",
+ 0,
+ "false",
+ false,
+ ],
+ },
+ Object {
+ "type": "string",
+ },
+ ],
+ },
"propertyName": "*",
"type": "union",
}
|
124e2d5 to
f6d3331
Compare
e5625c5 to
cb607d0
Compare
|
Hey @thetutlage! This pull-request is finally ready to be merged! I made a big change by moving out completely the json-schema computation out of the
|
|
Hello @kerwanp The PR looks great. Thanks for putting in the efforts I remember you had plans to test the JSON schema output against |
|
@thetutlage It might deserve more in depth testing but you can find tests against |
🔗 Linked issue
❓ Type of change
📚 Description
This feature adds the ability to transform validators to json-schema using the
toJSONSchemamethod.This will open a lot of doors for libraries that can build around the json-schema standards (openapi generation, form builder, configuration files, etc).
Implementation
This is currently a draft and serves as an implementation proposal.
The json-schema is computed when calling
toJSONSchemaon a schema. It can also be computed on the validator with the difference that it is computed only once.Each type can include
toJSONSchemawhich must return a valid json-schema. If a type does not include it it returns an empty json-schema{}which is considered as anAnytype.When creating rules, it is possible to pass an optional parameter for altering the json-schema.
The user is able to provide custom meta that will be merged with the schema to provide custom parameters.
📝 Checklist