Yargs: Nested object/key path bug fixes & improvements

[diesal11]

The parsed argv object from yargs-parser returns values for argument names with dots . as nested object values. Currently not all API methods correctly support nested objects, while other methods could potentially feature better support for objects.

This issue will track all bug fixes and proposed features for bringing nested object support up to scratch throughout the Yargs API.

Issue List

Collection of current & previous issues relating to nested objects:

• [ ] Implies always fails when the value key is a nested value #1190
• [ ] Options defined with dot notation not detected by demandOption #995
• [ ] A comment in #995 also mentions issues with the help output when .option key is a nested path
• [ ] coerce doesn't apply to dot-notation options #1021
• [ ] introduce object type #890 (See below comment)

I've also included previously closed issues as i feel this is a good opportunity to re evaluate the behaviour described in these issues. No doubt there are more issues to add to the above list, I haven't had time to thoroughly test the entire Yargs API and I only skimmed through the repos issues so I may have missed some, but i'll inevitably catch them when testing the full API myself. I'll keep the above list updated as i go.

I had previously opened a PR which addresses the first two issues which relate to the Validator (#1191) As described in the PR, I think that the majority of these issues across the repo should be addressed by using helper functions similar to lodash ._get or _.set

If there are any other issues people think need addressing then describe them below and I can add them to the list :)

[diesal11]

Object Type

Outside of the bugs above I like the idea of creating an object type, only allowing nested values on that key. Perhaps it should be required (and/or assumed) when a key has nested values defined? Take the following configuration:

var args = require('yargs')
  .option('foo', {
      type: 'string'
  })
  .option('foo.bar', {
      type: 'number'
  })
  .argv;

Currently if --foo=baz & --foo.bar=42 are set then the resulting ‘foo’ value is an array like: ['baz', { bar: 42 }] and foo.bar isn't accessible.

If object was a supported or required type this could remove ambiguity in the above configuration and allow validation against object keys from yargs-parser.

It could also be used for features that could be expanded upon using Objects like coerce, which could then run coerce every property on the object.

[bcoe]

@diesal11 this summary of work is amazing, and it would be great to close all those issues; I fully endorse you taking this on.

With regards to Object Type, I love this idea; I wonder if instead of calling --foo causing an error, if foo is an object, we should make it so --foo initializes an empty object {} -- this way, you could have a default object like {foo: 'bar'}, and use --foo to reset it to {}?

[bcoe]

@diesal11 I'd add, why don't you join our slack when you have a chance, good place to coordinate work outside of issues.