This ensures it is possible to allow unknown properties in request bodies (Postel’s Law), by respecting the x-hapi-options option.
Discussion
In general, one could consider making allowUnknown: true the default behavior, but I guess that would be considered a breaking change.
Some notes from the thought processes around this change:
The server wide route option (where this could be set) is apparently not respected by hapi-openapi (probably because validation is overwritten?). Otherwise, that would've been a nice way to avoid this custom property.
Just providing the validation option does not seem to cut it, since options.validator is overwritten. Avoiding overwriting the provided option (options.validate = Object.assign({}, v.validate, options.validate); did not solve the problem. Hence, I decided to make it an explicit option that trickled down the creation of the validator.
I decided not to strip the unknown properties, because it's a different property in Hapi (and not necessarily wanted just because unknowns are allowed).
If there's a better way to solve this, I'm all ears, but this was fairly straightforward and did solve the issue.
This ensures it is possible to allow unknown properties in request bodies (Postel’s Law), by respecting the
x-hapi-options
option.Discussion
In general, one could consider making
allowUnknown: true
the default behavior, but I guess that would be considered a breaking change.Some notes from the thought processes around this change:
options.validator
is overwritten. Avoiding overwriting the provided option (options.validate = Object.assign({}, v.validate, options.validate);
did not solve the problem. Hence, I decided to make it an explicit option that trickled down the creation of the validator.If there's a better way to solve this, I'm all ears, but this was fairly straightforward and did solve the issue.