suggestion: add interactive prompts to @std/cli

[Delapouite]

Hi.

When building CLI tools, there's often a need to ask the user about values.

Deno already provides functions such as prompt or promptSecret to gather simple strings.
But there's currently no easy way to let the user interactively choose a value in a finite set.

In user land, popular libraries such as Inquirer (https://www.npmjs.com/package/inquirer) offer such advanced prompts.
Here's a screenshot from Inquirer's README that illustrates what it looks like in the terminal, where the user can use its keyboard to navigate between options:

So I guess my question boils down to the following:

Could such features (a.k.a. Inquirer clone) deserve to be builtin in @std/cli to avoid reaching for an external dependencies?

Thanks.

[kt3k]

These additions are welcome in my opinion.

Note to those who are interested in contributing in these areas: Please also consider contributing in Pseudo Terminal support in Deno ( denoland/deno#3994 ). Deno currently doesn't have a practical way to test terminal interactions (as far as I know) and testing these features are very difficult/tricky.

[iuioiua]

cliffy already does this. Simple/basic CLI helpers make sense in the Standard Library, but there is a point when we should not go further. I'd prefer not to have this in the Standard Library.

[andrewthauer]

I tend to agree with @iuioiua here. I would generally like high quality and flexible building blocks in @std as a general rule of thumb. cliffy already has a full set of high quality tools needed to build a feature rich CLI experience. I'd be less apt to mix and match parts of @std and other libraries as this might provide a less holistic feel. That said, if @std included a full suite of rich and powerful CLI features that would potentially be a different story. Anything in between is not worth it imo.

[timreichen]

I tend to agree with @iuioiua here. I would generally like high quality and flexible building blocks in @std as a general rule of thumb. cliffy already has a full set of high quality tools needed to build a feature rich CLI experience. I'd be less apt to mix and match parts of @std and other libraries as this might provide a less holistic feel. That said, if @std included a full suite of rich and powerful CLI features that would potentially be a different story. Anything in between is not worth it imo.

@std already provides some major cli tools:

• colors
• (built-in prompt)
• secret prompt
• an argument parser based on minimist
• spinner
• (feat(cli): add parse() with descriptive schema #4362 as an alternative take on argument parser with possible auto help generator as a second step)

I would not exclude a commonly used feature as this that makes the tools list more complete just because the tools list is not complete (yet).

[andrewthauer]

I would not exclude a commonly used feature as this that makes the tools list more complete just because the tools list is not complete (yet).

This is my opinion of course, but let me try and clarify my stance.

My concern here is figuring out the balance of what goes into @std and what does not. I've been watching various issues and PRs over the last few months and often see dialogue and debate around what should and shouldn't be part of @std for various reasons. From what I've seen (which could be my misguided perspective), is that there is a tendency to keep things to a minimal API surface. On one side, this makes a lot of sense since @std provides building blocks for other libraries and apps. Having a large API surface could lead to complexity and make it harder to evolve. However, there is a grey area where some of these types of tools (e.g. select input) become quite opinionated and difficult to strike that balance where everyone can agree.

When I choose libraries to use, I try to be cognizant of how well they will evolve with my project. If I'm starting a CLI project, I want to pick a feature rich library up front, so I can avoid limitations that might cause me to have to rewrite or switch out libraries later. My worry is that some tools like the input select, etc. could easily fall into the grey area describe above. Especially given they are opinionated in a way that is directly exposed to the end user versus internal code.

Here is my current opinions on the existing cli tools:

• colors - Useful. I also like how cliffy builds on top of this to create a fluent API, which is often more readable to use when composing things imo.
• (built in prompt) - I'm not sure what is meant here but I suspect this is window.input maybe?
• secret prompt - There are not a lot of ways you can do this so probably doesn't require many additional features
• an argument parser based on mimist - I've describe my thoughts here. Overall, I find this API not very intuitive and overly simplistic to be very useful.
• spinner - A decent start, but it could use some additional states beyond start/stop (e.g. info, fail, warning, succeed) to show progress/completion. If there is appetite, I might be willing to contribute this.
• feat(cli): add parse() with descriptive schema #4362 - I like the direction of this so far and would hope to see the minimist arg parser replaced with this. That said, it's a slippery slope as this can get very opinionated with a lot of nuances since it's end user facing when you get into sub commands, etc.

To summarize, I'm not against having a full suite of CLI tools in @std. I just hope this is done with a clear intention and roadmap that avoids too much friction evolving the APIs and tools. Essentially, a go big or go home mentality for this class of tools building CLIs. Otherwise, I'd personally stick with a full suite in userland for most things (e.g. cliffy).