Restructure result conventions (again again)

[aaronccasanova]

I'm quite eager to see the parseArgs PR in Node cross the finish line, but since we missed the initial release should we consider one last time renaming the values result?

IMO, This property made sense when the associated parseArgs configuration API was withValue. However now we have switched to a config.options objects and combined the boolean options from the now legacy flags property.

If I think about it semantically, the parseArgs inputs are really an optionsConfig and the outputs are options.

Proposing

Before:

const { values } = parseArgs({ options })

After:

const { options } = parseArgs({ optionsConfig })

I imagine this update would be pretty frictionless with a simple find and replace. That being said, I absolutely don't want to hold things up and would be fine closing this issue here and now.

[shadowspawn]

I think the proposed naming is better, but probably not better enough to make the effort at this stage. 😫

[ljharb]

Why not “config”?

[bakkot]

"config" is not what I would generally call the collection of CLI arguments, personally.

[shadowspawn]

We use "config" as the name of the parameter: const parseArgs = (config = { __proto__: null })

[ljharb]

True, I’d call them options, but they’re both options :-) and “optionsConfig” is pretty wordy.

[aaronccasanova]

Yes, "optionsConfig" is definitely wordy! That's honestly my issue with it as well.

I think the proposed naming is better, but probably not better enough to make the effort at this stage.

Totally agree, this isn't worth the effort at this stage.

TBH I'm very happy with the current API and just wanted to quickly check if folks shared that opinion and/or had any alternative suggestions. Thanks for entertaining the idea all! 👍