Which Zend Framework config merge rules create ambiguity for repeatable development environments

In Zend Framework 3 (and its successor Laminas), the primary source of ambiguity for repeatable environments is the **ordered array merge strategy** used by the ModuleManager. Because the framework does not enforce a strict environment hierarchy, the final state of the configuration depends entirely on the sequence in which modules and configuration-glob paths are loaded.

The Precedence Rule

The ModuleManager iterates through the modules list defined in `application.config.php`. For each module, it retrieves the `module.config.php` and merges it into a global configuration array. The merge follows these rules:

• String Keys: If two modules define the same string key, the module loaded later in the list will overwrite the previous value.
• Integer Keys: If the key is an integer, the values are appended to the array rather than overwritten.
• Nested Arrays: The framework performs a recursive merge. However, if a nested array contains integer keys, it will result in appending, potentially leading to duplicate entries in configurations like routes or service factories.

Environment Hierarchy Ambiguity

The lack of an explicit environment hierarchy (e.g., a native "base-vs-override" toggle) means that developers often rely on `config_glob_paths` in `application.config.php`. A typical setup looks like this:

'config_glob_paths' => [
    DIRECTORY_SEPARATOR . 'config/{{,*,*,*,*,*,*}}.php' => true,
    DIRECTORY_SEPARATOR . 'config/autoload/{{,*,*local}}.{%global,local}' => true,
],

Because these globs are processed *after* all module configurations, a `local.php` file always has the final say. The ambiguity arises when developers conditionally include environment-specific logic inside `module.config.php` itself rather than using the globbing mechanism, leading to "works on my machine" scenarios where local overrides break CI.

Laminas Migration vs. ZF3 Repeatability

The decision to migrate to Laminas or stay on ZF3 affects repeatability primarily through dependency stability. While the merge logic remains functionally similar, Laminas introduces stricter typing and updated component versions. To evaluate this against repeatability requirements:

• Dependency Locking: If your environment relies on specific legacy behaviors of the ZF3 ServiceManager that were changed in Laminas, a migration will break the environment's state.
• Namespace Consistency: Laminas projects move toward more explicit configuration-driven patterns. Staying on ZF3 risks using unpatched modules that may behave differently on modern PHP versions, breaking repeatability over time.

Steps for Repeatable Setup

1. Explicitly Order Modules: Ensure the `modules` array in `application.config.php` is sorted identically across all environments.
2. Avoid Integer Keys in Config: Use string-based keys for all service and route definitions to prevent accidental appending during recursive merges.
3. Use `local.php` for Secrets: Keep environment-specific secrets strictly in `config/autoload/local.php` and ensure this file is ignored by git but templated correctly.