ability so force progress reporting even when output stream is not a TTY

[lbeschastny]

node-progress TTY detection as an awesome feature, but sometimes terminal connection is lost due to stdio piping.

Here is a very simple example:

node ./simple.js 2>&1 | cat

There is no way to check in simple.js that the end of srderr pipe is connected to some terminal, we only know that srderr stream is piped somewhere. But as a user I know it'll end up in a terminal and still want to see a progress bar.

[lbeschastny]

Found the following workaround:

var tty = require('tty').WriteStream.prototype;
Object.getOwnPropertyNames(tty).forEach(function (key) {
  process.stderr[key] = tty[key];
})
process.stderr.columns = 80; // almost all terminals have at least 80 columns

[lbeschastny]

This should also help with #104

[nicojs]

@lbeschastny wouldn't your solution fail in some use cases when the stream does not support stream.clearLine, stream.cursorTo, etc? Or simply not clear the line? For example when using jenkins, travis setups, etc.

In that case i want to suggest a different solution: fall back to a simple write-only progress bar. The bar would simply redraw on a new line. The time between redraws (refresh rate) would be configurable, with a default to 10 seconds intervals.

I could create a PR for this (i'm creating a similar solution for stryker-mutator/stryker-js#212)

[lbeschastny]

@nicojs it's not a real solution, but rather a simple workaround. And it definitely won't work for non-tty clients like jenkins.

It would be really nice to have some good failover for non-tty clients like a simple write-only progress bar.

Though drawing a new bar every n seconds doesn't look like a good idea here because some processes may take quite a while to complete.

The best solution is to use a simple incremental bar (when you just add a new symbol to an existing line from time to time), but it would conflict with current rich progress bar templating mechanics.

Another possible solution is to draw a new bar after every n percents and thus guarantee that resulting output will be small.

[ryan-frankel]

I made a PR that includes this fix as an option: #168