This will break the old manner?

@zhiyelee No, this only comes in to play when you override process.exit, or the commander methods that use it. Commander relies on process.exit to halt program flow. These returns mimic that if process.exit doesn't do it.

By doing so now you can use commander in contexts other than a shell.

@SomeKittens @zhiyelee Any thoughts? The patch has some added tests.

@zhiyelee what will break? This looks good to me.

@SomeKittens Nothing break. But I'm not a big fan of this. Since to use this, user must override process.exit first. Not very graceful, but I have no better solution.
Besides I think Commander is designed to use in command line instead as a class can be extended.

@zhiyelee I agree its not the most graceful approach when it comes to overriding process.exit. A better one long term would be centralizing all the process.exits into a single method that can then be overridden, and passing to that method the exit code as well as error message. The default approach, as it is now, would be to print that message and exit. However then if you wanted to do something else like forward the message to a remote client, you could do so.

Even if we do that, we'll still need to implement these changes where program flow is interrupted by returns instead of relying on process.exit to do it for us.

I should also mention this patch goes most of the way towards fixing the second Con on this list: http://trentm.com/2014/01/a-critique-of-commander-for-nodejs.html

In addition to the reason of this PR (testing purposes) we have a requirement to apply custom styling for the error messages to make them consistent across our app (e.g. we are using bold red ERROR prefix). I think the best solution for the both issues will be Command's error event. If it hasn't listeners it will behave as it does currently. If it has listener, when process will not exit and message text is passed as event argument. I can issue PR if you are OK with this behavior.

I'd also like to see this (and preferably a way to pass an exit function to the Command constructor). I'm currently overriding process.exit to throw an exception, which also works, but it would be nice to avoid patching process.exit altogether.

I have added this pull request to a triage collection of exit related issues for future reference.

This pull request has not had any activity in over six months. It isn't likely to get acted on due to this report.

Feel free to open a new issue if it comes up again, with new information and renewed interest.

Thank you for your contributions.