fix: passed arguments should take precedence over values in config

[jly36963]

Relates to:

issue: #2096
PR: #1992
PR: #2006

Problem

There were a few problems with pull 1992:

• Positional arguments combined with defaults (solved by 2006)
• Positional arguments combined with config objects (solved by this PR)
• Not accounting for kebab case arguments (solved by this PR)

Questions

• Are there any other sources of values that I'm not accounting for? (I would rather not have another follow up PR for a third source 🤦 )
• Is there a better way to write the logic? It works, but I can't help but think there's a more elegant solution.

BEGIN_COMMIT_OVERRIDE
fix: veriadic arguments override array provided in config (the same as multiple dash arguments).
END_COMMIT_OVERRIDE

[bcoe]

What's the specific breaking change this will expose ... if it's behavior that people would never want, and no tests caught it, then I could imagine us not taking this as a major change -- worst case perhaps we could put this behavior behind a flag, to help people bumping into issues, and then swap the default value in the next major.

[aol-nnov]

@bcoe I'm not sure I understand you correctly. Does your comment states this change will not be included until next major release unless it is hidden behid a flag or the other way around - it is for such an uncommon (rare) case that the author should not worry about any breakage?

[bcoe]

Thinking on this one a bit, a couple things jump out at me:

1. Rather than implicitly deciding whether to concat values, based on whether a default value has been configured for a key, better that we figure out a way to track (during parsing) whether a default value has been used -- we've talked in the past about adding an isDefaulted method, this would be a great feature for users, and would also allow us to simplify this logic.
2. Providing config feels different than default values, and I could imagine 50% of people wishing that values would be combined, and the other 50% wishing for the opposite behavior. This makes me think that rather than taking this as a breaking change, we'd do better to introduce a parser flag, to allow folks to configure which approach is taken.

[jly36963]

Questions:

• I added helpers (eg. isDefaulted). Will they need to be changed to accommodate aliases, or configurations like strip-dashed?
• Should an option for overwrite-config or combine-config be added, so that the behavior around merging config & user provided arrays can be configured?

[bcoe]

@jly36963 thank you for this great work 👏, I will make an effort to review soon.