Config Bundle Laravel Package

Technical Evaluation

Architecture fit: modera/config-bundle is a Symfony 2/3-era bundle that models configuration as persisted, typed properties resolved at runtime, with per-property handlers owning defaults, validation, and form metadata. For a Laravel shop, the fit is conceptual, not structural: Laravel's config repository, environment loading, service providers, and cache abstractions do not map onto Symfony's bundle/DI container model. The transferable asset is the design pattern — a database-backed settings store with a resolver that layers DB value → deploy-time parameter → hardcoded default — applied to the product decisions a TPM actually owns: runtime-editable settings, feature flags, per-tenant overrides, integration credentials, and limit/pricing values that ops need to change without a release.

Integration feasibility: Low as a drop-in dependency, moderate as prior art. Composer installation into a Laravel app is not advisable; the package assumes Symfony service wiring, Doctrine mapping, and bundle registration via the kernel. A viable path is a short spike to read the manager/resolver and property-handler contracts, followed by a Laravel-native reimplementation behind a ConfigRepository interface (Eloquent persistence, Laravel Cache, validation, encryption for secrets, events for invalidation). If reuse is mandated by a stakeholder, the only defensible route is fork-and-own: extract the non-Symfony logic, wrap it in a Laravel service provider, and accept full maintenance liability.

Technical risk: High. One star, zero dependents, last release 2016-07-21, and an explicit [READ-ONLY] subtree-split marker together mean no maintainer, no security response, no modern PHP/Symfony compatibility, and no community to absorb bugs. Functionally, the pattern also carries real risk surfaces that the package does not solve for us: secrets stored in plaintext, cache invalidation correctness, multi-tenant isolation, schema/version migration of config keys, and silent breakage when a malformed or unvalidated value reaches a service at runtime.

Key questions:

• Is the capability on our roadmap at all — do we need operator-editable config, or is versioned deploy-time config sufficient for the next two quarters?
• Which values genuinely need runtime editability (flags, limits, credentials, copy) versus which must stay in versioned config for auditability and rollback?
• Who is authorised to change what, what gets logged, and what is the rollback story when a change breaks production?
• Does the package's storage shape support typed values, validation, encryption, audit history, and per-tenant scoping — or do all four need building anyway?
• What is the true build cost of a Laravel-native layer (typically 1–3 days for a thin version, more with audit and multi-tenant scoping)?
• Is there any sponsor requiring Symfony interoperability, or is that assumption dead?

Integration Approach

Stack fit: Poor as a direct dependency; strong as a reference. The correct Laravel-native shape is a settings table (or typed columns/validated JSON schema), a cached resolver with an explicit fallback chain, a service-provider-bound Settings facade with typed getters, validation on write, Laravel encryption for sensitive values, and event-driven cache invalidation. Every application service should depend on our Settings abstraction, never on vendor classes — that keeps the replace-or-replace-in-place decision a one-file change later.

Migration path: Run a one-to-two-day discovery spike: read Manager/ConfigManager.php, the Doctrine mapping, and the property-handler directory to extract the resolver and defaulting semantics, then discard the code. Define a ConfigRepository contract, implement persistence and caching, add an admin/API surface with change logging, and write migration tooling only if we are importing existing config data. Do not attempt to boot Symfony bundles inside Laravel or to adapt Symfony service definitions; that path consumes more effort than the rewrite and leaves permanent coupling.

Compatibility: Assume none out of the box. The 2016 release predates modern PHP, Symfony, and Laravel majors, has no Flex recipe, and will not resolve cleanly against current dependency constraints. Any evaluation build must pin a tag and document the exact PHP version it was tested against; a compatibility matrix and automated test suite against our target PHP/Laravel versions are prerequisites even for a spike.

Sequencing:

1. Confirm scope with stakeholders: tenancy, secret handling, auditability, read/write volume, and which config tiers we are separating (deploy-time vs runtime-editable vs per-tenant).
2. Spike the bundle for reusable logic vs Symfony coupling; timebox to two days and produce a written go/no-go.
3. Define the ConfigRepository contract, data model, and fallback resolution order.
4. Implement persistence, caching, validation, encryption, invalidation, and audit logging.
5. Build admin/API workflows with role-based permissions and change history.
6. Load-test read paths, exercise cache-failure and DB-outage behaviour, then canary the rollout behind a feature flag.

Operational Impact

Maintenance: High if adopted directly, near-zero if used only as a reference. Adopting the bundle means owning PHP compatibility, security patching, dependency drift, and bug fixes in perpetuity, with no upstream to lean on. A Laravel-native implementation of the same pattern is small, well within a team's normal maintenance envelope, and — critically — understandable by whoever is on call. The TPM-level framing is that the bundle converts a small build cost into an unbounded ownership cost.

Support: No vendor or community support exists. Internal ownership must therefore be explicit and named: one accountable engineer or team for the settings schema, resolver semantics, cache behaviour, admin tooling, and the documented rule for what belongs in versioned config versus runtime-editable config. Without that rule, the settings table becomes an untyped junk drawer within two quarters, and the fallback chain degrades into tribal knowledge.

Scaling: The pattern scales well when backed by a proper database plus a cache layer with indexed scoping keys. Reads should be cached locally or in Redis, writes should be low-volume, permissioned, and audited. Multi-tenant deployments need scoped, indexed keys and hard safeguards against cross-tenant leakage — that is a data-model decision made on day one, not a later hardening task, and it is the single largest scaling risk in this capability.

Failure modes: Stale configuration after a failed cache invalidation; cache stampedes at expiry; database outage blocking config reads and thereby the whole app; malformed or unvalidated values breaking runtime behaviour; secrets stored or surfaced in plaintext; inconsistent config across nodes; and, specific to this package, upgrade breakage from an abandoned dependency. Mitigations are validation on write, encryption for sensitive keys, versioned config with audit history, a read-through cache with a safe fallback to last-known-good, and canary rollout of config changes.

Ramp-up: Moderate for a Laravel team evaluating the concept, high for anyone asked to operate the actual bundle. Symfony bundle conventions, 2016-era PHP idioms, absent documentation, and a read-only upstream raise onboarding cost and create bus-factor risk. Budget a short spike and a small cross-functional trio — backend, DevOps, security — to land the in-house version, and set the explicit expectation with stakeholders that the recommendation is to reference this package, not depend on it.