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
Just played a bit with this, the following runs fine: gad -o [org] -r [repo] [command] --[command-options]
but the following doesn't: gad [command] -o [org] -r [repo] --[command-options]
it leads to:
⏳ Fetching issues...
{ [Error: Empty value for parameter 'owner': null]
defaultMessage: 'Bad Request',
message: 'Empty value for parameter 'owner': null',
code: '400',
status: 'Bad Request',
headers: undefined }
Firstly, I think we should add some validation rules to the options and validate them before performing any http request or writing > anything to the output, in order to provide meaningful error messages when an option is missing or has an invalid value.
The first thing I would validate, now that you removed the interactive mode, is that a valid command has been passed.
Actually running just gad within this PR leads to the very same error (Bad Request, null owner). I would love to get an "help" > displayed in this case (list of all commands with options, same as the README table)
Running gad foobar leads to the same. I would love to get something like Invalid command "foobar". [help] in this case. WDYT?
Secondly, is it expected that global options (e.g. --owner, --repo) must be passed before the command name and options?
I think it would be nice if my 2nd (failing) try had worked as the first one. Is it doable?
That means kind of merging global options with command ones so that neither their order nor their position matters, which makes > sense I think.
The text was updated successfully, but these errors were encountered:
Based on @chalasr 's observations :
The text was updated successfully, but these errors were encountered: