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.

[Imran-imtiaz48]

Summary of Changes:

1. Added Dependencies:
   o Added thiserror = "1.0.31" to the [dependencies] section.
2. Target-Specific Dependencies:
   o Added dependencies specific to Unix and Windows targets under [target.'cfg(unix)'..] and [target.'cfg(windows)'..] respectively.
   Changes in swc_cli/src/commands/compile.rs:
   • Imports:
   o Adjusted imports related to util::trace::init_trace to now use crate::{util, util::trace::init_trace}.
   • Functionality:
   o Refactored collect_inputs() function to handle input collection from standard input (stdin) more efficiently.
   Review:
   • Dependency Changes:
   o The addition of thiserror and target-specific dependencies (mio for Unix and various Win32 libraries for Windows) suggests platform-specific enhancements or corrections.
   • Code Refactoring:
   o The refactoring of collect_inputs() enhances error handling and streamlines the logic for handling input sources (stdin vs. files).
   These changes appear focused on improving error handling, ensuring platform compatibility, and potentially enhancing code organization and efficiency within your project

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Brian Myers seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}