zendframework/zend-modulemanager
Zend Framework’s ModuleManager helps organize and load application modules with dependency resolution, configuration merging, and event-driven initialization. It supports module discovery, autoloading, and predictable bootstrapping for modular ZF apps.
ModuleResolverListener slightly. In #5, released in 2.8.0, we added the ability to use classes named after the module itself as a module class. However, in some specific cases, primarily when the module is a top-level namespace, this can lead to conflicts with globally-scoped classes. The patch in this release modifies the logic to first check if a Module class exists under the module namespace, and will use that; otherwise, it will then check if a class named after the namespace exists. Additionally, the class now implements a blacklist of specific classes known to be non-instantiable, including the Generator class shipped with the PHP language itself.ListenerOptions option, use_zend_loader. The option defaults to true, which keeps the current behavior of registering the ModuleAutoloader and AutoloaderProvider. If you disable it, these features will no longer be loaded, allowing ModuleManager to be used without zend-loader.ServiceListener::onLoadModulesPost() that was previously emitted when a named plugin manager did not have an associated service present yet. Doing so allows plugin managers to be registered after configuration is fully merged, instead of requiring they be defined early. This change allows components to define their plugin managers via their Module classes.ServiceListener::$listeners property.ServiceListener:onLoadModulesPost() workflow to override existing services on a given service/plugin manager instance when configuring it. Since the listener operates as part of bootstrapping, this is a requirement.ServiceListener (as v3 has a dedicated method in the Zend\ServiceManager\ConfigInterface for retrieving it).triggerEvent() and/or triggerEventUntil(), and ensuring the event instance is injected with the new event name prior.$aggregate->attach($events) signature instead of the $events->attachAggregate($aggregate) signature.EventListenerIntrospectionTrait to test that listeners are attached at expected priorities.How can I help you explore Laravel packages today?