Throwing an error in a command handler can result in truncated stdout/stderr output

Thanks for such a fantastic library. I wanted to help out by dropping a report for a rare bug I saw in case it helps anyone else.

Problem

I was debugging a problem with webpack output getting truncated on failures. This build is wrapped in a yargs command handler. The code looks roughly like this:

async function commandHandler() {
  const compiler = webpack(config);
  const stats = await util.promisify(compiler.run.bind(compiler))();

  if (stats.hasErrors()) {
    console.log(stats.toString());
    throw new Error("Webpack build failed. See error messages above.")
  }
}

This example is adapted slightly from: https://webpack.js.org/api/node/#error-handling

The stats.toString() object here could be quite large, and I was observing output from webpack getting cut off mid-line. It was clear the stdout output wasn’t complete.

Investigation

Making sure stdout was flushed before throwing an error fixed the issue.

console.log(stats.toString());
await new Promise((resolve) => process.stdout.write("", resolve));
throw new Error("Webpack build failed. See error messages above.")

This made me think there was a code path in yargs that called process.exit() after a command handler returns, which would force Node.js to exit before everything on the event queue is processed. Node.js normally waits for all stdout to be written before exiting.

I was able to repro yargs calling process.exit in a debugger. The code path is:

1. yargs calls yargs.getInternalMethods().getUsageInstance().fail if a command handler returns a rejecting promise:

   https://github.com/yargs/yargs/blob/59a86fb83cfeb8533c6dd446c73cf4166cc455f2/lib/command.ts#L434-L440

2. This fail handler calls yargs.exit(1) if exitProcess is set. (It is by default.)

   https://github.com/yargs/yargs/blob/59a86fb83cfeb8533c6dd446c73cf4166cc455f2/lib/usage.ts#L70-L71

3. yargs.exit then calls process.exit

   https://github.com/yargs/yargs/blob/59a86fb83cfeb8533c6dd446c73cf4166cc455f2/lib/yargs-factory.ts#L703-L707

Workarounds

• I ended up setting process.exitCode = 1 instead of throwing an error.
• This is also fixable by adding exitProcess(false), but the yargs docs discourage setting that option for commands.

[bcoe]

Do we know if that’s the only reason it’s defaulted to true?

I believe the reasoning was if you’ve triggered an event that should terminate execution, like --help, you don’t want the logic to execute after yargs is invoked.

I think we should leave it defaulting to true.

Would it help if I put up a PR for that?

Can you confirm that the truncation stops if you remove the check for stream.isTTY, if it does, I would happily take a PR for this fix.

[gluxon]

Thanks @bcoe. Removing the condition might make sense. Would it help if I put up a PR for that?

The other alternative would be to switch the exitProcess(...) default from true to false. This would avoid calling process.exit, which @zaripych also cautioned against. I saw the caveat about that duplicating promise rejection errors though.

• Do we know if that’s the only reason it’s defaulted to true?
• If so, could we reasonably address that and switch the default for the next yargs major version bump?