You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current description has two properties for identified options, and an option with a value appears in both:
args {Object}, having properties and Boolean values corresponding to parsed options passed
values {Object}, have properties and String values corresponding to parsed options passed
I found this a bit unexpected, and unlike what I see in other implementations (Commander, Yargs, et al).
If this a deliberate design decision? I didn't find any discussion that led to this, and don't want to go too deep on commentary if it is a somewhat accidental iteration as functionality has been added!
@shadowspawn If I recall, one of the reason for the two return values, was so that you could differentiate between the case where an option was passed no argument, vs., an option not being set at all.
I think in practice someone would tend to use either args or values, but someone building a more copmlex command line application on top of the parser would be able to look at values vs., `args, and infer more information about what the user provided.
Activity
bcoe commentedon Nov 14, 2021
@shadowspawn If I recall, one of the reason for the two return values, was so that you could differentiate between the case where an option was passed no argument, vs., an option not being set at all.
I think in practice someone would tend to use either
argsorvalues, but someone building a more copmlex command line application on top of the parser would be able to look atvaluesvs., `args, and infer more information about what the user provided.shadowspawn commentedon Nov 15, 2021
Thanks for recollections. Not convinced yet, but happy to wait and see! (How code develops, what gets stored, what client code looks like.)