Weave Code
Settings Bundle Laravel Package
symkit/settings-bundle
symkit/settings-bundle offers a simple, structured way to manage application settings in PHP. Store, retrieve, and organize configuration values through a clean API, with support for defaults and scoped settings for flexible project-wide configuration.
A Symfony bundle for managing application-wide settings with a sectioned UI, automatic cache invalidation, and WebManifest generation.
Frequently asked questions about Settings Bundle
- Is symkit/settings-bundle a Laravel package or a Symfony bundle?
- It is a Symfony bundle, not a Laravel package, so it is installed and registered through Symfony's bundle system rather than Laravel service providers. Laravel developers evaluating it should treat it as a Symfony component and compare it with Laravel-native settings packages instead. The concepts, such as defaults and scoped values, are similar, but the integration code is Symfony-specific.
- How do I install symkit/settings-bundle with Composer?
- Install it with Composer using composer require symkit/settings-bundle. Symfony Flex can register the bundle automatically when a recipe is available; otherwise you add it to config/bundles.php manually. After installation, check the package README for any required configuration or migration steps.
- Which Symfony and PHP versions does symkit/settings-bundle support?
- The supported Symfony and PHP versions are declared in the package's composer.json constraints, so check that file before adding it to an existing project. Because Symfony's release cycle moves quickly, confirm the bundle has a release compatible with your current Symfony minor version. Running composer why-not symkit/settings-bundle is a quick way to spot version conflicts.
- How do I register and configure the bundle in a Symfony application?
- Register the bundle in config/bundles.php, or let Symfony Flex do it if a recipe exists. Bundle-level configuration typically goes in a file under config/packages, where options such as cache behavior are set. Read the README for the exact configuration keys, since the package overview does not list them.
- How does automatic cache invalidation work in this settings bundle?
- When settings are created, updated, or deleted through the bundle's API or sectioned UI, the bundle invalidates the relevant cached values so later reads return fresh data. That avoids the common trap of editing a setting and still seeing the old value until a manual cache clear. The exact cache pool and key strategy depend on your configuration, so review the README before deploying behind a shared cache backend.
- Can I define default values for settings that have not been configured yet?
- Yes, the bundle supports defaults, so code can read a setting and receive a sensible fallback when no value has been stored yet. This keeps new installations and fresh environments working before an administrator visits the sectioned settings UI. Defaults belong in code as the baseline, with stored values overriding them at runtime.
- What are scoped settings and when should I use them?
- Scoped settings let you store different values for the same setting key under different scopes, such as a tenant, environment, or feature context. Use them when a single global value is too coarse but you do not want to invent duplicate configuration keys. For straightforward application-wide values, unscoped settings with defaults are usually easier to reason about.
- How does the WebManifest generation feature work?
- The bundle can generate a WebManifest from your stored settings, letting you manage PWA metadata such as the application name and icon references through the settings UI instead of hand-editing a manifest file. Because values come from the settings store, changes are reflected without a code deploy. Check the README for the route or command that exposes the generated manifest.
- How should I test application code that reads settings from this bundle?
- In Symfony functional tests, boot the kernel with a test configuration and write settings through the bundle's API before asserting behavior. If caching is enabled in the test environment, clear or disable it so each test sees the values it wrote. For unit tests, wrap settings access behind your own service and mock that interface rather than the bundle internals.
- Is symkit/settings-bundle production-ready and how does it compare to Laravel settings packages?
- Assess it like any smaller package: check recent releases, open issues, test coverage, and whether the maintainer responds to bug reports. The feature set is focused, covering a sectioned UI, cache invalidation, defaults, scopes, and WebManifest generation, so compare it against what your project actually needs rather than a long feature list. Laravel teams should weigh the integration cost, since this is a Symfony bundle and not a drop-in Laravel package.
Weaver
How can I help you explore Laravel packages today?