laminas/laminas-servicemanager
Powerful dependency injection and service container for PHP. Manage factories, abstract factories, delegators, aliases, and shared services, with PSR-11 interoperability and robust configuration for complex applications.
Feature release (minor)
Feature release (minor)
3.23.x bugfix release (patch)
3.22.x bugfix release (patch)
Feature release (minor)
Feature release (minor)
Introduces PHP 8.4 Support
4.2.x bugfix release (patch)
Feature release (minor)
Feature release (minor)
4.0.x bugfix release (patch)
4.0.x bugfix release (patch)
laminas-servicemanager 4.0.0 is here and finally enables projects to consume psr/container v2.0.0 after 2 years along with several type-additions and plugin manager decoupling.
The migration guide is not written yet but will be at some point (once we added support for SM v4 to other components) later.
ServiceManager#get, PluginManagerInterface#get and ServiceLocatorInterface#build now explicitly implement mixed as return-type to synchronize types with ContainerInterface#getpsr/container v1.1 and v2.0ReflectionBasedAbstractFactory via laminas-cliLaminas\ServiceManager\AbstractFactoryInterfaceLaminas\ServiceManager\FactoryInterfaceLaminas\ServiceManager\InitializerInterfaceLaminas\ServiceManager\DelegatorFactoryInterfacevendor/bin are removed in favor of the laminas-cli integration. All CLI commands of v3.x are accessible via vendor/bin/laminas servicemanager:<v3.x command name> once laminas/laminas-cli is required in the projects dependenciesConfigInterface and Config-class since these files did not provide any validation logic and were just used to proxy the configuration array structureAbstractPluginManager#validate and AbstractPluginManager::$instanceOf property as in v3.x, implementing plugin managers were able to implicitly validate mixed. In case an implementing plugin manager is providing a single $instanceOf such as laminas-cache, there is a new class AbstractSingleInstancePluginManager available which requires the $instanceOf property to be configuredAbstractPluginManager does not extend ServiceManager anymore and instead uses an own ServiceManager instance under the hood to manage plugin manager related services which can be configured the same way as in v3.xvendor/bin are now integrated via laminas-cli and can be called via vendor/bin/laminas once laminas/laminas-cli is part of the projects requirements. Read more about how to consume these commands here.AbstractPluginManager does not provide the validate-Method anymore and requires migration action such as:
AbstractSingleInstancePluginManager in case the plugin manager only provides instances of a specific interface- or class-string (please be aware that the $instanceOf property now requires native string property type)validate method and verify whatever type has to be returned and/or just allow mixed as v3.x did when omitting $instanceOf propertyConfigInterface and Config-class since these files did not provide any validation logic and were just used to proxy the configuration array structureServiceManager nor AbstractPluginManager do validate the provided configuration at runtime anymore. due to the psalm-types provided to ServiceManager#__construct, ServiceManager#configure, AbstractPluginManager#__construct and AbstractPluginManager#configure, the configuration schema is strictly typed and thus, a miss-configuration can be mitigated on static-analysis level prior actual runtimeAbstractPluginManager#get does not accept options anymore, in case an instance with options needs to be created, AbstractPluginManager#build has to be used$this to self thanks to @boesingReflectionBasedAbstractFactory mapped factories thanks to @boesingpsr/container v2 thanks to @boesing and @danielspkServiceManager#getServiceLocator method thanks to @boesingServiceManager inheritance for AbstractPluginManager thanks to @boesingAbstractPluginManager#validate thanks to @boesingServiceManager as final and change AbstractPluginManager to use composition over inheritance thanks to @boesingcontainer-interop/container-interop polyfill thanks to @boesingServiceManager#get, PluginManagerInterface#get and ServiceLocatorInterface#build now explicitly implement mixed as return-type to synchronize types with ContainerInterface#getpsr/container v1.1 and v2.0ReflectionBasedAbstractFactory via laminas-cliLaminas\ServiceManager\AbstractFactoryInterfaceLaminas\ServiceManager\FactoryInterfaceLaminas\ServiceManager\InitializerInterfaceLaminas\ServiceManager\DelegatorFactoryInterfacevendor/bin are removed in favor of the laminas-cli integration. All CLI commands of v3.x are accessible via vendor/bin/laminas servicemanager:<v3.x command name> once laminas/laminas-cli is required in the projects dependenciesConfigInterface and Config-class since these files did not provide any validation logic and were just used to proxy the configuration array structureAbstractPluginManager#validate and AbstractPluginManager::$instanceOf property as in v3.x, implementing plugin managers were able to implicitly validate mixed. In case an implementing plugin manager is providing a single $instanceOf such as laminas-cache, there is a new class AbstractSingleInstancePluginManager available which requires the $instanceOf property to be configuredAbstractPluginManager does not extend ServiceManager anymore and instead uses an own ServiceManager instance under the hood to manage plugin manager related services which can be configured the same way as in v3.xvendor/bin are now integrated via laminas-cli and can be called via vendor/bin/laminas once laminas/laminas-cli is part of the projects requirements. Read more about how to consume these commands here.AbstractPluginManager does not provide the validate-Method anymore and requires migration action such as:
AbstractSingleInstancePluginManager in case the plugin manager only provides instances of a specific interface- or class-string (please be aware that the $instanceOf property now requires native string property type)validate method and verify whatever type has to be returned and/or just allow mixed as v3.x did when omitting $instanceOf propertyConfigInterface and Config-class since these files did not provide any validation logic and were just used to proxy the configuration array structureServiceManager nor AbstractPluginManager do validate the provided configuration at runtime anymore. due to the psalm-types provided to ServiceManager#__construct, ServiceManager#configure, AbstractPluginManager#__construct and AbstractPluginManager#configure, the configuration schema is strictly typed and thus, a miss-configuration can be mitigated on static-analysis level prior actual runtimecontainer-interop/container-interop polyfill by @boesing in https://github.com/laminas/laminas-servicemanager/pull/169ServiceManager#getServiceLocator method by @boesing in https://github.com/laminas/laminas-servicemanager/pull/181ServiceManager inheritance for AbstractPluginManager by @boesing in https://github.com/laminas/laminas-servicemanager/pull/179psr/container v2 by @boesing in https://github.com/laminas/laminas-servicemanager/pull/188Full Changelog: https://github.com/laminas/laminas-servicemanager/compare/3.21.0...4.0.0-rc3
3.22.x bugfix release (patch)
ServiceManager#get, PluginManagerInterface#get and ServiceLocatorInterface#build now explicitly implement mixed as return-type to synchronize types with ContainerInterface#getpsr/container v1.1 and v2.0ReflectionBasedAbstractFactory via laminas-cliLaminas\ServiceManager\AbstractFactoryInterfaceLaminas\ServiceManager\FactoryInterfaceLaminas\ServiceManager\InitializerInterfaceLaminas\ServiceManager\DelegatorFactoryInterfacevendor/bin are removed in favor of the laminas-cli integration. All CLI commands of v3.x are accessible via vendor/bin/laminas servicemanager:<v3.x command name> once laminas/laminas-cli is required in the projects dependenciesConfigInterface and Config-class since these files did not provide any validation logic and were just used to proxy the configuration array structureAbstractPluginManager#validate and AbstractPluginManager::$instanceOf property as in v3.x, implementing plugin managers were able to implicitly validate mixed. In case an implementing plugin manager is providing a single $instanceOf such as laminas-cache, there is a new class AbstractSingleInstancePluginManager available which requires the $instanceOf property to be configuredAbstractPluginManager does not extend ServiceManager anymore and instead uses an own ServiceManager instance under the hood to manage plugin manager related services which can be configured the same way as in v3.xvendor/bin are now integrated via laminas-cli and can be called via vendor/bin/laminas once laminas/laminas-cli is part of the projects requirements. Read more about how to consume these commands here.AbstractPluginManager does not provide the validate-Method anymore and requires migration action such as:
AbstractSingleInstancePluginManager in case the plugin manager only provides instances of a specific interface- or class-string (please be aware that the $instanceOf property now requires native string property type)validate method and verify whatever type has to be returned and/or just allow mixed as v3.x did when omitting $instanceOf propertyConfigInterface and Config-class since these files did not provide any validation logic and were just used to proxy the configuration array structureServiceManager nor AbstractPluginManager do validate the provided configuration at runtime anymore. due to the psalm-types provided to ServiceManager#__construct, ServiceManager#configure, AbstractPluginManager#__construct and AbstractPluginManager#configure, the configuration schema is strictly typed and thus, a miss-configuration can be mitigated on static-analysis level prior actual runtimecontainer-interop/container-interop polyfill by @boesing in https://github.com/laminas/laminas-servicemanager/pull/169ServiceManager#getServiceLocator method by @boesing in https://github.com/laminas/laminas-servicemanager/pull/181ServiceManager inheritance for AbstractPluginManager by @boesing in https://github.com/laminas/laminas-servicemanager/pull/179psr/container v2 by @boesing in https://github.com/laminas/laminas-servicemanager/pull/188Full Changelog: https://github.com/laminas/laminas-servicemanager/compare/3.21.0...4.0.0-rc2
Feature release (minor)
ConfigInterface in ServiceManager. This provides forward compatibility with v4.0.0ConfigInterface and Config as deprecated as they will be removed with v4.0.0Config and ConfigInterface as deprecated thanks to @boesingConfigInterface psalm types in ServiceManager thanks to @boesingocramius/proxy-manager with friendsofphp/proxy-manager-lts thanks to @SlamdunkServiceManager#get, PluginManagerInterface#get and ServiceLocatorInterface#build now explicitly implement mixed as return-type to synchronize types with ContainerInterface#getpsr/container v1.1 and v2.0ReflectionBasedAbstractFactory via laminas-cliLaminas\ServiceManager\AbstractFactoryInterfaceLaminas\ServiceManager\FactoryInterfaceLaminas\ServiceManager\InitializerInterfaceLaminas\ServiceManager\DelegatorFactoryInterfacevendor/bin are removed in favor of the laminas-cli integration. All CLI commands of v3.x are accessible via vendor/bin/laminas servicemanager:<v3.x command name> once laminas/laminas-cli is required in the projects dependenciesConfigInterface and Config-class since these files did not provide any validation logic and were just used to proxy the configuration array structureAbstractPluginManager#validate and AbstractPluginManager::$instanceOf property as in v3.x, implementing plugin managers were able to implicitly validate mixed. In case an implementing plugin manager is providing a single $instanceOf such as laminas-cache, there is a new class AbstractSingleInstancePluginManager available which requires the $instanceOf property to be configuredAbstractPluginManager does not extend ServiceManager anymore and instead uses an own ServiceManager instance under the hood to manage plugin manager related services which can be configured the same way as in v3.xvendor/bin are now integrated via laminas-cli and can be called via vendor/bin/laminas once laminas/laminas-cli is part of the projects requirements. Read more about how to consume these commands here.AbstractPluginManager does not provide the validate-Method anymore and requires migration action such as:
AbstractSingleInstancePluginManager in case the plugin manager only provides instances of a specific interface- or class-string (please be aware that the $instanceOf property now requires native string property type)validate method and verify whatever type has to be returned and/or just allow mixed as v3.x did when omitting $instanceOf propertyConfigInterface and Config-class since these files did not provide any validation logic and were just used to proxy the configuration array structureServiceManager nor AbstractPluginManager do validate the provided configuration at runtime anymore. due to the psalm-types provided to ServiceManager#__construct, ServiceManager#configure, AbstractPluginManager#__construct and AbstractPluginManager#configure, the configuration schema is strictly typed and thus, a miss-configuration can be mitigated on static-analysis level prior actual runtimecontainer-interop/container-interop polyfill by @boesing in https://github.com/laminas/laminas-servicemanager/pull/169ServiceManager#getServiceLocator method by @boesing in https://github.com/laminas/laminas-servicemanager/pull/181ServiceManager inheritance for AbstractPluginManager by @boesing in https://github.com/laminas/laminas-servicemanager/pull/179psr/container v2 by @boesing in https://github.com/laminas/laminas-servicemanager/pull/188Full Changelog: https://github.com/laminas/laminas-servicemanager/compare/3.20.0...4.0.0-rc1
Feature release (minor)
Feature release (minor)
Feature release (minor)
Feature release (minor)
Feature release (minor)
3.15.x bugfix release (patch)
Feature release (minor)
psr/container v2 thanks to @boesingFeature release (minor)
Feature release (minor)
container-interop interfaces thanks to @starred-gijsFeature release (minor)
How can I help you explore Laravel packages today?