No matter what I do, I can't swap the class of the SDC plugin

Fixing IS. This is ready for review

As mentioned in Slack, the main reasons behind unalterability are:

1. To ensure that all the code in charge to render a component is in the single directory.
2. To protect ourselves from BC breaks when transitioning from experimental to stable.

I feel strongly about #1, but I think we can allow some extensibility while keeping that feature.

I think we can introduce the plugin manager interface after we move the classes to their final destination in 📌 Move code from the experimental SDC module to core Fixed . That will allow decoration of the plugin manager, which will open the possibility you mention.

Also note that we also have 📌 Make SDC extensible Active as well (which I haven't had time to properly respond to yet).

Seems like this is postponed on 📌 Move code from the experimental SDC module to core Fixed

But now it crashes in `\Drupal\sdc\Twig\TwigComponentLoader::__construct()` because the plugin manager, passed as 1st argument, is strict-typed to `\Drupal\sdc\ComponentPluginManager`, so I can't pass the custom class that swapped SDC plugin manager.

On re-reading the IS, I think we could introduce an interface and change the type hints to that interface. Perhaps that could be the extend of this issue?

Re #7

To ensure that all the code in charge to render a component is in the single directory

Is there any way to enforce that other than blocking the plugin definition alteration? Maybe implement own $this->alterInfo('sdc_info'); that selectively do enforcements, i.e. is not blocking the class swapping

Sry for working on this postponed issue, but I find it pretty hard to decorate services without an interface. There are several places where those services are getting injected and defining the type directly on the final class.
The work done here helped me already a lot, so I hope it's ok to add another interface here for now.

@e0ipso Are there plans to add those interfaces to core? I cant find any reference to this on the related issue.

+1 for the interfaces... I am currently trying to write some units tests for functionality that relies e.g. on ComponentPluginManager and it is impossible to mock these SDC services at all without adding some wrapper methods in my own classes that I can swap out during tests. Additionally this also prevents the sdc module itself from providing unit tests (which it actually should do to test all code on a low execution level).

So please do not restrict everything within this module only to keep the "single directory" methodology intact - IMHO developers writing extensions for this, should be free to do so.

The patch from MR 5035 is not applicable for Drupal 10.3.x, so i rewrote it