Preferences Bundle Laravel Package

Product Decisions This Supports

• Confirms a real capability gap on the roadmap: runtime, user-managed configuration. The package exists because some settings genuinely cannot live in env vars or container parameters — they change per user, per tenant, or per request without a deploy. If your backlog keeps producing "let users/admins change X themselves," treat that as evidence of a structural need, not a series of one-offs. This package is a data point for putting a settings/preferences capability on the roadmap.

• Forces a taxonomy decision that prevents long-term debt. Teams routinely merge four different things into one "settings" table: deploy-time config (env/container), global administrator settings, user preferences (this package's scope), feature flags, and secrets. Making that distinction explicit is a genuine product decision — it determines your admin UX, your permissions model, your caching strategy, and your security posture. Borrowing this package's framing (scoped key/value with a resolution order: user → tenant → global default) lets you draw those lines deliberately.

• Informs concrete feature scoping and sequencing. Directly applicable to notification/channel preferences, dashboard layout and saved views, per-tenant defaults, locale and timezone overrides, and operator-tunable thresholds that today require a config change and a redeploy. Each of these becomes a small, independently shippable increment once a shared preference store exists.

• Supports a build-vs-buy-vs-borrow call, and here the answer is "borrow." This should not be adopted as a dependency. It is a Symfony bundle being evaluated against a Laravel codebase — a platform mismatch that alone disqualifies it as an install candidate. What it is useful for is pressure-testing your own data model and surfacing the acceptance criteria your real implementation will need.

• Surfaces a platform and licensing trap before it costs a sprint. Flagging "this is Symfony, not Laravel" and "this is GPL-2.0" early prevents an engineer from burning a spike week on an integration that cannot ship. That is a cheap, high-value PM intervention.

When to Consider This Package

Consider it only as a design reference, and only when all of the following hold:

• You are designing a settings capability from scratch and want prior art. Read the source for the data model — scope hierarchy, typed values, default resolution — not for the code you'll ship.
• You are on Symfony, not Laravel, and on a compatible PHP/Symfony version (verify against your LTS line before assuming).
• Legal has cleared GPL-2.0 against your actual deployment model. This is copyleft. It's usually tolerable for internal tools and hosted SaaS where you never distribute binaries, but it is a real risk for on-prem, embedded, or redistributed products — and a fork you hand to other business units can itself count as distribution. Do not skip this gate, and do not run it in parallel with engineering.
• You accept that you are the maintainer from day one. One star and zero dependents means there is no community to absorb a fork and no upstream to consume patches from.

Look elsewhere — or build — when any of these apply:

• You are on Laravel. This will not slot in. Evaluate spatie/laravel-settings (mature, MIT, Laravel-native, actively maintained) or build a small settings table with a cached repository behind an interface. If the actual need is toggling behavior rather than storing preferences, evaluate Laravel Pennant instead.
• Adoption signals matter to you. One star, zero dependents, single-agency provenance: bus factor of roughly one, no security advisory channel, no observable supported-version matrix. The high "opportunity" score reflects the problem, not the artifact.
• You need production-grade requirements. Multi-tenant resolution, an audit trail of who changed what and when, encryption at rest for sensitive values, authorization on writes, cache invalidation semantics, and bulk import/export are all things a minimal preferences bundle typically does not cover — and retrofitting them costs more than building fresh against Eloquent and Laravel's cache contracts.
• The values are secrets. Preferences are user-editable by definition. Secrets belong in a secrets manager, full stop.
• The values are read on every request at scale. Confirm the read path and caching behavior before assuming it's free.

How to Pitch It (Stakeholders)

To executives (one paragraph): We've identified a recurring product need — letting users and administrators change certain settings themselves without an engineering deploy. That need is real, and it belongs on the roadmap. The specific open-source package we evaluated is not a dependency we recommend: it's a Symfony component in a Laravel-oriented evaluation, it carries a GPL-2.0 copyleft license requiring legal review, and it shows essentially no adoption or maintenance signal (one star, zero dependents). Recommendation: treat it as reference design, and fund either a small internal build (roughly one to two sprints) or a maintained MIT-licensed alternative. That de-risks the license exposure and the bus factor while still capturing the capability.

To engineering: It's a Symfony bundle from Makina Corpus under GPL-2.0, effectively unmaintained — assume we own it on day one, so plan to reimplement rather than integrate. What is worth taking is the model: typed key/value settings with a scope hierarchy and a defined resolution order (user → tenant → global), kept cleanly separate from env-based config. What it likely will not give us — and what we should write down as explicit acceptance criteria — is authorization on writes, an audit log, encryption for sensitive values, a cache layer with sane invalidation on the read path, and multi-tenant isolation. Build behind a single internal PreferenceStore interface so the implementation is swappable; that interface is the deliverable that caps the downside of this bet at one adapter swap.

The decision in one line: Adopt the pattern, not the package. The capability goes on the roadmap; this repository goes in the "prior art" column. And the first two questions for any future candidate in this space are "Laravel or Symfony?" and "what's the license?"