Config Laravel Package

Getting Started

The package swaps Laravel's file-backed config repository for one that reads (and writes) overrides from persistent storage, so config('app.name') or Config::get('mail.from.address') silently returns the database value when one exists and falls back to config/*.php otherwise.

1. composer require illuminatech/config
2. Publish assets: php artisan vendor:publish --provider="Illuminatech\Config\ConfigServiceProvider". This gives you a config/config.php (model, table, cache settings) and migrations for the storage table (configs by default).
3. Run migrations: php artisan migrate.
4. If your Laravel version doesn't auto-discover it, register Illuminatech\Config\ConfigServiceProvider in config/app.php — after the framework providers so the config container binding already exists.
5. Seed existing values. The package ships an artisan command (typically config:init) that walks your config/ directory and inserts rows, or you can seed manually.

Where to look first: read the published config/config.php and the README's "Usage" section — the exact persistence method (Config::set() vs. a dedicated persist()/save() on the repository) has shifted across versions, and that distinction is the crux of day-to-day use. Verify it against the README for your pinned version before writing code around it.

First use case: any value an admin needs to change without a deploy — site name, feature toggles, mail sender, pagination sizes, third-party API endpoints. Anything you'd otherwise shoehorn into a settings table.

Implementation Patterns

• Override at runtime, persist on purpose. Treat in-memory config(['key' => $v]) and persisted writes as two different operations. The repository lets you change a value for the current request without touching the DB, and separately write-through to storage. Don't accidentally call the persist path in a request loop.
• Admin CRUD over the model. The Config Eloquent model is the natural backing for a settings screen: list keys (ideally unioned with keys discovered from your config files), show the current value, and validate on save. Store the description/type so the UI can render the right input and cast the value back (see gotchas on casting).
• Import then edit. Run the init/import command on deploy to pick up new keys, then let admins edit values. Keep the import idempotent so a fresh environment gets seeded defaults.
• Cache aggressively. The repository does a DB lookup; wrap it with the package's cache layer and flush on write. Set the cache store to Redis or the database store, not array, in production.
• Testing. Use RefreshDatabase plus SQLite :memory:; seed only the keys the test cares about. Assert against config() rather than the repository so you exercise the same path the app uses.
• Multi-tenant. If you need per-tenant overrides, either scope rows with a tenant column and override the model's query, or use separate cache stores per tenant — the default repository assumes a single global config table.
• Long-running processes (Octane, Horizon, queue workers). Configuration is loaded once per process; a write in one request won't be visible in a worker already booted. Have writes flush the package cache and, for Octane, ensure the repository is rebuilt on worker recycle (or force a refresh on job start for settings-critical jobs).

Gotchas and Tips

• php artisan config:cache is the big one. The cached config array is baked from files and will bypass your DB overrides entirely. Either exclude this app from config caching, or make sure the DB layer is applied after the cache is loaded (that's what the service provider wrapper is supposed to do — confirm it still works when bootstrap/cache/config.php exists). Test both cached and uncached boot paths.
• Type fidelity. Values pass through a text column. Arrays and booleans need explicit casting (JSON/serialize or the package's type column). A stored "0" or "false" will bite you when it round-trips as truthy string — decide the cast rules once and enforce them in the model's casts.
• Provider order / binding shadowing. If something caches app('config') or resolves it before your provider registers, you get the vanilla repository. Register late and avoid resolving config inside other service providers' register() methods when possible.
• Per-request query cost. Without caching, every miss triggers a lookup on the storage table. Watch the query log on a real page; if you see repeated hits, your cache store isn't wired or is being invalidated too eagerly.
• Validation belongs on write, not on read. The repository will happily return garbage if an admin saves a bad string. Put validation in your admin controller / form request, and consider a saving model event as a second gate.
• Debugging checklist: confirm the row exists in the configs table, confirm the cache key is being cleared, confirm the provider is the illuminatech one (dump get_class(app('config'))), and confirm you're not comparing against a config:cached array.
• Extension points: the model class in config/config.php can be swapped for one with your own casts/events; the cache store is configurable; and the repository binding itself can be decorated if you need audit logging on writes.
• Maintenance risk. 149 stars and a NOASSERTION license mean you should read the LICENSE before shipping, pin the version, and be prepared to fork. It's a small package conceptually (a repository subclass plus a model and a command), so the blast radius if it's abandoned is low — but plan for it.
• Don't use it for secrets. Database-backed config is not a vault; keep API keys in .env/secret managers and reserve this for operational values.