Default validation transformers are too loose

Currently yup’s validation and cast behavior for booleans seems way too greedy: https://tonicdev.com/joshuajabbour/yup-greedy-cast Even with the strict flag, the results are counter-intuitive. Ultimately, I think most people will need to overwrite the default transformer.

Personally, I think the boolean transformer should be more restrictive, and only accept true, false, 'true', 'false', 1, 0, '1', '0'. At the very least, the docs need to detail that 'whatever1' === true, etc. (All the types need transformer documentation actually.)

[joshuajabbour]

Here’s another explanation, using number, which also has this problem (which is even more clear).

• In strict mode, the valid values are 1 and Number(1) (but also Number('whatever')?).
• In non-strict mode, '1', Date() and true/false also become valid “numbers”.
• But there’s no way to get '1' as valid, without also getting those other, less obvious values to be considered valid.

I guess the problem is that what is considered “valid” is all over the place (and not documented at all). I’m trying to use yup to validate REST API input, so everything comes in as strings. I’d love yup to smartly coerce my values, but it seems like I’ll need to reimplement every transformer to get that to happen.

[joshuajabbour]

If you run validate with strict false only the the validation pipeline is run, and you validate exactly what you put in. when it’s true it runs the transform pipeline, then passes the output to the validation pipeline

Pretty sure you got that backwards.

Strict doesn’t affect cast because its not an option of cast, a “strict” cast would be a complete noop, it would just be value => value. It makes no sense to “strictly” cast something.

Sure not for a strict value, but not everything has to be strict. Look at this example, where I have the age field set to strict. Otherwise, what is the point of the .strict() method? If I had the following, I’d expect a .cast() to ignore age, but coerce date, just like .validate() does the right thing here:

yup.object().shape({
  age: yup.number().strict().required().positive().integer(),
  date: yup.date()
})

Now maybe this is a problem with the documentation, where this isn’t explained. So maybe I’m making some assumptions here. But what I describe is sure what I’d like to happen.

This is incorrect, that is the only thing cast does.

Ok, this is due to me misreading/misunderstanding the default transforms (again). The date string gets converted to 2016 because it’s a string, a Date object gets converted to a timestamp.

I appreciate that it doesn’t make sense for those things to be distinct for you.

It makes total sense they are separate, I have no problem with that. But per above, it just shouldn’t be all or nothing. The way it works now is both too opinionated (because the default transforms), and not flexible enough (due to all or nothing casts).

The likelihood that we will ever agree is far fetched, not just because we differ but because its arbitrary and use case-specific.

Exactly what I’ve tried to say many times. Too much opinion, too hard to override.

it is hard to change the default type transforms. As I care about being flexible and configurable it seems like that is worth fixing.

Yes this is the key (plus the fact that it’s not documented).