Problem/Motivation
If people want to tweak existing plugins the only way at the moment is to extend and add a new plugin with a different functionality.
For example:
- It's impossible to tweak the default schema of a field being generated by a core field plug-in.
- It's impossible to tweak UI for such customization.
In the end people are just doing separate field type plugins that result in non-semantic distribution of fields, for example:
- String
- String with index.
- String with unique index.
- Short string.
- ... etc.
It is an awful DX, because once you define a new field type, there is no way to reuse existing widgets and formatters for it. You need to define new ones as well (even if they are dummy ones - empty class bodies).
This can be extended, as we can have more granular and single-purpose decorators for whole plug-in types. Imagine the whole logging related to a plugin hierarchy can be standardized by a single decorator implemented by the module maintainer.
Proposed resolution
It will be awesome to have a mechanism that will allow for concrete plugins to be decorated (somehow) based on the interface they expose. This should work in a similar fashion to the services decoration provided by the container.
Plugin decorators should be also decoratable.
Remaining tasks
Discussion, architectural idea for implementation patches etc...
User interface changes
None expected out o this change.
Contributed code will have better capability to customize core's behaviors.
API changes
API addition on the plug-in system.
I am imagining a standard trait to be added to plug-in managers that will decorate plugins after they are fetched by ID.
Data model changes
TBD.