Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

add S.raw #55

Closed
aboutlo opened this issue Dec 7, 2019 · 3 comments
Closed

add S.raw #55

aboutlo opened this issue Dec 7, 2019 · 3 comments

Comments

@aboutlo
Copy link
Collaborator

aboutlo commented Dec 7, 2019

馃殌 Allow injecting a raw JSON directly in fluent-schema

Motivation

A few users asked:

  • add custom implementation related to AJV or other JSON Schema validation tools.
  • inherited schema from a JSON schema and not our wrapper

ref. #51 #16 #47

Examples

S.object()
  .prop('foo', S.integer())
  .prop('myKeyword', S.raw({true})
S.definition(S.raw({ foo: 'bar'}))
S.object().prop('foo').extend(S.raw('{"bar": { "type": "string"}}'))

In order to implement that we need to implement a parser to build the fluent-schema internal data structure based on the raw JSON.

https://github.com/fastify/fluent-schema/blob/master/src/ObjectSchema.js#L13

 {
  type: 'object',
  definitions: [],
  properties: [],
  required: [],
}
This was referenced Dec 7, 2019
@firasdib
Copy link

We currently use fastify with fluent schema which works well, but we've hit a snag with the openapi spec that we try to generate from the json schema, when it comes to null values. If we want to return say a string or null, we have to do something along the lines of S.anyOf([S.string(), S.null()]) which generates the following openapi spec:

anyOf:
   - type: 'null'
   - type: string

This is unfortunately invalid. Instead, we should be setting the type to string, with the nullable option to true (see https://swagger.io/docs/specification/data-models/data-types/).

My understanding is that this is a clash between the JSON schema specification and the openapi specification.

Do you think using S.raw() could bridge this gap, or is this something we won't be able to get around?

@aboutlo
Copy link
Collaborator Author

aboutlo commented Dec 19, 2019

Rather than use S.anyOf([S.string(), S.null()])
We could have:

S.object()
  .prop('foo', S.raw({type: string, nullable:true}))

But then if you are using AJV to validate you will face other issues: ajv-validator/ajv#486

As you said, currently, there are discrepancies between Swagger and JSON Schema draft 7.
AFAIU the JSON Schema 2019-09 could fix your issue but the environment is changing: https://phil.tech/2019/09/07/update-openapi-json-schema/

I'm interested in your use cases. I would like to write in fluent-schema and having my endpoints documented with Swagger UI. Is that your goal?

@firasdib
Copy link

According to the AJV docs they should have support for nullable.

Yes, I have the same goal as you.

aboutlo added a commit that referenced this issue Dec 27, 2019
@aboutlo aboutlo mentioned this issue Dec 27, 2019
7 tasks
aboutlo added a commit that referenced this issue Jan 24, 2020
* S.raw draft #55

* Add node 12.x

* Switch default to node 12.14

* Fix types

* turn on noEmit again

* fix typo

* Uptated to the latest version of AJV and added AJV custom keywords package

* Added .raw method on each Schema

* Cleanup and doc

* Fix coverage and update doc

* Add more tests about S.raw

* Extracted Raw as a Schema

* Add an integration test for AJV and $data

* Add a check that the Fragment is an object
@aboutlo aboutlo closed this as completed Jan 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants