Zend Pimple Config Laravel Package

Getting Started

Start by installing the package via Composer: composer require zendframework/zend-pimple-config. This package assumes you already use Pimple (v3+), so ensure it’s present. The core class is Zend\PimpleConfig\Config, which loads and aggregates configuration. The first use case is typically bootstrapping a lightweight app: create a config.php (or .config directory with global.php, local.php, etc.) that returns an array or ArrayObject (Zend-style), then feed it into Config. Example:

use Zend\PimpleConfig\Config;
use Pimple\Container;

$config = new Config([
    'config_path' => __DIR__ . '/config',
]);

$container = new Container();
$config->populate($container);

The populate() method merges all discovered config files and injects them into the container as parameters (e.g., db.hostname becomes $container['db']['hostname'] or via offsetGet()), and can also register services if factories or invokables keys are present.

Implementation Patterns

Use layered configuration: define global.php (default settings) and local.php (local overrides, ignored in VCS) in config/. The Config object automatically loads both, with later files overriding earlier ones. For environment-specific behavior (e.g., dev vs prod), use config/config.php that returns ['environment' => 'prod'], then conditionally include prod.config.php in your config path.

Key patterns include:

• Declarative wiring: Define services as invokables (class → service name) or factories (callable + dependencies), avoiding imperative container setup.
• Parameter injection: Embed config values (e.g., API keys, feature flags) as scalar parameters, making them testable and overridable.
• Lazy service loading: leverage Pimple’s lazy resolution while keeping wiring centralized and read-only in config files.

For microservices, create a single config.php that returns a nested array (db, cache, services, etc.), then call populate() once on container init. Keep config files as pure PHP arrays for speed and clarity — no YAML/JSON needed.

Gotchas and Tips

• ⚠️ No auto-creation of nested arrays: Pimple doesn’t auto-vivify nested offsets (e.g., $container['db']['driver'] fails if db isn’t defined). Always pre-initialize parent keys ('db' => ['driver' => 'mysql']) in config.
• ⚠️ Factory signatures must match Pimple expectations: Factories receive the container and must return a value — no autowiring, so inject only via closures or named parameters.
• ⚠️ No native environment variable interpolation: Unlike Symfony’s Config component, this package doesn’t resolve %env(VAR)%. Do pre-processing manually or use $_ENV in config files.
• ✅ Tip: Use Config::getMergedConfig() after population to dump final config for debugging or caching.
• ✅ Tip: Override defaults via new Config(['config_path' => $path, 'config_cache_enabled' => true]) if you add caching manually (note: package itself has no cache built-in — just aggregates sources at runtime).
• 🛠️ Extension point: Subclass Config to add custom processing (e.g., JSON schema validation, nested secrets decryption).
• 📌 Note: Last updated in 2019, archived — suitable for stable, low-risk apps but consider migrating to container-interop + symfony/config for active support.