Laminas Config Aggregator Laravel Package

Product Decisions This Supports

• Configuration architecture for modular monoliths and multi-tenant deployments. This package lets you compose application configuration from many small, ordered sources (PHP files, and via laminas-config, YAML/JSON/XML/INI) with deterministic precedence — later entries win. That directly supports roadmap decisions around config layering: base defaults → environment overlays → tenant/customer overrides → secret injection. If your roadmap includes per-tenant or per-region configuration variants, this is the composition primitive you'd otherwise hand-roll.
• Build vs. buy on config plumbing. The "build" alternative is a bespoke config/*.php glob loader with array_replace_recursive, plus a homegrown cache writer. This package is ~a few hundred lines of well-tested code that already handles glob portability (FreeBSD, IBM i), deduplication of providers, provider preprocessing, post-processors, and cached bootstrap. Buying is the defensible call unless config composition is itself a differentiator.
• Performance/p95 work on cold start. The built-in cache generation (with configurable cache file mode) is the concrete lever for reducing bootstrap cost in production. This is a decision you can put on a reliability/performance roadmap: "config aggregation + compiled config cache" as a single initiative with an observable latency win.
• Derived/computed configuration as a first-class feature. Post-processors (added in 1.1.0) accept the merged array and return a new one — the documented use case is referencing one config key from another, Symfony ParameterBag-style. That unlocks a product decision to stop duplicating values (e.g., single source of truth for a service URL referenced by three subsystems) rather than a per-team convention.
• Ecosystem/tech-stack bets. If you're deciding whether a Laminas/Mezzio service is supportable long-term, this library signals a maintained, modern baseline (PHP 8.2–8.5 supported across recent releases, Psalm at v6, PHPUnit 10). Conversely, if you're standardizing on Laravel, this is not a Laravel-native component and adopting it implies a parallel config paradigm.
• Explicitly not supported: multi-environment config management (secrets storage, remote config services, feature flag propagation). This is a file-and-array merger, not a config control plane. Do not put a roadmap bet on it delivering dynamic config.

When to Consider This Package

Consider it when most of the following are true:

• You are on PHP 8.2+ and comfortable with an explicit, code-first config composition model. (Latest minors drop 8.1 and add 8.5; the project moves with PHP releases promptly.)
• Configuration already lives in, or can cleanly move to, discrete files with clear ownership — *.global.php per module, plus environment-specific overrides.
• You need ordered, predictable merge semantics and want that behavior to be a documented contract rather than an emergent property of your own loader.
• You want a production config cache so bootstrap doesn't re-parse N files per request, and you care about the cache file's permission mode.
• You want post-processing hooks to compute derived values or resolve parameter references instead of copying values between config files.
• Your team can accept the dependency chain: laminas-stdlib (glob compatibility), brick/varexporter (cache export), and optionally laminas-config for non-PHP formats.

Look elsewhere when:

• You are building on Laravel. Laravel already ships a config repository, environment-driven .env loading, config:cache, and Config::get() with dot notation. Introducing this package creates two competing config systems, two caching stories, and a confusing onboarding path. The honest recommendation for a Laravel codebase is to use Laravel's config layer and not add this.
• You need runtime/dynamic configuration — per-request overrides, remote config, flags, hot reload. This package resolves at bootstrap; it is not a control plane.
• You need secrets management. Nothing here encrypts, validates against a schema, or integrates with a vault. Pair it with something, or don't adopt it.
• You need schema validation. There is no built-in validation that the merged array conforms to expected shape; that's on you or a separate library.
• Adoption risk tolerance is low and the surface is trivial. If you have three config files and no multi-tenant story, a bespoke loader of 30 lines is a smaller liability than an added dependency.
• You weigh community signals heavily. Stars (43) and dependents (0 in this dataset) are low; expect to be a self-sufficient adopter who reads source, not a beneficiary of a large troubleshooting corpus. Mitigate by pinning versions and reading the small dependency tree.

How to Pitch It (Stakeholders)

To executives — the one-paragraph version: We have a decision to make about how application configuration is assembled and cached. Today this is either ad hoc per service or owned by whichever engineer wrote the loader. This package is a small, actively maintained, permissively licensed (BSD-3-Clause) library that makes config composition explicit, ordered, and cacheable, and it is kept current with PHP releases. Adopting it standardizes a piece of infrastructure that every service touches, reduces duplicate values across config files, and gives us a documented place to improve cold-start performance. It is a buy, not build, and the cost is one small dependency with two transitive libraries. The main caveat is that it is a Laminas-ecosystem tool: for our Laminas/Mezzio services this is a natural fit; for Laravel services it would duplicate existing framework capability and I do not recommend it there.

To engineering — what I'm actually committing us to:

• A config model of many small, owned files merged in declared order, later wins. This is a convention change, and it needs to be written down and reviewed, because precedence bugs are silent.
• A production path that generates a compiled config cache with an explicit file mode; the cache becomes part of deploy artifacts and must be invalidated on release. This needs an owner and a CI step.
• Optional post-processors for derived values. Powerful, but every post-processor is logic in the boot path — we accept that trade only where it removes real duplication.
• A version pin plus a quarterly check that the library still supports our PHP target. Recent release history shows PHP 8.1 support dropped and 8.5 added within the same series, so this is a live maintenance item, not a one-time setup.
• Explicit non-goals: this does not give us secrets handling, config schema validation, or runtime reconfiguration. If a stakeholder expects any of those, we should correct that expectation now rather than after integration.

Ask: approve a time-boxed spike on one non-Laravel service to measure bootstrap latency with and without the config cache, then decide on broader rollout based on that number.