Skip to content

Behaviour for withValue --foo followed by --bar ? #25

Closed
@shadowspawn

Description

@shadowspawn

I am working through some of the special cases during a refactor of the results code.

parseArgs(['--foo', '--bar'], { withValue: ['foo'] )

This is a case where the parser could behave two ways. The --foo option is expecting a value, there is an argument available, but the argument looks like an option.

The current implementation is that foo gets the value undefined, and --bar is seen as a flag.

  1. I think seeing --bar as a flag rather than the value is the least surprising behaviour, so just confirming that this is as intended and/or expected by others?
  2. Would it be better if foo was an empty string rather than undefined? This might be more consistent from a typing point of view. I don't have a wrong preference.

Current behaviour, assuming flags are stored in flags and values are stored in values:

flags // { bar: true }  <-- ok?
values // { foo: undefined } <-- or empty string?

If the user wants the --bar to be the value then they can achieve this with --foo=--bar.

For comparison:

  • In Commander both behaviours are available. An option with a required option-argument does eat the next argument, but an option wth an optional option-argument does not eat arguments that look like options.
  • In Minimist, with foo configured to be a "string" it gets an empty string as value, and --bar is parsed as a flag.

Added TL;DR proposal: #25 (comment)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions