Add Drush support to Configuration Synchronizer

Looks great, thanks!

I'm trying to find time for major refactoring in #2615146: Analyze diffs to do safe synchronization of customized configuration and #2678946: Repurpose core's config synchronization, so I'm slightly unsure of how that would affect these commands, but I'm comfortable meantime adding these.

Didn't get this applied before major refactoring in #2793027: Refactor to use Configuration Provider and #2678946: Repurpose core's config synchronization. Will now need to be reworked to use new approaches

Is there any other related work likely to come in the next few days/weeks that is worth holding out for first?

I think the major refactoring is done.

I've also been thinking that it would be good to have an option to the drush command like --module-dir, to allow 'reverting' all modules within/below a certain directory

Two relevant changes in the recent refactoring.

First, I've removed the code that was specific to a particular extension. Instead, all changes from all extensionns are merged all at once.

The main reason for this change is dependency handling. Often, particularly with features, a given module's configuration may depend on that provided by other modules, so updates are best done as a set.

Also, for directories other than config/install, changes in a particular module may trigger changes in other modules. For example, configuration provided by Module A may satisfy config dependencies of Module B's config/optional items, meaning, again, that updates are best done as a set.

Second, this module can no longer be used for reverting in the sense we used the term in D7. Instead, all changes are merged into the active configuration, retaining any overrides that have been made.

The initial Drush work seems to be two commands, one to initialize the merged configuration storage and one to run imports. Because we're reusing core's config sync importing, the second should be very similar to what's already in drush config-import.

@james.williams: I think it's worth at least exploring if/how config_sync could continue to meet your use case. I've just posted two issues to try to capture at least most of what would be needed:

• #2797291: Make retaining active storage values optional.
• #2797273: Enable filtering the data returned by extension. (On Configuration Provider, a new dependency of Configuration Sychronizer.)

I'm definitely open to doing this and at first glance it doesn't look prohibitively difficult. Could you look over the two issues and see if they capture what you'd need?

@james.williams: thanks for the update. Even if it doesn't end up meeting your own requirements, this conversation's been a useful spur to improvements here in config_sync, so it's all good.

This looks great!

+++ b/src/Commands/ConfigSyncCommands.php
@@ -0,0 +1,161 @@
+  public function syncUpdate($options = ['retain-overrides' => FALSE]) {

For 'retain-overrides', in ConfigSyncInitializerInterface, the corresponding parameter is named $retain_active_overrides and the default value is TRUE. It also defaults to TRUE in the UI:

      $form['retain_active_overrides'] = [
        '#type' => 'checkbox',
        '#title' => $this->t('Retain customizations'),
        '#default_value' => TRUE,
        '#description' => $this->t('If you select this option, configuration updates will be merged into the active configuration, retaining any customizations.'),
      ];

We should be consistent with the naming and default value. Since we're in alpha it's fine to change the interface.

Let's use 'retain-overrides' in Drush and change retain_active_overrides to retain_overrides in the interface and elsewhere in the code base. It's shorter to enter at the Drush command line.

For the default value, there are probably two main use cases for Configuration Synchronizer. The first is to safely merge configuration changes from extensions into the active configuration. In this use case, the desired value is TRUE. The second is to revert the site's configuration to the current state of extension-provided versions. In this use case, the desired value is FALSE.

Since I wrote the module primarily for the first use case, I put it as the default. It may turn out use case 2 is equally or more used, but it's probably too early to tell. For now I suggest we switch the default to TRUE in the drush command.

Agreed, that sounds like the way to go.

Nice, thanks! This will fill a major gap in the module. Unless there are other pending changes, once this is committed, we should put out a new alpha release.

Thanks! I've added a note about using Drush to the project page. Please feel free to refine that, and also to add your company to the "supporting organizations" for the project.