Weblibs Configmanager Laravel Package

Getting Started

Install via Composer and confirm the autoload namespace matches the source tree before writing any code:

composer require clagiordano/weblibs-configmanager

Then look, in this order:

1. composer.json — check the autoload PSR-4 prefix and the PHP constraint. This library predates PHP 8.1 and its constraint may block installation on modern stacks.
2. src/ — the package is small (a handful of classes); reading the manager class end to end takes minutes and is faster than guessing the API from the README.
3. tests/ — the tests are the most reliable specification of behaviour for edge cases like missing keys and nested access.
4. README.md — quickstart examples, but verify against src/ since documentation may lag behind the last 2021 release.

The first realistic use case is a plain PHP project with a config.php that returns an array:

// config/app.php
return ['db' => ['host' => '127.0.0.1', 'port' => 3306]];

// bootstrap
$config = new ConfigManager();
$config->load(__DIR__ . '/config/app.php');

echo $config->get('db.host');   // confirm dot-notation support in src/

If you need runtime persistence (write a value back to the file), that is the second use case and the reason to choose this over a plain require — treat it as the differentiator and validate it early with a scratch file.

Implementation Patterns

Wrap it, don't scatter it. Bind the manager behind a small interface so the rest of the codebase never sees the package API directly. This is the single most valuable pattern given the package's age and 16-star footprint — it makes replacement trivial.

final class AppConfig
{
    public function __construct(private ConfigManager $manager) {}

    public function get(string $key, mixed $default = null): mixed
    {
        return $this->manager->has($key) ? $this->manager->get($key) : $default;
    }
}

Laravel integration. Register a singleton in a service provider and publish the config file path from config/:

$this->app->singleton(ConfigManager::class, function () {
    $manager = new ConfigManager();
    $manager->load(config_path('app.php'));
    return $manager;
});

Prefer injecting ConfigManager (or your wrapper) over resolving it from the container inside methods — it keeps tests fast and explicit.

Environment layering. Keep a base config/app.php and overlay per-environment files by loading base first, then the environment file. Whether the manager merges or replaces on repeated load()/set() calls is a behaviour you must confirm in src/; if it replaces, do the merge yourself before handing the array over.

Write path as a controlled operation. When persisting, build the full array, write to a temp file, then rename() — atomic on the same filesystem. Never let the library write directly over a live config if multiple processes read it.

Testing. Point the manager at a fixture directory (or vfsStream for virtual files) and assert both read and round-trip write behaviour. A thin wrapper makes these tests independent of the package's internals.

Gotchas and Tips

• Maintenance risk. Last release was July 2021 with zero dependents — assume no security patches. Pin the version, run it through your CI on your target PHP, and keep the wrapper boundary so a swap to vlucas/phpdotenv-style config or Laravel's own repository stays cheap.
• File writes need explicit permissions. Config files are typically deployed read-only. Writing will throw or silently fail depending on your error reporting; check is_writable() before attempting persistence and fail loudly.
• Dot notation is an assumption. Many small config managers use get('a.b.c'), others require array access get(['a','b','c']), and some treat dots as literal characters in keys. Read the accessor implementation before designing your key convention around it.
• Missing keys. Determine whether get() returns null, throws, or triggers a notice for an absent key — this drives whether your wrapper's default-value path is safe.
• Arrays must be returned, not echoed. A config file that accidentally outputs whitespace or returns null will produce confusing failures. Keep config files free of <?php trailing output and closing tags.
• OPcache. PHP config files included from disk are cached by OPcache. After a runtime write, the in-memory cache may serve stale values until invalidation — call opcache_invalidate($path, true) if you rewrite files in a long-running process (Octane, queue workers).
• Type coercion. Values read back from a written PHP file lose types that aren't representable in a var_export-style array (e.g. objects, closures). Store scalars and arrays only.
• Extension points are thin. Expect no plugin system — extension means subclassing or composition. Composition (the wrapper above) is safer than subclassing since internal method signatures are unversioned contracts at this point.
• Debugging tip. When a lookup misbehaves, var_export() the entire loaded array first; it distinguishes "key not loaded" from "key lookup broken" in one step.