Weave Code
Preferences Bundle Laravel Package
makinacorpus/preferences-bundle
Symfony bundle for managing user preferences: define configurable preference keys, persist per-user values, and read or write settings through a simple API. Integrates with Symfony apps to centralize user-specific configuration.
Preferences are configuration variables that are user-managed for which we cannot rely upon container parameters or environment variables.
Frequently asked questions about Preferences Bundle
- Is makinacorpus/preferences-bundle a Laravel package?
- No. It is a Symfony bundle: it ships a Bundle subclass, a dependency-injection extension, and Doctrine ORM mappings, so it hooks into Symfony's compiled container and bundle lifecycle rather than Laravel's service providers. Laravel has no equivalent bundle or compiler-pass system to register it against. Treat it as a reference design for user-editable runtime settings, not a drop-in Composer dependency for a Laravel app.
- Can I install this Symfony bundle in a Laravel application?
- Only through a fragile shim that boots a parallel Symfony container inside Laravel, which is typically weeks of work and permanent operational debt. Its Composer constraints likely pin symfony/framework-bundle to older major versions and doctrine/orm to v2, which can conflict with the Symfony components Laravel already ships and force risky downgrades. For a preference store, that trade-off is not worth approving. Forking the domain logic into a Laravel service provider is the only realistic integration path.
- What is the best Laravel alternative for storing user-editable settings?
- spatie/laravel-settings is the closest match: MIT licensed, actively maintained, with typed settings classes, migrations, and per-model scoping. For simpler needs, a small custom settings table behind a cached repository interface covers most cases in a few days of work. Both avoid the GPL-2.0 licensing and Symfony container coupling issues of this bundle.
- What does PreferencesBundle actually do?
- It lets you define typed preference keys, persist their values via Doctrine ORM, and resolve them at runtime with defaults and fallbacks. It supports global and per-user scopes so applications can offer configurable settings without writing bespoke storage code. The core idea is sound; the implementation is tied to Symfony's service and configuration model.
- What license does preferences-bundle use, and does it matter for Laravel projects?
- It is GPL-2.0, a copyleft license. Internal SaaS use is usually survivable where no binaries are distributed, but sharing a fork between business units can count as distribution and is incompatible with shipping a proprietary Laravel product. Legal sign-off must be a hard gate before any code is written, not a parallel task.
- Is the package actively maintained?
- It has roughly one star, no dependents, single-agency provenance, and no visible community. There is no security advisory feed to subscribe to and no supported-version matrix, so you should assume you own any fork from day one. Check upstream commit cadence over the last 24 months before relying on it at all.
- How are preference values typed and serialized?
- The description promises configurable preference definitions and value types, but the storage contract is undocumented. Typing and serialization behavior, plus what happens when a preference definition changes and needs schema versioning, are exactly the parts that cause production incidents. Read the Doctrine mappings and any serializer code before assuming type safety.
- Does it support per-user or multi-tenant scoping?
- It advertises scoped preferences for global and per-user settings, but it is unclear whether scoping extends to tenants or arbitrary entities. The resolution order between scopes and defaults is also undocumented. Confirm both before designing a multi-tenant feature on top of it.
- How does caching and invalidation work for resolved preferences?
- Runtime resolution with defaults suggests some form of read cache, but the package does not document whether it is request-scoped or persistent, or how writes invalidate it. In a Laravel port you would almost certainly replace this layer with the framework cache and explicit invalidation on save. Plan for that work in any estimate.
- What Laravel and PHP versions could run a ported version of this?
- A native rebuild using an Eloquent model, typed casts, and the cache facade would run on any currently supported Laravel and PHP version without constraint conflicts. The upstream bundle, by contrast, targets older Symfony and Doctrine majors and will not resolve cleanly against Laravel 10, 11, or 12. Scope any evaluation as a pattern reference rather than a dependency.
Weaver
How can I help you explore Laravel packages today?