Allow experimental modules to rely on \Drupal\Core\ namespaced classes that are only loadable when the module is enabled

We also need an issue to discuss @internal vs. @version (should be a separate issue per @alexpott).

Whilst discussing this issue with @catch, @xjm, @dries, @effulgentsia, @cilefen and @webchick I realised that we could use the autoloader to fix this for us. The namespaces of the code would still be \Drupal\Core\NewThing but the location of the files would be core/experimental.

Oh, I understood our call differently. I thought the location would be somewhere within the module's directory. Here's a patch for what I had in mind. No interdiff, since it's a different approach.

Basically there's quite a few things that depend on directories like plugin discovery so this is not as simple as it seems.

Hm, I haven't looked into that complication yet. Can you add a failing test to demonstrate one or several of those problems?

1. +++ b/core/lib/Drupal/Core/DrupalKernel.php
   @@ -1407,9 +1408,16 @@ protected function getModuleFileNames() {
          $namespaces["Drupal\\$module"] = dirname($filename) . '/src';
   ...
   +          $namespaces[$namespace] = dirname($filename) . '/' . $path;
   

   Nit: We can save dirname($filename) into a variable as it can be used twice.

2. +++ b/core/modules/system/tests/modules/experimental_module_test/lib/Drupal/Core/Test/ExperimentalTest.php
   @@ -0,0 +1,10 @@
   + * This class exists to test experiment class loading for classes that will be
   + * part of core.
   

   Nit: Should be one line, I think.

3. +++ b/core/tests/Drupal/KernelTests/Core/DrupalKernel/DrupalExperimentalCoreTest.php
   @@ -0,0 +1,28 @@
   +  public static $modules = ['system'];
   

   We need a different patch for 8.3.x because there should be protected static $modules.

Rerolled, 8.3.x patch and fixed my own comments.

+1 to #14, this is much easier and a nicer way to do it. (and the other code approach was not really that nice)

FWIW, it is also possible to keep BC later by having the modules stick around and just have the classes in the module extend the ones from the core/lib later.

Or it is also possible to have core/lib as empty classes that extend from the experimental module classes - though that would fail really hard if you tried to use it without the module being enabled.

--

To the discovery:

Yes, plugin discovery works based on the namespaces registered (which several of us disputed back then), however as long as the namespace in core/lib/foo is similar to core/[foo] this should work correctly as there is no special code to handle modules vs. core.

So I imagine #14 could just work (tm).

Given that its also in module/lib/Drupal/Core also should not interfere with the normal autoloader, which only checks and registers src/.

1. +++ b/core/lib/Drupal/Core/DrupalKernel.php
   @@ -15,6 +15,7 @@
    use Drupal\Core\Installer\InstallerRedirectTrait;
   
   @@ -1407,9 +1408,17 @@ protected function getModuleFileNames() {
   +          $namespaces[$namespace] = "$module_dir/$path";
   
   +++ b/core/modules/system/tests/modules/experimental_module_test/experimental_module_test.info.yml
   @@ -4,3 +4,5 @@ description: 'Module in the experimental package to test experimental functional
   +  'Drupal\Core\Test': 'lib/Drupal/Core/Test'
   

   This should handle trimming \ and / off.
   For example, this should also work:

   '\Drupal\Core\Test': '/lib/Drupal/Core/Test/'

   Okay maybe not the trailing slash, but definitely the leading one on each

2. +++ b/core/modules/system/tests/modules/experimental_module_test/experimental_module_test.info.yml
   @@ -4,3 +4,5 @@ description: 'Module in the experimental package to test experimental functional
   +namespaces:
   

   I think this needs a more specific name

Otherwise, this is pretty ingenious.

Trying a more detailed title. I don't want the title to unduly bias implementation details though. While I prefer #17 to #12, #12 might also be an ok approach, so please interpret "come with" loosely. Further improvements to the issue title are welcome.

I think "rely on" captures it better than "come with" :)