cannot coerce/filter overrides

[boneskull]

you can coerce via command-line args, you can filter via stdin, but you can't do anything like this with overrides.

(for purposes of clarity, I'm going to refer to this function which transforms input as coerce in this issue)

1. Is there a use-case where you'd want a different coerce depending on the mode of input used? e.g., do x when prompted, but do y (and return a different type and/or value) when given a flag?
2. If not, should coerce be a top-level option, which can then be applied to the prompt (as filter), CLI args (as coerce) and overrides as a map predicate?
3. insofar as API design, imo a top-level option (with the ability to be more granular via flag.coerce or prompt.filter) would be more intuitive.

specific use-case:

keywords in package.json. this is an array. on the CLI and via prompts, the user can supply a ,-delimited string. however, passing such a delimited string in overrides does no such transformation; overrides is accepted verbatim.

example:

// current usage; supports prompt and CLI args
      keywords: {
        type: 'string',
        prompt: {
          message: 'Keywords:',
          filter: parseList
        },

proposed change:

// this applies parseList to all user input, no matter where it came in 
      keywords: {
        type: 'string',
        prompt: {
          message: 'Keywords:',
        },
        coerce: parseList
      }

in the above, if you wanted a different function for prompt.filter or flag.coerce, you could go ahead and do that. but importantly, only specifying prompt.filter would not generate a coerce function (from prompt.filter) for yargs, as it currently does; the only way to say "use this function everywhere" would be a top-level coerce.

doesn't have to be called coerce. maybe map or transform; idk. not filter. 😄

[boneskull]

(I realize translation of the provided top-level coerce function would need to be wrapped to speak yargs and inquirer--we'd still want to use much of the wrapping code, just in a different way)

[wesleytodd]

I think you are right here. The goal of those top level options is specifically to pave over this kind of detail in a reasonable way. It should be pretty simple to take the same approach used in other options where if there is a flag.coerce/prompt.filter it takes precedence, but is filled in with .coerce otherwise. Right?