Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Additional parameters for coercing functions #1207

Closed
vonagam opened this issue Mar 3, 2020 · 2 comments
Closed

Additional parameters for coercing functions #1207

vonagam opened this issue Mar 3, 2020 · 2 comments

Comments

@vonagam
Copy link
Contributor

vonagam commented Mar 3, 2020

If you want to throw an error in a coercing function because a received string value does not satisfy some requirement you might want to have access to an option name (or a command name) to customise an error message.

How about changing coerce signature?

// from
(value: string, previous: T) => T
// to
(value: string, previous: T, option: Option, command: this) => T

One will be able to use long, name() or attributeName() from Option to customise a message. Also negate property is useful. None of those are accessible right now.

command can be used to get its name for an error or currently parsed options if a person wants to change coercing behaviour based on already present options. User already has access to command, so nothing new in terms of access, just convenience.

@shadowspawn
Copy link
Collaborator

This is an interesting suggestion thanks, and aligns with the name shortcoming I noticed when I was writing a custom validator recently: #518 #1130

Fair warning though, we are not going to rush a change. The previous changes to the parameters for the coercion function caused a lot of problems, in particular by breaking parseInt: #943 (The next change should hopefully be less problematic!)

The support for a RegEx to validate the option values has been removed from the documentation as underdelivering, and I commented there I thought the custom option processing was a better longterm approach: #967

Providing an array of allowed values for an option (#518) is one of the two most upvoted open issues.

Interested in seeing interest in this, and whether it looks a good approach for allowing the custom option processing to solve questions that come up.

@shadowspawn
Copy link
Collaborator

shadowspawn commented Sep 26, 2020

There will be more possibilities in Commander v7, with one coercing function moved down into the Option: #1331

This issue has not had any activity in over six months. It isn't likely to get acted on due to this report.

Feel free to open a new issue if it comes up again, with new information and renewed interest.

Thank you for your contributions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants