util: support more config options for parseArgs

[RedYetiDev]

Fixes #53427

This pull request introduces the ability for an argument in parseArgs to have the required and placeholder options.

required means that an argument must be supplied.
placeholder is the value for an argument when it is supplied, but no value is supplied with it.

[RedYetiDev]

I'm all ears to better name options than useDefaultWhenUndefined, if anyone has suggestions.

[cjihrig]

Maybe I'm misunderstanding the request here, but would the following work:

• Add an optional option for individual flags.
• If optional is false use the current behavior.
• If optional is true the value is essentially provided value || default value || undefined (yes I realize this is not ideal JavaScript code)
• optional defaults to false to keep current behavior.

[RedYetiDev]

IMO, "optional" doesn't explain what's this is doing. This flag is meant for if the flag is supplied, but does not contain a value.

[cjihrig]

Ah, I was indeed misunderstanding the request. Carry on 😄

[tniessen]

As I mentioned in #53427 (comment), parseArgs() is supposed to be a minimal implementation. It is not meant for anything beyond the most basic use cases.

More importantly, I don't see how this PR addresses #53427. With this API, how is the application supposed to distinguish between the absence of the option (in which case the option gets the default value) and the presence of the option without a value (in which case the option gets the default value)? In what scenario is useDefaultWhenUndefined useful?

[RedYetiDev]

With this API, how is the application supposed to distinguish between the absence of the option (in which case the option gets the default value) and the presence of the option without a value (in which case the option gets the default value)? In what scenario is useDefaultWhenUndefined useful?

Before this API, when an argument was supplied without a value (--my-argument), and the type was string, an error would throw. With this API, when an argument is supplied without a value and as a string type, the default value will be used.

An example use case is when you want the user to have the option to enable/customize an option.
If you want to achieve: --color[=green]

./my_script.js --color # Green color
./my_script.js --color=yellow # Yellow color
./my_script.js # Green color

[RedYetiDev]

My latest commit undid itself 🤔

(Fixed)

[tniessen]

An example use case is when you want the user to have the option to enable/customize an option.
If you want to achieve: --color[=green]

./my_script.js --color # Green color
./my_script.js --color=yellow # Yellow color
./my_script.js # Green color

@RedYetiDev Again, I do not think that's what the feature request is describing. The first and third case in your example should not have the same result, and they do not in the case of git ... --color, which is the reference in #53427.

[RedYetiDev]

Makes sense, I can adjust the specifics later today

[shadowspawn]

required was not mentioned in #53427 and has already been proposed, and some concerns raised:

• util: parseArgs should support required in options[key] #44564
• required option pkgjs/parseargs#150
• util: parseArgs - if the option key is not being passed it should also throw an error #48839

[RedYetiDev]

required was not mentioned in #53427

While it wasn't mentioned, I felt that the addition of a placeholder also warranted the addition of a required, as a user may want to use the placeholder on a required flag.

[RedYetiDev]

The comments on the PR requesting this feature appear to have reached a consensus that this implemtation should remain minimal.

[tniessen]

I agree that the feature should be minimal, but I also think that the main problem with the approach in this PR is that it makes the parsing ambiguous from a user's point of view.