- Issue created by @DimaS11
- 🇨🇦Canada gapple
This raises a couple issues from Drupal core:
- Thelibrary.discovery
service is now implicitly expected to have the additional methods fromCacheCollectorInterface
(e.g.clear()
is also called fromModuleInstaller
), even thoughLibraryDiscoveryInterface
doesn't include them.
-destruct()
is being called on a decorator service which does not have theneeds_destruction
tag - because the decorated service does: 🐛 Container compile crash when a service decorates a destructable service Needs workSymfony's documentation doesn't include the
needs_destruction
tag in the ones it lists as being copied from the decorated service to the decorator (https://symfony.com/doc/current/service_container/service_decoration.html), but\Drupal\Core\DependencyInjection\Compiler\RegisterServicesForDestructionPass::process()
applies thekernel.destructable_services
parameter to the service, which appears tied to the service name and not the actual implementing class (and so is called on the decorator by\Drupal\Core\DrupalKernel::terminate()
).----
Service decorators should not extend their decorated class.
Decoration allows stacking alterations to the public interface of the original class, without concern for if the next layer of the stack is another decorator or the original service - or even if the original service has been swapped for a different implementation. However, if a decorator extends the original class then it will not proxy calls properly to the next layer of the stack.
The quickest change is to add proxy methods for just the additional ones used on the library discovery service (
clear()
anddestruct()
), but to prevent potential other issues if service consumers use the methods ofLibraryDiscoveryCollector
and not justLibraryDiscoverInterface
, the decorator should implement and proxy all the methods ofCacheCollectorInterface
andDestructableInterface
. This would also prevent problems if the service is passed somewhere that types against those interfaces.