Skip to content

fix: handle custom formats with null values - #161

Open
bahmutov wants to merge 2 commits into
mafintosh:masterfrom
bahmutov:master
Open

bahmutov wants to merge 2 commits into
mafintosh:masterfrom
bahmutov:master

Conversation

@bahmutov

Copy link
Copy Markdown

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

{
    type: 'object',
    properties: {
      foo: {
        type: ['string', 'null'],
        format: 'as'
      }
    }
  }, {formats: {as:/^a+$/}
// object
{foo: null}

Seems this was due to fmts vs formats usage

Comment thread index.js

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))

Copy link
Copy Markdown
Collaborator

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

Copy link
Copy Markdown
Author

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.

Copy link
Copy Markdown
Collaborator

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))

@LinusU

LinusU commented May 1, 2018

Copy link
Copy Markdown
Collaborator

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?

@bahmutov

bahmutov commented May 1, 2018

Copy link
Copy Markdown
Author

I just added an assertion to make sure non-string values do not pass

t.notOk(validate({foo:123}), 'not as if number')

but your concern is the "missing string" type, which I think the format is not solving (in any way)

@LinusU

LinusU commented May 4, 2018

Copy link
Copy Markdown
Collaborator

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 format without a type would still run the format on the value coerced into a string. Thus my example would not pass before, but after this patch, it would let it through.

If that is correct this needs to be a breaking change.

@johansteffner

Copy link
Copy Markdown

@LinusU the solution we ran with was checking that typeof input === 'string' before running the format validator, returning true if the value is not a string.

@LinusU LinusU mentioned this pull request Aug 13, 2018
4 tasks
@LinusU LinusU added this to the 3.0.0 milestone Aug 13, 2018
ChALkeR added a commit to ExodusOSS/schemasafe that referenced this pull request Jun 29, 2020
Refs: mafintosh/is-my-json-valid#161
Co-authored-by: Gleb Bahmutov <gleb.bahmutov@gmail.com>
ChALkeR added a commit to ExodusOSS/schemasafe that referenced this pull request Jun 29, 2020
Refs: mafintosh/is-my-json-valid#161
Co-authored-by: Gleb Bahmutov <gleb.bahmutov@gmail.com>
ChALkeR added a commit to ExodusOSS/schemasafe that referenced this pull request Jun 29, 2020
Refs: mafintosh/is-my-json-valid#161
Co-authored-by: Gleb Bahmutov <gleb.bahmutov@gmail.com>
kklash pushed a commit to ExodusOSS/schemasafe that referenced this pull request Jun 29, 2020
Refs: mafintosh/is-my-json-valid#161
Co-authored-by: Gleb Bahmutov <gleb.bahmutov@gmail.com>

Co-authored-by: Gleb Bahmutov <gleb.bahmutov@gmail.com>
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

Successfully merging this pull request may close these issues.

3 participants