The use of `process.exit()` is undocumented and too disruptive

[joakimbeng]

Thanks for a handy package!

But because it uses process.exit() under the hood in the .fail() method it's not usable in my use case.

I tried using tasktree to display a main task with a couple of subtasks, the main task should only fail if any of the sub tasks fail and the rest of the sub tasks should be marked as skipped. Then after all sub tasks has run successfully or any of them has failed I need to do some cleanup. I think the console output looks best when using Task.fail(error) for the sub task that failed, but because it uses process.exit() it immediately exits the process and therefor hinders any cleanup from even happening.

It took a while to investigate why the cleanup didn't happen until I discovered the exit call in the fail method's code.

I can see you have disabled the no-process-exit ESLint rule and the reason for having that rule in the first place is exactly because of the scenario I'm experiencing.

Disabling that rule makes sense when you're developing CLI's, but this package is not a CLI script it's a library that will probably be used inside a CLI script.

My suggestion is to delete the process.exit() calls completely from the code base as it removes control from the user of this package. Either that or exposing the Task.setStatus method, as what I want is essentially Task.setStatus(TaskStatus.Failed); and Task.error(error, false), so I can control the state and output fully myself.

What do you think?

[keindev]

You can use task.error() without the 'fail' flag, this will not cause the tree to stop redrawing. task.fail() - always stops "started" tree render.

I also added the noProcessExit flag to the TaskTree.start() options. If a task failed, an exception will be thrown.