Skip to content

rest... args support #78

@theoephraim

Description

@theoephraim

Clear and concise description of the problem

My cli has a sub command which will run a user-supplied command - for example mycli run -- something else.

I'd like to be able to treat that subcommand as another option, and make sure that the help info is generated appropriately.

update: I just discovered this related issue

Suggested solution

add a new rest or command option type, which captures everything else

{
  name: 'run',
  description: 'Run a command with the environment variables loaded',
  options: {
    'command-to-run': {
      type: 'rest',
      description: 'command to run',
    },
  },
};

Personally I'm ok with forcing the user to use a -- separator, as I find it is more explicit and cleaner, but this could conceivably be an option.

It's important that this then translates correctly into the autogenerated help info into something like
mycli run <options> -- [command-to-run]

Alternative

I can filter out the -- ... before parsing, and then within the command look at process.argv to recover it, but either way the autogenerated help info will not look right. Commander also didn't quite handle this correctly, but I believe I was able to explicitly override a few things to get it looking correct.

Additional context

No response

Validations

  • Read the Contributing Guide.
  • Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Metadata

Metadata

Assignees

No one assigned

    Labels

    featureIncludes new features🍰 p2-nice-to-havePriority 2: nothing is broken but it's worth addressing

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions