Weave Code
Php Settings Container Laravel Package
chillerlan/php-settings-container
A lightweight PHP settings container that decouples configuration logic from your application. It is not a DI container, offering typed settings objects, property hooks for PHP before 8.4, and straightforward access, merging, and serialization.
chillerlan/php-settings-container is a lightweight settings container for PHP that decouples configuration logic from your application. It provides a consistent, object-oriented way to define, hydrate, and access settings while keeping them separate from dependency injection.
- Property hooks and magic accessors for PHP < 8.4
- Typed settings objects with a clean
get()/set()API - Array and JSON serialization via
toArray(),toJSON(), andJsonSerializable - Bulk hydration from iterables with
fromIterable() - Framework-agnostic and Composer-ready
Frequently asked questions about Php Settings Container
- What is chillerlan/php-settings-container used for in a Laravel application?
- It is a small, dependency-free utility for modeling configuration as typed settings value objects instead of loose arrays. Each container is a class extending SettingsContainerAbstract that exposes typed properties through magic get and set behavior, plus array, JSON, and serialize round-tripping. In Laravel it fits as a leaf-level library inside a domain service, for example an integration's credentials and format options, or the option payload expected by chillerlan/php-qrcode. It does not replace config(), .env handling, or the service container.
- Is chillerlan/php-settings-container a dependency injection container?
- No. The package explicitly describes itself as a settings container, not a DI container. It has no concept of bindings, resolution, lifetimes, or autowiring, so it does not overlap with Laravel's service container, config repository, or service providers. Use it as a value object that you construct or hydrate yourself and keep all wiring in Laravel's container.
- Does chillerlan/php-settings-container support Laravel 11 and Laravel 12?
- There are no framework constraints or Laravel version requirements; installation is a plain Composer require with PSR-4 autoloading, no service provider, and no facade. The real constraint is your PHP floor: v4.0 requires PHP 8.4 or newer, while the 3.3.x line works on PHP 8.2 and 8.3. A Laravel 11 or 12 application on PHP 8.2 or 8.3 should pin ^3.3 and only move to ^4.0 once the runtime is upgraded.
- How do I install chillerlan/php-settings-container with Composer?
- Run composer require chillerlan/php-settings-container and choose the constraint that matches your PHP version: ^3.3 for PHP 8.2 and 8.3, ^4.0 for PHP 8.4. Avoid dev-main in production and commit the constraint to composer.json so a PHP floor bump between major lines does not surprise you. Nothing else needs registering, since there is no provider, facade, or publishable config.
- How do I hydrate a settings container from Laravel's config()?
- Write a thin adapter, such as a static fromConfig() factory or a small SettingsFactory service, that maps the array from config('services.x') onto the container's typed properties. Keep the container itself free of Laravel helpers so it stays testable and portable, and bind the hydrated instance as a singleton only if rebuilding it is expensive. Treat the container as a validated snapshot of config, never as the config layer itself.
- Can settings containers be passed to queued jobs or stored in the cache?
- The containers implement Serializable, __serialize, __unserialize, and JsonSerialize, so they can cross queue and cache boundaries, but that surface needs explicit tests before you depend on it. Serializable is deprecated in modern PHP, and behavior can differ between queue and cache drivers. If a settings object must survive a round trip, add a test that serializes and restores it and asserts every value.
- Why does a misspelled property return null instead of throwing an exception?
- Unknown properties are ignored on write and read back as null, so a typo in a config key degrades silently at runtime rather than failing fast. You can opt into stricter behavior by enabling the ThrowOnInvalidProperty attribute, which converts that into an exception. Enable it in development and tests at minimum, and assert on required values when hydrating from config().
- Does chillerlan/php-settings-container work with PHPStan and IDE autocompletion?
- Magic get and set accessors hide properties from static analysis and IDE completion, which is the main ergonomic cost of the package. It ships a rules-magic-access.neon PHPStan ruleset meant to teach your analyser about the magic accessors, and that file is worth including in your phpstan.neon. Even with it, expect some editor friction, so document the concrete container classes in docblocks.
- What are the alternatives to chillerlan/php-settings-container in Laravel?
- If you only need a typed, read-only bag of values, PHP readonly classes or a small OptionsResolver-style DTO get you there with no dependency and full static analysis support. Spatie's laravel-data or Symfony's OptionsResolver are heavier but more established when you need validation, casting, or array-to-object mapping. Choose this package mainly to satisfy the SettingsContainerInterface expected by another chillerlan library such as php-qrcode, or when you specifically want property-hook behavior below PHP 8.4.
- Who maintains chillerlan/php-settings-container and is it risky to depend on?
- The project is effectively single-maintainer with a small star count and almost no external dependents beyond the author's own libraries, so the bus factor is real. Code quality and CI are reasonable, and the v3 to v4 transition was a clean PHP floor bump, but nothing guarantees future majors stay that tame. Pin the version, watch releases, and keep your adapter thin so switching to a readonly class later stays cheap.
Weaver
How can I help you explore Laravel packages today?