Settings Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for configuration/settings management. This bundle is a candidate reference design, not a candidate dependency. If we're scoping multi-tenant or per-publication settings (editable at runtime without deploys), reading its settings model — namespacing, scoping, persistence — is a cheap way to validate our own schema before we commit to it.
• Multi-tenant configuration architecture. Superdesk Web Publisher is a multi-tenant publishing platform, so this bundle's job is almost certainly settings scoped to a tenant/organization with override behavior. That is exactly the decision we face whenever a customer asks "can each brand/edition have its own workflow, branding, or feature toggles?" — it gives us a prior art answer for hierarchical override semantics.
• Roadmap triage. This is a no as a scheduled item. Last release 2018, one star, zero dependents, and it's a [READ-ONLY] subtree split — the repo is a mirror, not a product, with no issue tracker, no support channel, and no security patch path. Nothing here belongs on a roadmap except "spend a day reading the source."
• Platform-fit gate. Our stack is Laravel/PHP; this is a Symfony bundle. There is no service provider, no Laravel config integration, and no facade — adopting it means adopting Symfony's bundle/kernel conventions and a Doctrine-era persistence layer. That alone closes most of the buy case.
• Use cases where it's genuinely relevant: runtime-editable editorial configuration, per-tenant branding and feature flags, and settings that content operators change without a release. Those are real product needs; the package is just not the vehicle.

When to Consider This Package

Consider it only if:

• You are already running or extending a Superdesk Web Publisher installation pinned to the same Symfony/PHP generation.
• You need a Doctrine-backed, tenant-scoped settings store and are prepared to vendor or fork it, owning patching and upgrades outright.
• You want a worked example of settings scoping for a multi-tenant CMS and are reading, not installing.

Look elsewhere if:

• You are on Laravel, or on Symfony 6/7 and PHP 8.x — this predates both and will not install cleanly.
• You need anything resembling active maintenance: security advisories, PHP version bumps, a changelog, a responsive maintainer.
• You need documentation, a support contract, or a community to ask questions of. One star and zero dependents means the answer rate is effectively zero.
• You want a settings/feature-flag layer with a modern ecosystem (Laravel's config plus a flags package, or a hosted flag service) — those are cheaper to adopt than a decade-old fork.

How to Pitch It (Stakeholders)

To executives: This is not a purchase and not a shortcut. It's an unmaintained 2018 component with no user base, no support, and no security patch path, and it's built for a different framework than ours. I'm not recommending adoption. The upside is limited to what we can learn from its data model in about a day of engineering time.

To engineering: Treat swp/settings-bundle as documentation, not a dependency. It's a read-only subtree split of the Superdesk Web Publisher monorepo — bugs and PRs go upstream, not here — and it hasn't shipped since June 2018. We should read its settings-scoping approach, then implement the equivalent ourselves in Laravel: a tenant-scoped key/value store with typed values and override resolution is a few hundred lines and a migration, and we own it. Adopting the bundle would cost us a fork, a compatibility port, and permanent maintenance, in exchange for code we could write in two days. Recommendation: reference, don't depend.