The current required validation approach is a "one size fits all" in terms of what is considered invalid when a prompt is required.
For a text prompt, an empty string from the user shouldn't be accepted when the prompt is required. But with a select prompt, it's possible to pass an empty string key as one of the configured options (potentially as a marker for something), and it seems unreasonable that a configured option would cause a validation error by default.
This PR addresses this by allowing each prompt to configure what should be considered invalid when the prompt is required. For now, I don't see a need to configure this for every prompt, so I've kept the current values as the "default" set and just updated the SelectPrompt with an override.
It's still possible to add a custom validation handler to prevent a configured option from being selected if needed.
It was also pointed out in #98 that setting the $required value to an empty string would disable validation due to truthy check, so I've also tightened this up.
The current
requiredvalidation approach is a "one size fits all" in terms of what is considered invalid when a prompt is required.For a
textprompt, an empty string from the user shouldn't be accepted when the prompt is required. But with aselectprompt, it's possible to pass an empty string key as one of the configuredoptions(potentially as a marker for something), and it seems unreasonable that a configured option would cause a validation error by default.This PR addresses this by allowing each prompt to configure what should be considered invalid when the prompt is required. For now, I don't see a need to configure this for every prompt, so I've kept the current values as the "default" set and just updated the
SelectPromptwith an override.It's still possible to add a custom validation handler to prevent a configured option from being selected if needed.
It was also pointed out in #98 that setting the
$requiredvalue to an empty string would disable validation due to truthy check, so I've also tightened this up.Fixes #98.