serializing null value crash fix

[mum-never-proud]

resolves #218

Checklist

• run npm run test and npm run benchmark
• tests and/or benchmarks are included
• documentation is changed or added (not needed)
• commit message and code follows Code of conduct

[mcollina]

Good work!

[simoami]

@mum-never-proud Thanks for the quick PR. What about substituting $asString(date) with $asStringNullable(date) since in that conditional branch date can still be null.

[simoami]

@mum-never-proud
I suggest that we drop the format attribute from the basic tests and add the following date format specific tests to date.test.js:

Test 1

test('should render a null value', (t) => {
  t.plan(2)

  const schema = {
    title: 'an object in a string',
    type: 'object',
    properties: {
      date: {
        type: ['string', 'null'],
        format: 'date-time'
      }
    }
  }
  const toStringify = { date: null }

  const validate = validator(schema)
  const stringify = build(schema)
  const output = stringify(toStringify)
  t.equal(output, JSON.stringify(toStringify))
  t.ok(validate(JSON.parse(output)), 'valid schema')
})

Test 2

test('should fail validation on unexpected null values', (t) => {
  t.plan(2)

  const schema = {
    title: 'an object in a string',
    type: 'object',
    properties: {
      date: {
        type: 'string',
        format: 'date-time'
      }
    }
  }
  const toStringify = { date: null }

  const validate = validator(schema)
  const stringify = build(schema)
  const output = stringify(toStringify)
  console.log(output)
  t.equal(output, JSON.stringify(toStringify))
  t.notOk(validate(JSON.parse(output)), 'valid schema')
})

There are some interesting things about the second test:

• As is, it will fail because the output will be {"date": ""} instead of {"date":null} from the native JSON.stringify(), so the equality check fails. This proves my point about replacing $asString(date) with $asStringNullable(date) in my previous comment so that null is not stringified. We should replicate these 2 tests for other date/time formats and potentially also use the same patches there.
• What's interesting here is that if you specify the type as ['string'] instead of 'string' the output comes out as expected {"date":null}. Might be good to track why it has a different behavior.

[Eomm]

This proves my point about replacing $asString(date) with $asStringNullable(date)

No, if you set type: string you want a string and null is not a string, so the type is coerced to an empty string. This is right.
You should use nullable or type[string, null] to get null as output.

Might be good to track why it has a different behavior.

The fix didn't cover it, I have suggested what should solve

[Eomm]

Could you duplicate the tests for date and time format?
So we will have complete coverage of the changes!

Thanks for your patience! 💪

[mum-never-proud]

my naming convention might suck, let me know for any changes :)

[mcollina]

lgtm, thanks!

[Eomm]

only last fixes on test messages

then we can land it!