parse/parseAsync cannot be used multiple times on the same Command instance

[goodov]

Not sure if it's a known gotcha or an actual bug, but I've noticed that I can't use parseAsync multiple times with different args on the same Command instance (for ex. in tests), because internally all parsed options are cached.

[goodov]

Hm. Found multiple closed duplicates which are all solved by referring to the added text in README.md. How about having this info in the parse/parseAsync method comment? This is pretty important bit that I wasn't able to find by looking into the source closely.

  /**
   * Parse `argv`, setting options and invoking commands when defined.
   *
   * Use parseAsync instead of parse if any of your action handlers are async. Returns a Promise.
   *
   * The default expectation is that the arguments are from node and have the application as argv[0]
   * and the script being run in argv[1], with user parameters after that.
   *
   * @example
   * ```
   * program.parseAsync(process.argv);
   * program.parseAsync(); // implicitly use process.argv and auto-detect node vs electron conventions
   * program.parseAsync(my-args, { from: 'user' }); // just user supplied arguments, nothing special about argv[0]
   * ```
   *
   * @returns Promise
   */
  parseAsync(argv?: readonly string[], options?: ParseOptions): Promise<this>;

[goodov]

Throwing might be the best thing to do as another user mentioned here: #2246 (comment)

This should be fixed.

[shadowspawn]

There were no related issues opened for a while after the note got added to the README in #2036, but this issue and two others just recently:

• Commands cannot be reused #2246
• Boolean option does not reset between parse() and parseAsync() calls #2247

I expect prohibiting repeated calls will break some programs, but I also expect most of the cases will be technically unsafe and the author had not noticed there is state left behind from the first parse.

I am wondering whether to throw an error for multiple calls to parse in the next major version.

[goodov]

I expect prohibiting repeated calls will break some programs, but I also expect most of the cases will be technically unsafe and the author had not noticed there is state left behind from the first parse.

yep, I think this is what everyone are doing right now until they figure that something is wrong.

Throwing is a fast and simple take on the problem. Supporting multiple calls to parse would be a much better solution for the library in terms of the usability. It looks like it supposed to work like that, but was never carefully supported in this area which led to some invariants being broken with time. I don't see why we can't support this, it's just a matter of resetting the state on each call.

[shadowspawn]

Opened a PR to allow multiple calls to .parse(): #2299

[shadowspawn]

Support for multiple parse added in version 13.0.0