Shared configuration for migrations

NW to rename the plugin to "migrate_include/MigrateInclude". Tagging novice, because code refactor like what I just mentioned should be PHP novice stuff.

1. +++ b/src/MigrateSharedConfigPluginManager.php
   @@ -0,0 +1,65 @@
   + * @code
   
   --- /dev/null
   +++ b/src/SharedConfigIncludeHandler.php
   

   We should also point to src/SharedConfigIncludeHandler.php (which should be renamed to src/MigrateIncludeHandler.php). From here.

2. +++ b/src/SharedConfigIncludeHandler.php
   @@ -0,0 +1,35 @@
   +final class SharedConfigIncludeHandler {
   

   We should add some documentation here on how this should be invoked in a migrate yaml. Examples of a single and multiple includes would be good.

Is migrate_tools the right place for this module? Should it move to plus? Should it be in a new module namespace entirely? I really don't like that last option. It seems troublesome for discoverability of the feature. Plus is maybe the right place. But we're introducing it for the sake of tools, so we can (re)move some of the drush commands into upstream drush.

I wouldn't do any module naming changes. Those can be done after #3 is addressed.

hi @andregp, I think you tried to do a module name change? Let's reverse those parts. And only rename the plugin & classes. Also, when doing incrimental changes like this, an interdiff is really helpful.

+++ b/src/Commands/MigrateToolsCommands.php
@@ -391,7 +391,7 @@ class MigrateToolsCommands extends DrushCommands {
     'update' => FALSE,

This file should not be renamed. Rolling that back would clear up even more noise in the patch.

+++ b/src/Commands/MigrateToolsCommands.php
@@ -15,7 +15,7 @@ use Drupal\migrate\Plugin\RequirementsInterface;
+use Drupal\migrate_tools\MigrateInclude;

This shouldn't rename. It will greatly reduce the noise in this patch too if you back out that change.

Don't rename MigrateTools utility class.

This is passing green locally. I want to get some feedback on it, but I think it is a distinct possibility this will let us get to a place where migrate tools and drush 10.4+ can co-exist again.

Also, refer to the linked change record for more fully details on how this patch would work. And any input on what version 5.2 or 6.0 this feature should be released into.

re #22:

Migrate_tools could add a schema entry. But it isn't strictly required. You can use shared config with migrate plus config entities or with core's yml based migrate plugins. I'm using less and less of migrate plus config entities these days, so I hadn't really thought about needing a schema entry. Does it need one?

I'm leaning towards put this into a 6.x branch so I don't have to worry about breaking as many things. Ergo, bumping a few things in the composer.json/.info.yml.

Automated testing will fail until Drush 11.0.6 is released. But those failures are related to issues in Drush's testing classes, not the classes under test. Tests pass as-is with Drush ^10.6 on local. Watch for a quick-follow to make the code work with PHP 8.1.