execArgv option to force TTY

[novemberborn]

Is your feature request related to a problem? Please describe.

Developer tools may run user code in a child process. When invoked in in a terminal, process.stdout and process.stderr will be TTY streams. This will not be the case in the child process.

Describe the solution you'd like

It'd be great if the developer tool could force TTY to be available in the child process.

Describe alternatives you've considered

I've tried faking TTY support in the child processes. This is somewhat doable but breaks when Node.js adds new features. With AVA we've now removed this behavior, hoping for somebody to provide the functionality in a separately loadable package.

It'd be much better if we could make Node.js provide its own implementation.

[mscdex]

Have you already tried something like node-pty?

[addaleax]

It'd be great if the developer tool could force TTY to be available in the child process.

It might help if you could be more specific here – you can’t create TTYs without using native modules like @mscdex mentioned at the moment, and while a libuv feature along those lines might be possible, is there a chance that it might help more to control Node.js’s behaviour in these situations?

For example, I’ve recently had a conversation in which the idea of forcing Node.js core to enable color mode for its output was brought up. I think that would be a reasonable request, and something that developers right now might try to solve by manually creating TTYs.

[mscdex]

For example, I’ve recently had a conversation in which the idea of forcing Node.js core to enable color mode for its output was brought up.

Is this something other than setting the FORCE_COLOR env var that node currently respects?

[novemberborn]

It might help if you could be more specific here

Specifically for a test framework, if you want to test a TTY program you might need a TTY. I suppose node-pty could be used for that, but it doesn't look like something we at AVA would support directly.

Requiring a module which overwrites some modules to fake the TTY is conceptually easier, even if it's more liable to break.

If there was a flag to expose the TTY APIs on stdout and stderr it would solve many use cases for folks developing programs that use a TTY. Of course I don't know how hard this is to achieve within Node.js itself.

[bnoordhuis]

It sounds like what you're asking for is a quick fix, expose e.g. process.stdout.getWindowSize() even when process.stdout is not a tty? I don't think that's a good way forward.

Proper built-in pty support however might be so I've opened libuv/libuv#2640 to discuss.

[novemberborn]

It sounds like what you're asking for is a quick fix, expose e.g. process.stdout.getWindowSize() even when process.stdout is not a tty? I don't think that's a good way forward.

To be fair, I'm approaching this from a user's perspective, like " why can't I get this API in my child process".

Built-in pseudo-TTY support would also be great, and I can see how that's more "correct" for Node.js itself.

[ZheyangSong]

I ran into a similar scenario where I tried to run my own script with lint-staged (which, in turn, relies on execa to execute my script in a spawned child process). Since my script decides the input source based on process.stdin.isTTY, it wrongfully waits for data from process.stdin when it's invoked via child_process.spawn by execa... It took me a long time to figure this out...

[prettydiff]

As a specific example of why such an option has value consider the following real life example:

The git command checks for TTY on the process output stream. If TTY is true then you get color output formatted with ANSI escape sequences. When TTY is false, such as running git in a Node spawned process the output is raw text without the ANSI escape sequences.

This ability to optionally force a TTY flag on a child process stdout stream would be helpful for a testing perspective, but its more than just testing. Its about setting environmental conditions to impose a different execution context, and thus achieve a different result.

In my own use case I am creating a command terminal that executes in the browser. Input commands are sent out of the browser to a localhost node process that executes the commands in a child process. The output from that child process presents different behaviors in some more advanced programs than those same commands executed outside of Node.

[bnoordhuis]

I've opened #46105 to track pty support. I'll take the liberty of closing this issue.