- Is mesd/settings-bundle a Laravel package?
- No. It is a Symfony bundle built for Symfony 2.x-era projects, registered through the Symfony kernel and a bundles.php-style configuration. It ships no Laravel service provider, facade, config stub, or publishable migrations. Laravel has no bundle concept, so none of its Extension or CompilerPass plumbing maps onto Laravel's lifecycle.
- What does mesd/settings-bundle actually do?
- It provides a database-backed configuration layer where settings are stored and read as namespaced key/value pairs, so you can change application settings at runtime without editing config files. Persistence is handled by Doctrine with a ready-made entity and schema, and lookups can optionally be cached. A small service API handles reading, writing, and checking values, and the whole thing is wired in through a Symfony bundle.
- How do I install mesd/settings-bundle in a Laravel application?
- You effectively cannot, at least not cleanly. The package's Composer constraints date from 2015 and target PHP 5.x with Symfony 2.x components and Doctrine, which will almost certainly conflict with modern illuminate/* v10 or v11 requirements on PHP 8.2+. Forcing the install with --ignore-platform-reqs gets you past Composer but leaves you with runtime code that was never designed for Laravel's container.
- Which Laravel and PHP versions does mesd/settings-bundle support?
- None officially. The last release was 2015-03-25, in the PHP 5.x and Symfony 2.x era, long before Laravel 5.5's package auto-discovery and the current service provider conventions. There is no declared support for Laravel 8, 9, 10, or 11, and no compatibility work has been done for PHP 8.2+. Assume it will not install or run against a modern Laravel stack.
- What is the best Laravel alternative for database-backed settings?
- Start with spatie/laravel-settings, which is the native, actively maintained choice for typed settings backed by the database and cached through Laravel's own cache layer. If your needs are narrow, a small Eloquent settings table with attribute casters is often enough and gives you full ownership. For plain global configuration that does not need to be editable at runtime, Laravel's native config repository already covers it.
- Can I bridge a Symfony bundle into a Laravel application?
- Technically you could build a container bridge or boot a Symfony kernel inside Laravel for this single concern, but both options are disproportionate for a settings layer. Any such bridge would be bespoke code you own and maintain forever, and it would still be running an abandoned 2015 dependency underneath. Once you have rewritten that much glue, reimplementing the logic against Eloquent is cheaper and safer.
- Does mesd/settings-bundle work with Eloquent?
- No. Its persistence layer is Doctrine ORM and DBAL, with a bundled entity and schema, and it assumes a Symfony event dispatcher and HttpKernel are present. Laravel does not ship Doctrine, so there is nothing for the bundle to bind to out of the box. Adapting it to Eloquent means replacing the storage layer entirely, at which point you are no longer really using the package.
- Is mesd/settings-bundle maintained and safe for production?
- There is no evidence of maintenance. The last release was in March 2015, the repository shows zero stars and zero dependents, and there is no CI, test coverage, or security disclosure channel. Settings sit on a sensitive seam combining database persistence, caching, and the request lifecycle, so a stale implementation tends to fail silently rather than loudly. Adopting it means forking it and owning security patching and dependency upgrades indefinitely.
- How do I migrate existing settings data out of mesd/settings-bundle?
- This is a data-migration task, not a package adoption. Export the bundle's settings tables to a neutral format such as JSON or CSV, map each namespaced key to a new Eloquent-backed settings model or a spatie/laravel-settings class, then decommission the bundle. Run the import in a one-off command and verify the values against the old application before switching traffic over. For greenfield projects there is nothing to migrate, so simply choose an alternative.
- Why not just adopt mesd/settings-bundle instead of writing settings myself?
- Because the cost of ownership outweighs the code you save. The bundle gives you namespaced key/value storage, a service API, and optional caching, all of which are a few hundred lines against Eloquent plus Laravel's cache. In exchange you inherit an unmaintained 2015 dependency with incompatible Doctrine and Symfony requirements and no support path. Scope the requirement first, decide whether it is global config, per-tenant, or admin-editable, then pick the native option and record the decision in an ADR so the evaluation is not repeated.