Laminas Modulemanager Laravel Package

Product Decisions This Supports

• Framework/runtime commitment. Adopting this package is not a library choice, it is a platform choice: it only earns its keep inside a Laminas MVC or Mezzio application (or a Zend Framework estate mid-migration). The real decision it informs is "do we standardize on Laminas for this service, or do we standardize on Laravel/Symfony?" Treat it as an architecture decision record, not a dependency ticket.
• Modular monolith vs. microservices. The dependency-aware module ordering and Module.php bootstrapping contract let you carve a large application into bounded contexts (Billing, Identity, Catalog) that boot in a declared order, share a DI container, and can be enabled per deployment. That is a credible middle path when a microservices split is premature — use it to defer infrastructure spend by 2–4 quarters.
• Build vs. buy. The package does three unglamorous things — module discovery/autoloading, config aggregation with *.global.php / *.local.php precedence, and ordered lifecycle events. Hand-rolling that is roughly 2–4 engineer-weeks plus permanent maintenance, and you will get the precedence rules subtly wrong. BSD-3-Clause, actively released (2025-10-17), maintained under the Laminas project umbrella. Buy.
• Multi-product / multi-tenant packaging. Module enablement lists are a natural feature-flag and edition mechanism (Community vs. Enterprise editions as different enabled-module sets). This supports pricing/packaging roadmap items without a separate entitlement service.
• Config environment strategy. The global/local config split is a governance decision as much as a technical one: it defines how environment overrides ship, where secrets live, and what a "config change" review looks like. Decide this before onboarding the third module, not after.
• Migration sequencing. If you own a Zend Framework application, this package is the load-bearing piece of the Laminas migration. It gates the timeline for everything downstream (MVC, ServiceManager, authentication), so it belongs on the roadmap as a milestone, not a task.

When to Consider This Package

Adopt when all of the following hold:

• You are on, or committed to, Laminas MVC or Mezzio — or you are maintaining a Zend Framework application with a funded migration path.
• You have, or will have, more than a handful of cohesive feature areas that need to register their own config, services, and boot logic without centralizing all of it in one bootstrap file.
• You need deterministic boot order because modules have real dependencies on each other's services or event listeners.
• You need shared modules across multiple applications (admin app, API app, CLI worker) from one codebase.
• You want a per-deployment or per-edition module toggle rather than forking config.

Look elsewhere when:

• You are a Laravel shop. Laravel already provides the equivalent layer: Composer package discovery, service providers, register()/boot() ordering, and config/*.php merging. Pulling in laminas-modulemanager alongside Laravel gives you two competing bootstrapping and config systems and zero incremental value. This is the most likely misfire for a Laravel-focused evaluation — flag it early before an engineer prototypes it.
• You are on Symfony — Bundles plus Flex recipe handling already cover discovery and config aggregation.
• You only need dependency injection. Reach for a PSR-11 container (PHP-DI, laminas-servicemanager standalone) rather than adopting a whole module system.
• Your app is a small, single-purpose service. One bootstrap file and one config array are cheaper to read than a module abstraction.
• You need a large, loud community. 29 GitHub stars is a misleading metric for a component that ships inside a framework monorepo, but it is an accurate signal about the volume of third-party tutorials, StackOverflow answers, and candidate familiarity you can lean on. Budget for internal documentation.
• You require vendor SLAs. There is no commercial support tier here; sustainability depends on the Laminas project's ongoing funding and contributor pool. Have a contingency note in the risk register.

Gating questions for the review: Which application(s)? What is the module count in 18 months? Who owns config precedence documentation? Who is our internal Laminas subject-matter expert, and what is the bus factor?

How to Pitch It (Stakeholders)

To executives — one paragraph: This is a free, permissively licensed (BSD-3-Clause), actively maintained component that gives our PHP application a clean internal structure: independent feature modules that register their own configuration and services, load in a guaranteed order, and can be switched on or off per deployment or product edition. The business value is threefold — it lets us ship a modular monolith instead of funding a premature microservices program, it lets us package Community and Enterprise editions from one codebase via enabled-module lists, and it avoids roughly a month of engineering on plumbing we would otherwise write and maintain ourselves. It carries no license cost and no vendor lock-in beyond the framework decision we are already making. The main risk is not technical but organizational: the Laminas ecosystem is smaller than Laravel's, so we should deliberately build internal documentation and avoid a single-person dependency.

To engineering — the practical case: It handles module autoloading, Module.php lifecycle (load, bootstrap, mergeConfig), dependency-aware ordering, and config merging from module config plus config/autoload/*.global.php and *.local.php. It is event-driven, so you can hook the lifecycle without patching the package. Last release October 2025, so it is being maintained. The tradeoffs you are accepting: a framework-specific contract (Module.php) that is not portable to Laravel or Symfony; config merge precedence that is powerful enough to be a footgun and therefore must be documented in the repo; and a thin public knowledge base, so onboarding relies on our own notes. If we are already on Laminas or Mezzio, this is the standard, boring answer — use it and move on. If we are on Laravel, stop: Laravel's service providers already do this job and adopting both is a net negative.