docs(api): explain .parse()’s exiting behavior more clearly

[roryokane]

The original wording “disables the exitProcess setting” is ambiguous. It could be wrongly interpreted to mean “disable the exitProcess function, which allows changing of the setting”, which would then leave ambiguous the actual value used for the exitProcess setting.

[bcoe]

rather than saying "until after the callback is invoked", perhaps something along the lines of, the Node process will exit normally, i.e., when the event loop is empty, or an error is thrown.

[roryokane]

I’m afraid I don’t understand the relevance of the Node process exiting normally, or why it’s unnecessary to say “until after the callback is invoked”.

This is how I understand the phrase “until after the callback is invoked”:

Providing a callback to parse() disables automatic exiting of the process (as if the exitProcess setting were set to false). After the callback is invoked, future calls to yargs.parse() without a callback will follow the exitProcess setting – i.e. they might exit automatically if an error is encountered during parsing.

Is that an accurate reading? How is normal Node exiting behavior relevant?

[mleguen]

I’m afraid I don’t understand the relevance of the Node process exiting normally

Because this is the way exitProcess(false) works: yargs no longer exits the process, and if you have some code after your call to parse(), it is executed by node.

If this code calls parse() again without exitProcess(false), then, yes, yargs will exit the process. Otherwise, the process will be exited normally by node after all code is executed.

Your first wording could be understood as yargs automatically exiting the process after the callback was ran (so before the code after parse() was executed), which is not the case.

[roryokane]

How’s this?

[bcoe]

@roryokane left suggestion 👍

[roryokane]

I’m okay with that. Added a commit with that change.

[bcoe]

@roryokane thank you for the contribution.