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):