-
Notifications
You must be signed in to change notification settings - Fork 56
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
Allow using non-standard formats #16
Comments
I need to dig into the specification but it doesn't seem a good idea to add a flavor. Maybe I'm too careful. Let me think more about that. @mcollina thoughts? |
IMHO it’s a bad idea, but a lot of people ask/need this. Providing some sort of escape hatch to add this would be good to accept as a PR. |
The spec says:
In our case this is useful for reducing boilerplate in schemas within a shared domain. It is more readable to specify a semantic format rather than to repeat I will be happy to submit a MR if you specify how the API should look. |
I don't like to add a
In the JSDoc of the format method, we could add the above example Then in the format implementation, we can merge Name wise I don't like too much Test wise we have do double check that in a nested schema the extraFormats are propagated to the children. It should I did a refactoring in the 0.3.0 version so it should. 🤞 |
Moved the discussion here: #55 |
Thanks @aboutlo, support for raw JSON injection is quite a good compromise. |
The
format
method checks if the passed format is supported by the specification. However, validator can support custom, non-standard formats, for example Ajv has addFormat method. Would it be possible to allow passing non-standard format?To maintain current behavior, perhaps it could be a different method, for example:
The text was updated successfully, but these errors were encountered: