Make SDC extensible

As related issue landed already, services without interface is allowed and accessible by classname 📌 Enable more service autowiring by adding interface aliases to core modules Fixed

I find decoration is the preferable way comparing to overrides

As related issue landed already, services without interface is allowed and accessible by classname

OK, but we need stable class name & path. If the class move, will it break? We already know SDC classes will move out of the Drupal\sdc namespace.

I find decoration is the preferable way comparing to overrides

Indeed. And we may find other good way of extending SDC.

Our main concern with UI Patterns is to add a new component plugin discovery. We will use the SDC one for the "UI Patterns 2" components, but we also need to add one for the company layer with the legacy "UI Patterns 1" components.

If sdc classes are supposed to be moved then better to decorate using service provider, it will allow to check core version and select required class.

new component plugin discovery

I think Drush example is good to illustrate usage of two discovery working at the same time (annotated and legacy)
https://github.com/drush-ops/drush/blob/a83c9ae56728dd6f99aa5d150c11e5e3...

@pdureau, what if I want to swap the SDC plugin Plugin/Component? The fact that is "final" is not a big deal, you can decorate. The biggest problem is that the plugin manager doesn't allow to alter the plugin definitions. Quoting from the plugin manager constructor:

// Note that we are intentionally skipping $this->alterInfo('sdc_info');
// We want to ensure that everything related to a component is in the
// single directory. If the alteration of a component is necessary,
// component replacement is the preferred tool for that.

Now we're still able to override the plugin manager itself but why this complication?

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

With the move of SDC to Drupal Core namespace, the final keyword was removed from Component plugin manager class, and we can know extends it and override it in service container.

However, there is no way to allow 2 classes from 2 different module to extend it. So, we may need a decoration system instead.

Now SDC in in the Drupal\Core\Theme namespace, the final keyword was removed and it is possible to decorate the plugin manager (Experience builder is already doing that).

The main obstacle for extensibility is now ✨ ComponentPluginManager must implement CategorizingPluginManagerInterface Active because a service decorator can't add an interface to the service.