DrupalKernel requires a Drupal\Core\*\Plugin directory for annotated classes to be discovered

I did add this to avoid having to parse tons of components folders for nothing. We're talking about 80 folders * dozens of plugin types, that's a lot of file_exists() checks...

For now, let's simply make the condition more complex + add the expected directory names of core plugin types that may exist.

Alternatively, we could as well hard-code a few component names; e.g., $component === 'Form' || $component === 'Render' + skip the is_dir() checks altogether. That might make even more sense.

Perhaps we should even consider to convert the entire condition to that approach, but separate issue.

--- a/core/lib/Drupal/Core/DrupalKernel.php
+++ b/core/lib/Drupal/Core/DrupalKernel.php

+++ b/core/lib/Drupal/Core/DrupalKernel.php
@@ -1017,7 +1017,7 @@ protected function compileContainer() {

@@ -1017,7 +1017,7 @@ protected function compileContainer() {
       $path = DRUPAL_ROOT . '/core/lib/Drupal/' . $parent_directory;

There is a little bit documentation above here

One alternative approach could be to just specify the Plugin directories directly in the core.services.yml file, for example.

This is probably a really bad solution but this should just give some idea.

     // Get a list of namespaces and put it onto the container.
     $namespaces = $this->getModuleNamespacesPsr4($this->getModuleFileNames());

Apparently, we're unconditionally adding all namespaces of all modules, regardless of whether they have any plugins. — FWIW, it's a bit pointless to do this optimization for Component + Core, while checking all (possibly a lot more) module namespaces anyway.

Thinking through all available options, I think the current implementation is fine. Adding an empty Plugin subdirectory isn't really a problem.

The only other sensible option would be to fully hard-code the entire list of component/core namespaces, so as to skip the directory scan altogether (because it will always yield the same result anyway).

As discussed, I'm ok with either just hardcoding a list (but a container parameter seems overkill to me, nobody will add something in there, and if they really do, they could do it in service builder alter or something?) or just extend the existing folder check to include Render and Entity. I don't think we will be adding more top level directories like that?

meh okay.

Just wondering if it's worth to micro-optimize this and talk about the order of checks (e.g. plugin first because that is the most common one?). But OK with this as well.

Does need an issue summary update, though.

I agree #15 we should optimise for the most common use case. Plus yep an issue summary update is needed.

Committed 305b2f3 and pushed to 8.0.x. Thanks!