Optionally use a whitelist of config on exporting.

[anotherjames]

The --ignore-list option is very handy for excluding config you know about, but I reckon just as important a use case is for only including config you want to manage (i.e. whitelisting config as opposed to blacklisting as currently). For example, a client might set up a new view, vocabulary, image style, or node type, and you might allow that, but you can't necessarily know the config they've created in order to add it to your ignore list.
Instead, in this workflow, you actually only care about managing a known list of config, so an option could be used to switch the cexy command to only export that config that matches against that list?

I reckon a new option could be used to get this suggested whitelisting behaviour:

--partial-list=/path/to/file

Setting both a partial-list and an ignore-list would mean only things in the partial list and not in the ignore list get exported. Or could anyone suggest a better way of defining/naming the options?

(Originally raised as #2)

[anotherjames]

I have not actually tested this yet, but I just wanted to post this up for now in the meantime in case anyone has any thoughts to add that would help, or could make use of it already, as I may not get to myself for a little while.

[larowlan]

Thanks, this would be useful for install profiles, I agree

[andypost]

As I pointed in https://www.drupal.org/node/2788777 we need to decide about mix of signed/unsigned config in profiles
PS: also a good question a language translations for /optional config

[anotherjames]

Note that we've ended up rolling our own set of tools inspired by all this, as we're likely to go down a slightly different route. See https://www.drupal.org/project/cm_config_tools . The main difference is that we're working with the config_devel module to whitelist config to export, and then importing is based on what is in the /config/install sub-directory of an install profile (or multiple modules).

Since the text files of config to ignore & delete that you use are basically playing the role of manifest files, we came to our approach because modules/profiles already have an existing single suitable manifest file (their .info.yml, especially since config_devel already uses that for exporting config) and already have a store of config that core understands.