feature(cli): don't block forever waiting on stdin

[bcmyers]

Description:

I use the swc cli via bazel. I noticed today that bazel is unable to supply input to the compile subcommand via stdin because it does not pass this check in the current code:

if atty::is(atty::Stream::Stdin) {
    return None;
}

It seems you probably do not want this check to remain in the long-run, as, as far as I understand it, it means that processes not invoked via a TTY will not be able to supply input for compilation via stdin, which seems like an unwanted limitation.

It got me thinking about how supplying input via stdin probably should work for the compile subcommand. I'm not at all sure that I got it right, but I wanted to try an alternative; so here it is.

In this PR I propose the following:

• If files are supplied as arguments, stdin is ignored. The user has indicated he/she wants to compile the files listed explicitly as arguments.
• If no files are supplied as arguments, the user is indicating that he/she wants input to be read from stdin.
• However, because you don't want reading from stdin to block forever in the case where users accidentally call swc compile with no file arguments and without passing information over stdin, you probably want reading from stdin to timeout after a reasonable period of time and report an error.

It turns out that reading from stdin with a timeout is actually an interesting problem, but this PR accomplishes it using a mini event loop from mio on unix and the standard Windows API on windows.

An alternative design would be to use an asynchronous runtime such as tokio to add timeouts, but that would involve many other changes to the current structure. Since you don't currently have an architecture that uses an async runtime, I opted to implement "reading from stdin with a timeout" without using one, but depending on what you think I also could see benefits in re-architecting the program to use tokio.

Note: I have another "cleanup" PR outstanding (#5003). This does not base itself off of that, but rather off of the current code. If #5003 lands (even partially), I'll rebase these changes on top of that.

BREAKING CHANGE:

This changes the API for reading input for compilation as described above.

Related issue (if exists):

[kwonoj]

However, because you don't want reading from stdin to block forever in the case where users accidentally call swc compile with no file arguments and without passing information over stdin, you probably want reading from stdin to timeout after a reasonable period of time and report an error.

I'm not sure if I'm fully agreed with this proposal. stdin as input is an interesting challenage indeed, and my honest feeling is if it wasn't supported in v1 I'd rather not adapted in native cli even - but status quo is the world swc lives in now.

Anyway, I'd rather say it's user's responsibility to choose stdin to terminate process on their own if they decide to not to supply input later. After all, swc cannot assume any desire of user either input comes or not. Timeout is easy, implicit way to guess those but it is not correct measure - especially implementing timeout with stdin brings some amount of complexity to solve.

I'd rather to leave explicit messages when swc kicks in if it attempt to stdin, like swc now waiting input from stdin to tell its status explicitly. Or either (I think I thought this once but somehow didn't / couldn't make it work), having flags like --stdin for the compile subcommand so user manually opt in and owns complete responsibility.