rushstack
rushstack copied to clipboard
Move CLI information output to stderr for install-run-rush
Summary
Trying to solve #2607 by forward informational CLI output on stderr
Details
Rather than using and stdout for informational output we want to use sterr, this is also the right usage for the stderr.
We can read more about it here: https://pubs.opengroup.org/onlinepubs/9699919799/functions/stderr.html
At program start-up, three streams shall be predefined and need not be opened explicitly: standard input (for reading conventional input), standard output (for writing conventional output), and standard error (for writing diagnostic output).
This isn't a solution to #2607. These are informational messages that should be printed to stdout. When the --json flag is passed, those messages should be suppressed.
Can we discuss in-person tomorrow? I think I have a good solution, but I'd like to discuss it first.
This isn't a solution to #2607. These are informational messages that should be printed to stdout. When the
--jsonflag is passed, those messages should be suppressed.Can we discuss in-person tomorrow? I think I have a good solution, but I'd like to discuss it first.
@iclanton I don't think you want to discuss with me right? 😅 otherwise sure I can make time.
@M3kH - lol sorry, I started typing that response, got distracted, and then typed something I meant to type to someone else.
You want to fix this issue by completely suppressing the banner messages, not just print them to a different stream. The easiest way to do that may be to add a feature to ts-command-line where a flag parameter can be marked as causing the tool to produce machine-readable output. Then you can plumb its inclusion to a property or function in the action class and the CommandLineParser class directing the tool not to print anything but the machine-readable output.
#2777 is looking at an alternate approach to the problem, namely it is turning off the logging from install-run-rush.js altogether unless --debug or -d is passed on the command line, and only printing the output of the underlying command. This combines with an ability to disable Rush's own additional boilerplate logging with a configuration parameter in the action schema.
@dmichon-msft indeed I think that is a better solution.
I will still consider not using stdout for debugging purposes, which is a practice of many CLI tools.