Allow defining positional argument #541
Comments
hey @hax, we actually already support this with the concept of a builder and a handler for commands (these can even be provided in sub-modules, how cool is that!). we're in discussion to figure out how to make these features more intuitive, but the current pass is pretty well documented here: https://github.com/yargs/yargs#commandmodule Would love to have you join in on the conversation here regarding version |
@bcoe You mean the 5.x branch already support refine positional argument like option? I will try it. |
@hax should be supported in |
@bcoe Sorry, I still can not find how to refine the argument. (with version 4.8.0-candidate) yargs.command('cmd <arg>')
.number('arg')
.choices('arg', [2, 3, 4]) As my example in the first comment, I expect to define the the constraint (should be a number, should be in 2, 3, 4) of |
I'm confused as well, how would you describe |
@wearhere I confirmed that it only describe options, my question is how to solve the requirements of describing |
@wearhere @hax commands currently only allow for simply positional arguments, but using the commands API you can define options that a command would accept, so: yargs.command('cmd <foo>') only allows for simple values to be provided for
But this would expect the signature, I like the idea of being able to apply the full suite of yargs options to positional arguments, perhaps you could open this as a detailed feature request? |
I actually ended up re-implementing the part of It would be awesome if we could get an equivalent to |
These are all good ideas. Honestly, I too have been annoyed that positional args don't get the same treatment as flagged options. IMO, I wouldn't mind if my CLI accepted either a positional arg or a flagged option for the same value, e.g. something like this: require('yargs')
.command('cmd <x> [y]', 'An exemplar command', (yargs) => {
return yargs
.option('x', {
desc: 'This is a required string',
type: 'string'
})
.option('y', {
desc: 'This is an optional number',
type: 'number',
default: 10
})
}, (argv) => {
console.log(`x: ${argv.x}, y: ${argv.y}`)
})
.help()
.wrap(null)
.argv $ app help cmd
app cmd <x> [y]
Arguments:
x This is a required string [string]
y This is an optional number [number]
Options:
--help Show help [boolean]
$ app cmd hang
x: hang, y: 10
$ app cmd -x hang
x: hang, y: 10
$ app cmd -y 5 -x high
x: high, y: 5 That way, there's not really any need to modify the API; yargs should be smart enough to know when a configured We could probably hack around this without too much drastic refactoring, but I'm convinced we need to move positional arg parsing down to yargs-parser in order to make positional args a first-class citizen when it comes to configuration, parsing, and validation. As it is, positional arg handling is done in yargs after yargs-parser has already been executed, so we end up duplicating logic for each little nuance/feature we want. Unfortunately, this would be somewhat of a big change for yargs-parser, since it'd have to have some knowledge of configured commands, which it currently doesn't have. Not saying it can't be done - it's just gonna take a bit of work to get it right. When I get time, I'll have to start experimenting with yargs-parser to see how much work this will actually be. |
Was this closed on purpose? If so, does this mean the feature is not being considered? For example: |
I don't understand why this issue was closed when the original problem is not solved nor has a viable workaround. As far as I understand the builder function @bcoe mentions can be used to describe the -- options to a command. But not the positional arguments. so, consider the string: Here, I can easily specify allowed values on --hello. Assign a coerce function etc. But with arg I cannot do anything like that. Right? I think this issue deserves to be reopened. |
@tkarls right. I'm also looking for the same behaviour (e.g. coercing) for positional arguments. |
I think @nexdrew makes perfect sense, and I, too, don't understand why this issue was closed. |
I know this is late, but it appears this has been addressed with positionals and flagged options. I've set up command directories with exports.
|
Currently describe/number/string... only apply to option, I expect it would also apply to positional argument.
We also need
arg/args
method likeoption/options
Here is the list of methods or keys of arg/args opt I think could apply to arguments:
The text was updated successfully, but these errors were encountered: