Help stops before finishing to write in Node v6.1.0

[nicola]

var yargs = require('yargs')
const program = yargs
  .usage('usage: $0 [options]')

// program.option('hello', {description: 'test option'})
for (var i = 0; i < 20; i++) {
  program.option('hello_' + i, {description: 'this is a medium sized description, good!'})
}

program
  .help('help')
  .wrap(null)

const argv = program.argv

if (argv._.length < 1) {
  yargs.showHelp()
}

Here is my little command:

$ node example2.js
usage: example2.js [options]

Options:
  --hello_0   this is a medium sized description, good!
  --hello_1   this is a medium sized description, good!
  --hello_2   this is a medium sized description, good!
  --hello_3   this is a medium sized description, good!
  --hello_4   this is a medium sized description, good!
  --hello_5   this is a medium sized description, good!
  --hello_6   this is a medium sized description, good!
  --hello_7   this is a medium sized description, good!
  --hello_8   this is a medium sized description, good!
  --hello_9   this is a medium sized description, good!
  --hello_10  this is a medium sized description, good!
  --hello_11  this is a medium sized description, good!
  --hello_12  this is a medium sized description, good!
  --hello_13  this is a medium sized description, good!
  --hello_14  this is a medium sized description, good!
  --hello_15  this is a medium sized description, good!
  --hello_16  this is a medium sized description, good!
  --hello_17  this is a medium sized description, good!
  --hello_18  this is a medium sized description, good!
  --hello_19  this is a medium sized description, good!
  --help      Show help  [boolean]

All correct, but when I use the flag --help, it breaks:

$ node example2.js --help
usage: example2.js [options]

Options:
  --hello_0   this is a medium sized description, good!
  --hello_1   this is a medium sized description, good!
  --hello_2   this is a medium sized description, good!
  --hello_3   this is a medium sized description, good!
  --hello_4   this is a medium sized description, good!
  --hello_5   this is a medium sized description, good!
  --hello_6   this is a medium sized description, good!
  --hello_7   this is a medium sized description, good!
  --hello_8   this is a medium sized description, good!
  --hello_9   this is a medium sized description, good!
  --hello_10  this is a medium sized description, good!
  --hello_11  this is a medium sized description, good!
  --hello_12  this is a medium sized description, good!
  --hello_13  this is a medium sized description, good!
  --hello_14  this is a medium sized description, good!
  --hello_15  this is a medium sized description, good!
  --hello_16  this is a medium sized description, good!
  --hello_17 %

This is the same problem facing tj/commander.js#530 right now,
do you have a fix for this planned?

[bcoe]

@nicola interesting, is there a chance that printing the output is taking more than one tick? this would be strange behavior, but should be fixable; looks like we might need to do some thorough testing debugging on Node@6.x.

[nicola]

hey @bcoe thanks for your quick reply, Node v6 has done several updates to Buffer, worth looking into it

[lpinca]

Posting this here for reference: nodejs/node#6456.

[eljefedelrodeodeljefe]

console.log is not blocking for a while now. We are seeing lots of behaviour like this in similar cases and repos, because recent libuv changes have made this problem visible. We are working on workarounds in node core.

The problem often arises when looping over stdout or console in combination with with process.on('exit', handlers), this could be an immediate fix. I keep you posted.

[bcoe]

@nicola @eljefedelrodeodeljefe I've been chatting with @othiym23, and have a plan of action for a hacky patch; @nicola could you submit a failing test case in test/integration?

[eljefedelrodeodeljefe]

Just to throw in some: I assume it's about the recursive call of parseArgs and the process.exit(0) here.

At best the hotfix is revertable in the future though. The private process APIs are likely to change and are a terrible hack - if you consider them.

[eljefedelrodeodeljefe]

I have tried replacing all the process.exit() with

ee.on('custom_exit', function () {
  // no-op
})

and a respective ee.emit('custom_exit', 0) and at least that prints everything. You would have to decide whether that is breaking the APIs

[eljefedelrodeodeljefe]

Exploring this here #498

[bcoe]

@eljefedelrodeodeljefe would custom_exit be emitted immediately, or would the consumer code be able to execute in the current tick before our event fires; something we should test :)

[eljefedelrodeodeljefe]

hmm. Can you think of a test case? When I see this right node core defer most events to the nextTick. In this case I would suppose it wouldn't matter because when you return from top scope and there is still something on the event loop that will execute. But, tbh, I am not sure.

[bcoe]

@nicola please give this a spin:

npm i yargs@next

I've written this shim: https://github.com/yargs/set-blocking

[bcoe]

@nicola bump; somewhat worried about this change, so would love to have the second set of eyes before it gets promoted to latest.

[nexdrew]

@bcoe FWIW, using @nicola's script and running with --help on Node 6.1.0, I was able to consistently see the problem with yargs@4.7.0 and cannot reproduce the problem with yargs@4.7.1, so it looks good to me. 👍

[bcoe]

@nicola this should now be fixed on latest.

[nicola]

edit: all great it works! thank you so much for the quick fix!

[bcoe]

@nicola awesome, I can close this out?