parse vs parseAndExit about sywac HOT 11 CLOSED

I am AFK right now, but concerning when to use parse vs parseAndExit, they are not designed to be interchangeable, your CLI should use one or the other.

parseAndExit is a special case only meant for "simple" use-cases where you want your CLI to exit if validation fails or if a command reports an error via cliMessage. parseAndExit resolves to the parsed argv object, which is just one property of the entire parsing result.

parse is meant for all other cases, resolving to the entire parsing result, and it never exits the app - any errors that occur are included in the result, your app would have to handle them (decide what to do) on its own.

from sywac.

I am AFK right now, but concerning when to use parse vs parseAndExit, they are not designed to be interchangeable, your CLI should use one or the other.

OK

Most of the time parse does what I need, and parseAndExit does not.

but: parse doesn't print about, version, help (generic, command specific (incl specific messages)).

So: If I use only parse, the end user has no idea how to use the Cli as there is no help, about, version, etc. If I use only parseAndExit The commands that run, won't.

So you can probably see the predicament. If I use one or the other, which would you suggest, and how would you suggest I work around the issues that come with either of the options?

Thanks.

from sywac.

There's no magic to parseAndExit - this is what it does:

You could do something similar. If help was requested, or if there is an error to report, the content to display will be given in result.output as a string. The reason parse doesn't print it to the console for you is that it makes no assumptions about which stream or medium to use - for instance, if you were using sywac to build a chatbot, printing to the console (stdout) would not be relevant.

from sywac.

Understood, but this doesn't seem to be working. As I mentioned above, when I run test <unknownOption> ([known command] ) result.output is empty string. The test command has everything it needs to run, but I provided an additional piece of text that is meaningless, I'd expect a help message that informs the user that the <unknownOption> is invalid.

Do I need to add something extra to the test command setup, or am I missing something else?

Thanks.

from sywac.

What you describe is known as "strict" mode in yargs.

Sywac does not support "strict" mode out-of-the-box; rather, any unknown flags are parsed on a best-effort basis and added as keys in argv, and any unknown commands/positionals are added as values to the argv._ array.

If you want to use "strict" mode with sywac, you'll need to write some custom validation code. I recommend using a .check() handler.

from sywac.

I replaced my shouldParseAndExit function with the .check() function call and the passed handler doesn't get called. the .check() function is called, but the handler is not.
I just tested by running the programme with a random string as it's first arg/command.
What causes the handler to be called?

I see there is a check for shouldCoerceAndCheck, but I'm not aware of that option, do I need to know about that, if so, can you tell me about it?

I also see on the .check docs you provided a link for, that it says

Define any custom validation logic to run after all types have been parsed, validated, and coerced. The handler will not be called if help or version are explicitly requested.

I noticed that when I used parseAndExit instead of my default of parse that help was displayed, obviously help or version wasn't explicitly requested, but I guess it was implicitly requested, is this the problem?

Thanks.

from sywac.

How about something like this? https://gitlab.com/nexdrew/purpleteam/compare/master...fix-cli

If you pass unknown args to the test or testplan command, it will fail-fast and display an error message.

If you pass unknown flags, they are simply ignored and the command is run.

If you pass an unknown command, the top-level help content is displayed (this is due to .showHelpByDefault()).

One thing I noticed is that you are catching API errors in the code that is called by the test command, which means the CLI code won't know that anything went wrong and will exit the process with a normal (0) exit code.

from sywac.

This seems to work well, except...

One thing I noticed is that you are catching API errors in the code that is called by the test command, which means the CLI code won't know that anything went wrong and will exit the process with a normal (0) exit code.

This is why I was using parse most of the time, so the application (not cli) errors could be handled by the blessed screen in the dashboard view. The reason for this from memory was that when I used parseAndExit any application errors seemed to dissapear, and as you say, the process would exit with 0

I'm also re-throwing any app errors which I would have thought would bubble up for the CLI code to display and exit, but they don't. How should a sywac consumer deal with these?

I also didn't realise that the check function was supposed to be within each commands setup, I had it in the top level under the style function.

Thanks very much for helping so far!

from sywac.

Thoughts @nexdrew ?

from sywac.

Any unhandled errors will bubble up to sywac and sywac will handle them and report them in the result object resolved by the .parse() method.

The error handling I was talking about in your code is found here: https://gitlab.com/purpleteam-labs/purpleteam/blob/49e1341ca37f0b5f81cd239f92b9f86344c51f97/src/presenter/apiDecoratingAdapter.js#L50-77

Since it catches the error from the rejected Promise and doesn't re-throw it or notify sywac, the CLI code doesn't know that any error occurred.

This is what I see:

$ NODE_ENV=test ./bin/purpleteam test -c ./testResources/jobs/job_0.1.0-alpha.1
▶  debug      [index] Starting the CLI
▶  debug      [cli] Configuring sywac

✖  critical   [apiDecoratingAdapter] Error occurred while attempting to communicate with the purpleteam SaaS. Error was: "The purpleteam backend is currently unreachable".
$ echo $?
0

How you want to handle this is entirely up to you. Perhaps the easiest thing might be to set process.exitCode wherever you are handling errors this way.

let response
try {
  response = await something()
} catch (err) {
  handleError(err)
  process.exitCode = 1
}

from sywac.

I'm closing this issue as I believe I have fully answered the question about when to use parseAndExit vs when to use parse. All the other details are specific to your implementation and do not reflect issues with sywac.

from sywac.