- Can I use hexanet/settings-bundle in a Laravel application?
- No. hexanet/settings-bundle is a Symfony bundle by design, built around a bundle class, a DI extension, and Symfony service configuration. Its v2.0.0 changelog explicitly states it only supports Symfony >= 3.4, and there is no Laravel service provider, facade, or config integration. Using it in Laravel would require standing up Symfony kernel components or hand-porting the internal logic, at which point you are no longer adopting the package.
- Is hexanet/settings-bundle still maintained and safe to depend on?
- The repository is archived, so there are no security patches, compatibility updates, or issue triage. It has 0 stars and 0 dependents, meaning no production signal and no downstream projects surfacing edge cases. A v2.0.0 tag exists, but it is a one-off modernization rather than evidence of a maintenance cadence. Treat it as unmaintained code.
- What Symfony version does hexanet/settings-bundle support?
- v2.0.0 states 'Only support Symfony >= 3.4,' which raises the floor to a Symfony line that reached end-of-life in November 2019. The release does not declare support for Symfony 5, 6, or 7, so modern Symfony runtimes are not covered. If you are on a current Symfony version, this constraint is far behind your runtime.
- What types of settings can I store with hexanet/settings-bundle?
- It supports string, integer, boolean, and array settings with automatic casting and validation so stored values stay consistent. Values are persisted through Doctrine, which keeps them editable at runtime rather than hard-coded in configuration. Settings are read through a dedicated manager service you can inject wherever needed.
- How do I install and configure hexanet/settings-bundle?
- Installation is via Composer, then you register the bundle in your Symfony kernel, configure Doctrine entity mapping, and update your database schema. You then inject the settings manager service where you need to read or write values. Note that these are Symfony steps; there is no Laravel installation path, and the package repository is archived.
- Does hexanet/settings-bundle support caching and cache invalidation?
- Yes, the bundle advertises caching support to avoid repeated database queries for frequently used values. However, the documentation does not describe how cache invalidation works across processes or web workers. Cache coherence in a settings layer is a real correctness risk, so probe this before relying on it.
- What changed in hexanet/settings-bundle v2.0.0?
- v2.0.0 is a breaking major release whose changelog says 'Only support Symfony >= 3.4' and moves service definitions to autowiring. That rewrites the bundle's DI setup, so services that were explicitly defined and overridable may now be autowired, renamed, private, or aliased. It contains no documented functional fixes to persistence, typing, caching, serialization, or transactions. If you decorated or referenced service IDs, this release likely breaks you.
- How do I test settings managed by hexanet/settings-bundle?
- There are no documented test helpers or fixtures, and because the repository is archived there is no support channel for testing questions. In practice you would mock or stub the settings manager service in unit tests and use a real Doctrine-backed instance in integration tests. Verify cache invalidation and write behavior explicitly, since those areas are undocumented.
- What are the best Laravel alternatives to hexanet/settings-bundle?
- For Laravel, look at spatie/laravel-settings, akaunting/laravel-setting, or a small custom settings table backed by a cached config repository. These follow Laravel service provider and config idioms instead of Symfony bundle wiring. For Symfony, prefer a maintained bundle or Symfony's own configuration plus a database-backed override layer.
- Does hexanet/settings-bundle support multi-tenant or scoped settings?
- Scoping and multi-tenancy are not documented, and no per-tenant or per-scope API is described in the overview. If you need tenant-specific settings, you would have to verify how the Doctrine entity is keyed and whether queries can be constrained by tenant. Treat undocumented behavior here as a silent-corruption risk and test it before adopting.