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

Validate parameters #13

Open
Tom32i opened this issue Jun 28, 2017 · 0 comments
Open

Validate parameters #13

Tom32i opened this issue Jun 28, 2017 · 0 comments

Comments

@Tom32i
Copy link
Contributor

Tom32i commented Jun 28, 2017

Based on @chalasr 's observations :

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.

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

No branches or pull requests

1 participant