[Feature]: Add flag for explicit interactive mode

[alexflint]

What problem does this feature solve?

When I run rsbuild as a subprocess of another process, it doesn't start in interactive mode, so I can't type "o + enter" to open the app in the browser (or other interactive commands). In my case I am running rsbuild under concurrently, which has an option to pass stdin to one of its subprocesses. I was hoping to be able to use rsbuild's interactive commands when running it under concurrently, but it doesn't work because rsbuild doesn't go into interactive mode when running as a subprocess. I imagine this is based on detecting whether stdin is a TTY, which it isn't in the case of being run under concurrently. Unfortunately concurrently doesn't have an option to allocate a TTY to a subprocess.

Could there be an rsbuild --interactive that forces interactive mode?

What does the proposed API look like?

rsbuild --interactive

Forces rsbuild to go into interactive mode, even if stdin is not a TTY.

[chenjiahan]

Thanks for the suggestion! However, if Rsbuild's dev server runs in a child process, it can't directly receive keyboard input from the parent process. Supporting a manual --interactive flag wouldn't work. For now, we'd prefer to keep the current behavior based on TTY detection.

[alexflint]

Thanks for the response @chenjiahan, but isn't it possible that rsbuild could still have a stdin that receives characters typed by the user, even when running under a subprocess, and even when it does not have TTY? In the case of concurrently, that exact situation arises because the library manually copies input from its own stdin to the stdin of the subprocess running rsbuild. If rsbuild were to read from stdin under these conditions, it would receive characters typed by the user. For example running cat under concurrently correctly echos characters typed (the "abc" and "def" lines below were typed by me; the lines starting "[0]" were echoed back from cat):

$ npx concurrently -i cat
abc
[0] abc
def
[0] def

However, you can also verify that subprocess is not connected to a TTY:

$ npx concurrently -i tty                                                                                             
[0] not a tty
[0] tty exited with code 1

[chenjiahan]

Is it possible to get user input via node:readline in a child process? I tried it and it doesn't seem to work.

[alexflint]

OK just tried the following and it works when process.stdin is not a tty:

const readline = require('readline');

console.log(process.stdin.isTTY ? "is a tty" : "not a tty");

const rl = readline.createInterface({
  input: process.stdin,
  output: process.stdout
});

rl.on('line', (line) => {
  console.log(`Read: ${line}`);
});

rl.on('close', () => {
  console.log('Reading complete.');
});

For example:

$ cat | node readline-experiment.js                                                                                                
not a tty
abc
Read: abc

[chenjiahan]

Have you tried running concurrently "node ./readline-experiment.js" "node ./readline-experiment.js" and checking whether the input can be read? It didn't work on my side.

[alexflint]

You actually need to add -i to tell concurrently to pass input through to the first subprocess. With that flag, it works:

$ npx concurrently -i "node ./readline-experiment.js" "node ./readline-experiment.js"                                                                                     
[0] not a tty
[1] not a tty
a
[0] Read: a
b
[0] Read: b

Of course, only the first readline-experiment.js gets the input.