Narrow down ExpressJoiError type to assume the Joi.ValidationResult is an error #46
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
👋
While writing some error handling middleware using ExpressJoiError I noticed that the type also includes the non-error type of the
Joi.ValidationResult
:I assume (and correct me if I'm wrong!) that the ExpressJoiError is only raised when the
Joi.ValidationResult
contains the error field. If that is true thenExtract
ing the error variant of the type will result in a more narrow type to use.Additionally I've also added the
TSchema
generic type on the ExpressJoiError that's passed into theJoi.ValidationResult
to allow for more accurate handling when it comes to the schema that raised the error.