- Can I install lst/settings-bundle in Laravel, and which Laravel versions does it support?
- No, not as a working Laravel package. lst/settings-bundle is a Symfony bundle with a bundle class, DI extension, configuration tree, and Doctrine ORM mappings; it has no Laravel service provider, facade, publishable config, or Eloquent model. That means there is no Laravel 10, 11, or other Laravel version support to rely on, because the Symfony kernel is what wires it.
- What is lst/settings-bundle used for?
- It is used to persist application settings as key/value rows and read them back through a small runtime API. It keeps dynamic settings out of static config files so values can change without a redeploy, and it adds type-aware retrieval for consistent booleans, integers, arrays, and strings. Think of it as boilerplate removal for a familiar settings-table pattern, not a full settings platform.
- Does lst/settings-bundle support typed settings such as booleans and arrays?
- Yes, typed accessors are the main feature: the example API includes set and getBool, and the package stores a type with each key/value pair. That lets reads return consistent booleans, integers, arrays, or strings regardless of the storage format. Review the source for the complete accessor list and default-on-miss behavior before copying the semantics.
- How is lst/settings-bundle installed and configured?
- In Symfony, you install it with Composer, register the bundle, configure its DI extension, and provide Doctrine entity mapping plus a settings table. The package assumes Doctrine ORM and a Symfony service container, so setup is not transferable to Laravel as-is. A Laravel equivalent would need a service provider, an Eloquent model, and a migration you own.
- Does lst/settings-bundle cache settings reads?
- The available description does not mention caching, so assume get calls may hit the database until you verify the source. Settings are commonly read on nearly every request, so a production implementation needs a cache layer with invalidation on set and forget. Treat caching as your responsibility, not a guarantee from this bundle.
- Can lst/settings-bundle scope settings per tenant or per environment?
- The package is described as a flat key/value settings store with no namespacing, tenant scoping, environment scoping, or grouping. If you need per-tenant or per-environment settings, you must add scope columns and query constraints yourself. That gap is a strong argument for designing the Laravel version around your actual tenancy model.
- Does lst/settings-bundle encrypt settings at rest?
- There is no indication of encryption at rest in the package description. Do not assume it is safe for secrets, API credentials, or other sensitive settings without reviewing the source and schema. In Laravel, use encrypted casts or a dedicated secrets store for sensitive values.
- How should I test a Laravel settings manager based on this pattern?
- The Symfony bundle does not ship Laravel testing helpers, so test your Laravel-native version with your normal conventions. Use an in-memory SQLite database with RefreshDatabase, bind the settings manager in the test container, and assert typed getters, defaults on miss, and cache invalidation on set and forget. That gives you coverage the original bundle cannot provide in a Laravel app.
- Is lst/settings-bundle maintained and safe for production?
- The package has zero stars, zero dependents, and no known consumers, so there is no third-party security review, downstream bug discovery, or issue-response expectation. For a small utility that is not automatically disqualifying, but for settings that may hold feature flags or credentials it makes you the de facto maintainer. Check the last commit date, open issues, release cadence, and Doctrine ORM 2 to 3 compatibility before relying on it.
- What is the best Laravel alternative to lst/settings-bundle?
- The practical alternative is a Laravel-native settings manager: an Eloquent model for key, value, and type, a service provider binding, typed get and set methods, defaults on miss, and a cache decorator. That is about one to two days of work and inherits your migrations, queues, cache, testing conventions, and observability. Running Doctrine inside Laravel or porting the bundle is disproportionate unless you intend to publish and maintain it publicly.