stabilize @std/cli

[kt3k]

part of #4600

• fully documented
• fully tested
• no ongoing breaking change discussion
• 1.0.0-rc.1
• wait 1 month
• 1.0.0 (stabilization)

---

related issue #4362

[iuioiua]

I'm not confident that stabilizing @std/cli right now is the correct decision for a few reasons:

1. parseArgs()is arguably quite sub-optimal, compared to alternatives like feat(cli/unstable): add parse() with descriptive schema #4362, even though it's widely used.
2. Spinner is new, and recent issues/PRs suggest it might not be ready for stabilization.

Apart from those, promptSecret() and unicodeWidth() seem ready for stabilization. So, might it be worth considering stabilizing a package (if it's mostly ready) but marking some APIs as unstable?

[kt3k]

Discussed this offline

I think parseArgs should be stabilized as is. We are still open to alternative designs like #4362, but we'd work on that after the stabilization. (#4362 doesn't seem to be finished soon)

We would mark Spinner unstable/experimental for now mainly because it's a very new API, and revisit the stabilization of it some time later.

[andrewthauer]

Related to cli tools in general, is there a stance on using stdout vs stderr for information messages? This may not widely known, but a relatively common practice is using stdout for anything that might be piped and stderr for anything that is informational since it's not passed along when piping commands. I believe this comes from the unix philosophy, but I have seen some argument over this behaviour. The Command Line Interface Guidelines resource describes this as desirable in https://clig.dev/#output.

The reason I ask is that I have considered proposing either changing some usages of stdout to stderr by default (e.g. the Spinner messages) or adding options to change the behaviour. I also noticed that some of fmt and logging also assume stdout and have no options to use stderr instead. I suppose changing the default would be considered a breaking change in behaviour but not API.

[jsejcksn]

is there a stance on using stdout vs stderr for information messages?

I think that — unless fully configurable, and by default — stderr is the only appropriate stream. Refer to the discussion here for more…

• Add CLI flag to disable internal writes to stdio streams deno#16804

…and see this QA for links and information about the definitions and purposes of the standard streams:

Do progress reports/logging information belong on stderr or stdout? - Unix & Linux Stack Exchange