defined() allows null to validate

Describe the bug

Calling defined on any schema will allow null to pass validation, unless required is also included or nullable(false) is called after calling defined.

Discovered while discussing in https://github.com/DefinitelyTyped/DefinitelyTyped/pull/45244.

number().isValidSync(null); // false
number().defined().isValidSync(null); // true (!!)
number().nullable(false).defined().isValidSync(null); // true (!!)
number().required().defined().isValidSync(null); // false

To Reproduce

https://codesandbox.io/s/hopeful-diffie-tp9l7

Expected behavior

defined should only disallow undefined – it should never affect the allowance or disallowance of null.

Platform (please complete the following information):

• Browser: Edge
• Version: 83

[danieldiekmeier]

I also just stumbled over this. In TypeScript, the types don’t match the actual allowed values after validation.

Correct:

const schema = yup.string()
// Inferred type: 
const schema: yup.StringSchema<string | undefined>

Also correct:

const schema = yup.string().required()
// Inferred type: 
const schema: yup.StringSchema<string>

This is the problem case:

const schema = yup.string().defined()
// Inferred type: 
const schema: yup.StringSchema<string>

// The inferred type should be yup.StringSchema<string | null>, because this works:
const x = schema.validateSync(null)
// x now has the inferred type `string`, even though its value is `null`

To make sure the inferred types are correct, you have to call nullable anyway:

const schema = yup.string().defined().nullable(false)
// Inferred type: 
const schema: yup.StringSchema<string>

The documentation for this is correct, but the types are incorrect and led me to a lot of head scratching.

[jquense]

.defined().nullable(false) and .nullable().present() (or notNullOrUndefined) wouldn’t be equivalent and solve slightly different use cases. The former strictly bans null, whereas the latter allows it as a value but fails validation.

e.g.

string().defined().cast(null) // throws TypeError
string().validate(null) // throws ValidationError

but

// validates against undefined and null
string().nullable().present().cast(null) // -> null
string().nullable().present().validate(null) // throws ValidationError

The reason you might want the second but not the first is when parsing server responses, e.g. you fetch from an API, then cast the JSON, manipulate it and then validate after, at which point you want required values to be filled and throw if they aren’t. Mentioning this mostly to clarify my own thinking for when invariably read this months from now contemplating changing something again 😛