feature(cli): don't block forever waiting on stdin #5017
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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: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:
stdin
is ignored. The user has indicated he/she wants to compile the files listed explicitly as arguments.stdin
.stdin
to block forever in the case where users accidentally callswc compile
with no file arguments and without passing information overstdin
, you probably want reading fromstdin
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 usetokio
.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):