-
-
Notifications
You must be signed in to change notification settings - Fork 111
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
fix: handle custom formats with null values #161
base: master
Are you sure you want to change the base?
Conversation
@@ -212,15 +212,15 @@ var compile = function(schema, cache, root, reporter, opts) { | |||
} | |||
|
|||
if (node.format && fmts[node.format]) { | |||
if (type !== 'string' && formats[node.format]) validate('if (%s) {', types.string(name)) | |||
if (type !== 'string' && fmts[node.format]) validate('if (%s) {', types.string(name)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fmts[node.format]
will always be truthy since it's checked in the outer if
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's good observation, but does not affect the fix. the only difference between formats
and fmts
is that fmts
has user supplied custom formats and built-ins.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant that you can remove that part alltogether, since it will always be true:
if (type !== 'string') validate('if (%s) {', types.string(name))
Hmm, I remember having a discussion about this at my former place of work 🤔 I think that in the end, we worked around this ourself, potentially because we thought that the current behaviour was the corect one 🤔 I guess that after this change the following will pass: // schema
{
type: 'object',
properties: {
test: { format: /^a+$/ }
}
}
// input
{ test: 123 } whereas before it would be invalid? This should probably be a breaking change... @johansteffner any comments? |
I just added an assertion to make sure non-string values do not pass
but your concern is the "missing string" type, which I think the format is not solving (in any way) |
Before this patch, only passing a If that is correct this needs to be a breaking change. |
@LinusU the solution we ran with was checking that |
Refs: mafintosh/is-my-json-valid#161 Co-authored-by: Gleb Bahmutov <[email protected]>
Refs: mafintosh/is-my-json-valid#161 Co-authored-by: Gleb Bahmutov <[email protected]>
Refs: mafintosh/is-my-json-valid#161 Co-authored-by: Gleb Bahmutov <[email protected]>
Refs: mafintosh/is-my-json-valid#161 Co-authored-by: Gleb Bahmutov <[email protected]> Co-authored-by: Gleb Bahmutov <[email protected]>
If a custom formatted value (string) has null value and the type allows it, the validation should not fail.
Example that is failing on master and this PR is fixing
Seems this was due to
fmts
vsformats
usage