- Is jbtronics/settings-bundle a Laravel package?
- No. jbtronics/settings-bundle is a Symfony bundle for typed application settings, built around Symfony bundle registration, DI configuration trees, compiler passes, Doctrine ORM entities, Symfony Forms, and Twig. Laravel has no bundle system or equivalent container compilation phase, so there is no supported boot path for this package in a Laravel application. Laravel teams should use spatie/laravel-settings instead.
- Can I install jbtronics/settings-bundle in Laravel with Composer?
- Composer may resolve the dependency, but the bundle will never register its services, routes, or Doctrine entities under Laravel's container. It relies on Symfony kernel-level bundle registration and a DI extension exposing a Configuration tree, neither of which Laravel provides. Installing it directly adds dead weight plus a large transitive dependency surface.
- What is the Laravel alternative to jbtronics/settings-bundle?
- spatie/laravel-settings is the near 1:1 Laravel analog: typed settings classes, per-group migrations, encrypted casts, and a cached repository. If your settings are really feature flags, use laravel/pennant instead. Both are designed for Laravel's container and persistence layers rather than Symfony's.
- Does jbtronics/settings-bundle support Laravel 10 or Laravel 11?
- No. The package targets Symfony, and version 5.0.0 requires PHP 8.2+ and Symfony 7.4+, dropping Symfony 6.x and all earlier 7.x lines. There is no Laravel version support and no framework-agnostic integration path. Laravel compatibility is not a goal of this package.
- What are the requirements for jbtronics/settings-bundle v5?
- Version 5.0.0 requires PHP 8.2 or newer and Symfony 7.4 or newer. It depends on Doctrine ORM for persistence, Symfony Forms and Twig for admin editing, Symfony Validator for constraints, and now symfony/type-info for metadata. The hard minimum-platform jump forces an upgrade if you are on older Symfony lines.
- How do I install and configure jbtronics/settings-bundle?
- In a Symfony app, you install it with Composer, register the bundle in config/bundles.php, configure its DI extension, and define settings as typed PHP classes persisted through Doctrine. Values are edited with auto-generated Symfony forms or CLI commands. None of these setup steps apply to Laravel, which lacks the bundle and DI configuration layers.
- Why does jbtronics/settings-bundle need Doctrine ORM?
- The bundle persists editable runtime settings through Doctrine ORM entities. There is no framework-agnostic core extraction and no PSR-only integration path that decouples persistence from Doctrine. Laravel does not ship a Doctrine entity manager by default, so this dependency alone blocks direct Laravel use.
- Is jbtronics/settings-bundle production-ready and well maintained?
- The package has around 95 stars and zero dependents, with a single maintainer, so there is little production evidence at scale. Version 5.0.0 introduces a hard BC break in ParameterMetadata::getPHPType(), which now returns symfony/type-info Type objects instead of strings. Combined with the Symfony 7.4 floor, this suggests you will absorb breaks on the maintainer's schedule rather than your own.
- Can I run jbtronics/settings-bundle in a Symfony service and read settings from Laravel?
- A polyglot setup is technically viable: a dedicated Symfony 7.4 service owns the bundle and its tables, and Laravel reads values via an API or shared database. This is now more expensive because the Symfony 7.4 floor forces the satellite service onto a current, faster-moving Symfony major. The type-info change also affects any settings-metadata introspection you expose.
- What changed in jbtronics/settings-bundle 5.0.0?
- Version 5.0.0 raises the minimum platform to PHP 8.2+ and Symfony 7.4+, dropping Symfony 6.x and all earlier 7.x lines entirely. It also makes a breaking API change: ParameterMetadata::getPHPType() returns symfony/type-info Type objects rather than strings. There are no new features relevant to Laravel, no framework-agnostic core extraction, and no decoupling of persistence from Doctrine. It is effectively a platform bump plus an internal type migration.