Config Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for runtime settings. This package solves a recurring, well-understood problem: letting non-engineers change application behaviour (feature flags, thresholds, copy, credentials-adjacent values) without a deploy. It reframes the decision from "do we adopt this bundle" to "do we own ~2–4 engineer-days of a settings table, cached accessor, and warmup command" — which is the honest comparison for a Laravel team.
• Roadmap sequencing for admin configurability. The typed model (bool/string/text/int, plus float and password types visible in release notes) and group/label addressing map directly to a self-serve admin surface. This helps decide whether "customer-admin-editable settings" belongs in the next quarter or the one after, and whether it ships with RBAC and audit or as a bare CRUD.
• Tooling standardisation for the Symfony estate. If any part of the portfolio is Symfony + Doctrine + Twig, this is a low-effort decision: VCS repo entry, a Config entity using ConfigTrait, a repository extending AbstractConfigRepository, and a warmup command in the deploy pipeline. Roughly one engineer-day, not a procurement cycle.
• Reuse of the pattern across products. The pattern — DB-backed settings row, cached read path, typed accessors, a warmup/seed command that initialises defaults without overwriting operator changes — is portable and worth formalising as an internal convention regardless of which implementation wins.
• Use cases to evaluate against: per-environment feature toggles, business-rule thresholds (fees, limits, SLAs), editable email templates and copy, integration endpoints and non-secret keys, per-tenant/establishment overrides (as the README's Establishment example implies).
• What it does not support, and should not be sold as: audit trails, change history, versioning, RBAC, or encryption of the password type. None of these appear in the source material. Any decision premised on those capabilities is building on sand.

When to Consider This Package

Consider adopting it when all of the following hold:

• The target application is Symfony (Doctrine ORM, Symfony routing, Twig) — not Laravel. This is a hard gate. The bundle registers into the Symfony kernel via resolve_target_entities and config/routes.yaml; there is no equivalent in a Laravel application without pulling in Symfony DI and Doctrine, an architectural commitment far larger than the problem.
• The team is already using, or planning to use, CruditBundle. The bundle is explicitly designed as its companion and the admin-editing value is largely contingent on that pairing.
• The scope is single-tenant, low-sensitivity settings. No multi-tenancy, no secrets, no compliance-driven change history.
• You can vendor it deliberately: 1 star, 0 dependents, not on Packagist, org name (2lenet) and PHP namespace (Lle) disagree, and the metadata contains a future-dated release (2026-08-03). Treat this as an internal fork candidate, not a maintained dependency — budget for owning the code.
• The settings surface is small and stable enough that a full configuration-management product is overkill.

Look elsewhere (or build) when:

• The stack is Laravel. Port the pattern. A settings table keyed on group/label/nullable tenant_id, a SettingsService reading through Cache::rememberForever with tag invalidation on write, an artisan settings:warmup command in the deploy pipeline, and a Blade helper mirroring get_config_value reproduces every stated benefit in roughly 2–4 engineer-days.
• Multi-tenancy is in scope and unverified. If CacheManager keys on group/label only, tenant A's configuration can be served to tenant B. This is the highest-severity unknown in the package and must be resolved before any adoption decision.
• You need audit trails, approval workflows, secret encryption, or RBAC. Escalate to a purpose-built feature-flag/config platform (LaunchDarkly, Unleash, Flagsmith) or an internal service with those properties designed in.
• You need a supported dependency with a vendor SLA. There is one maintainer team, no external contributors, and no Packagist presence. Do not put this on a critical path without a fork-and-own plan.
• Documentation accuracy matters to your onboarding cost. The README documents four get* methods while releases add float, password, and translatable labels; the documented getInt(...): int signature is type-inconsistent; the composer repositories stanza is malformed. Assume the docs lag the code.

How to Pitch It (Stakeholders)

To executives — one paragraph. This is a small, unmaintained Symfony component that stores application settings in a database table so business users can change behaviour without engineering involvement. It is not a Laravel package and cannot be dropped into our Laravel services. The strategic value is the pattern, not the code: we can reproduce it internally in under a week with our own caching, access control, and audit trail — capabilities this package does not provide. Recommendation: do not adopt the dependency; adopt the pattern. This avoids a single-maintainer, non-Packagist risk on a critical configuration path while delivering the same user-facing outcome on our own terms.

To engineering — the short version. Symfony-only bundle (Lle\ConfigBundle) from 2lenet; 1 star, 0 dependents, not on Packagist, installed via manual VCS repo entry. It is a Doctrine-entity settings table with typed accessors, a CacheManager, a lle:config:warmup command, and a Twig helper, designed to pair with CruditBundle. For a Symfony/Crudit shop it is roughly a one-day integration. For us it is a 2–4 day reimplementation: settings table (group, label, type, value, nullable tenant_id, unique index on group+label+tenant_id), SettingsService over Cache::rememberForever with invalidation on write, artisan settings:warmup in the deploy pipeline, Blade helper.

Three questions to answer before anyone writes code:

1. Is the target Symfony or Laravel? This alone decides one-day adoption versus rewrite.
2. Is multi-tenancy in scope, and does the cache key include the tenant? If not, we have a cross-tenant data-leak class of bug.
3. Do we need audit trail, RBAC, or encrypted secrets? If yes to any, this package does not clear the bar and we should scope an internal build or a commercial platform.