Deno: [Discussion]: std/cli

[timreichen]

I would love deno to have a std/cli that

• standardises deno cli programs
• uses std/flags for parsing args
• standardises ouput format

Something like commanderjs but with deno conventions.

I think that would make a great addition to std/flags. What are your thoughts on that?

[caspervonb]

"Standardizes" doesn't mean much to me here so if you wouldn't mind elaborating, the indent is to provide a mechanism for subcommands, it's option parsing, usage output and automatic help generation?

[timreichen]

Yeah, you pretty much nailed what I meant:

• no external dependencies (std/flags only)
• provide mechanism for program, subcommands, options and arguments declaration
• auto help generation for program and subcommands
• auto option and argument validation with error log (example: error: The following required arguments were not provided: <source_file>)

Sorry for the confusion, I used _standardise_ to describe a feature to be found in std

[kitsonk]

In my opinion, that feels like an highly opinionated "framework" that should start life outside std and only come into std if it become a _de facto_.

[timreichen]

Yeah, I would suggest to avoid creating a framework for std but implementing the features without an opinion. I think that is possible with the suggested features above.

For example auto help generator can be done by a simple tree structure with a function like createProgramHelp or createSubcommandHelp:

const program = {
  name: "logger",
  version: "1.2.3",
  description: "Program that can log something.",

  options: [
    {
      name: "help",
      description: "Prints help information",
      alias: "h",
      boolean: true
    }
  ],

  subcommands: [
    {
      name: "help",
      description: "Prints this message or the help of the given subcommand(s)",
    },
    {
      name: "log",
      description: "logs something",
      args:  [  { name: "source_file" } ],
      options: [
         {
          name: "help",
          description: "Prints help information",
          alias: "h",
          boolean: true
        },
        {
          name: "log-level",
          args: [  { name: "log-level" } ],
          description: "Set log level [possible values: debug, info]",
          alias: "L",
        }
      ]
    }
  ]

}

const help = createProgramHelp(program)
console.log(help)

logger 1.2.3
program that can log something.

USAGE:
    logger [OPTIONS] [SUBCOMMAND]

OPTIONS:
    -h, --help    Prints help information

SUBCOMMANDS:
    help          Prints this message or the help of the given subcommand(s)
    log           Bundle module and dependencies into single file

and for subcommands accordingly:

const help = createSubcommandHelp(program.subcommands[1])
console.log(help)

logger-log
logs something

USAGE:
    logger log [OPTIONS] <source_file>

OPTIONS:
    -h, --help                     Prints help information
    -L, --log-level <log-level>    Set log level [possible values: debug, info]

ARGS:
    <source_file>

I think this would be easy to implement but really powerful and super helpful for every cli creator. What do you think?

[kitsonk]

In my opinion, that feels like an highly opinionated "framework" that should start life outside std and only come into std if it become a de facto.

[axetroy]

I think the standard library, should not pay too much attention to application-level things.

But focus on specification

eg Encodings (base32/base64/hex/ascii...) / Compression (gzip/tar...) / Parsing (email, image) / Protocol(grpc/jsonrcp/http/ftp/sftp/ssh...) ...

All these things have specification files. These are the things that deno/std should do.

And there are too many application-level things implemented in std, which will greatly dampen the enthusiasm of the open-source community. No one is willing to spend more time and experience to developing another better library. Because there is already a library available in std, although it is not the best

[timreichen]

Thank you for your clarification. I agree on the focus on specs with you for std. I thought there was a spec for command-line interfaces on printing help and usage but I learned that there are just commonly used conventions.

PS: I have created a separate rep with the functionality here.