Persistence Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, and there is a category mismatch to resolve first. Despite being submitted for a Laravel evaluation, funddy/persistence-bundle is a Symfony bundle, not a Laravel package. Its entire reason for existing is Symfony's DI machinery: a Bundle class, a DependencyInjection extension, service definitions and likely compiler passes to register repositories/units of work. Laravel's container and package-discovery model is a different contract; nothing in this repo maps onto a ServiceProvider without us writing that adapter ourselves.

Worse, the bundle is only glue. It contains no persistence implementation — the actual component lives in the sibling funddy/persistence package, which is a second dependency with its own maintenance status to audit. Adopting this means adopting two unmaintained artifacts, one of which we would have to re-target.

Integration feasibility — low. A Laravel integration would mean re-implementing the bundle's service wiring from scratch against Illuminate's container. At that point we are not "using the package," we are reading it as a reference design. In a Symfony context it is installable but almost certainly pinned to an older PHP/Symfony generation.

Technical risk — high. Three stars, zero dependents, score 0.015: this is effectively a personal repository, not a component with a user base. Expected risk profile:

• Composer constraints frozen at a PHP 7.x / Symfony 2–3 era; PHP 8.2+ will likely fail to resolve or fatal at runtime.
• Unpatched transitive dependencies (security surface we inherit silently).
• No CI signal, no release cadence, no issue triage.
• Zero public documentation beyond a README, so behaviour must be reverse-engineered from source.

Key questions before any further work:

1. What is our actual requirement — repository/unit-of-work abstraction, event-sourced persistence, or just data access? Eloquent or Doctrine likely already satisfies it.
2. Is funddy/persistence itself maintained, and does it have any consumers?
3. Are we a Symfony shop or a Laravel shop? The answer changes this from "fork it" to "discard it."
4. What is the licence, and are we permitted to fork and vendor?
5. Who internally would own a fork, and for how long?

Integration Approach

Stack fit. On Laravel: not viable as a dependency. On Symfony: viable only as a vendored fork. Either way the honest read is that the bundle contributes ~a few hundred lines of container wiring, and its value is mostly as a design reference.

Migration path. Three ordered options, in preference order:

1. Do not adopt. Use the framework-native persistence layer (Eloquent / Doctrine DBAL) or a maintained CQRS/event-sourcing library if that is the real need. This closes the question at near-zero cost.
2. Adopt the underlying component only. If funddy/persistence offers a specific abstraction we want, depend on it directly and write our own thin wiring — ~100 lines of ServiceProvider or Symfony config — rather than inheriting the bundle.
3. Fork the bundle. Only justified if we are already a Symfony shop with a concrete need and accept ownership. Fork, modernise constraints, add CI, publish internally.

Compatibility. Assume breakage. Before committing, run composer why-not against our PHP version, execute the existing test suite (if any) on PHP 8.2/8.3, and run static analysis across the transitive tree. Budget for constraint patching and at least one round of deprecation fixes.

Sequencing.

1. Requirement clarification — confirm the abstraction is genuinely needed and not already covered.
2. Timeboxed spike (≤2 days) in a throwaway branch: install, boot, prove one repository round-trip.
3. Go/no-go on fork based on spike output and dependency audit.
4. If go: fork → modernise → CI → wrap behind our own interfaces so the dependency is swappable.
5. Document the exit path in the ADR before merging.

The non-negotiable design constraint in every branch is that our domain code depends on our interfaces, never on funddy\* types directly.

Operational Impact

Maintenance. Upstream maintenance is effectively zero; on adoption we inherit 100% of it. Mitigating factor: the bundle's surface is small and mostly declarative, so fork upkeep is modest — but the underlying component is the larger and less visible liability.

Support. No community, no docs, no StackOverflow footprint, no vendor. Any engineer encountering this in six months will have no path to answers except reading source. That is a real onboarding tax on every future hire who touches the persistence layer.

Scaling. The bundle itself is not a scaling bottleneck — it is wiring. Throughput, connection pooling and transaction semantics are determined entirely by the underlying implementation, which we would need to benchmark independently. We should not assume the bundle's presence tells us anything about production behaviour.

Failure modes to plan for:

• Composer resolution failures after a routine PHP upgrade — breaks CI for the whole repo, not just this feature.
• Silent behavioural change when we upgrade Symfony/Laravel and the fork's compiler passes or bindings drift.
• Inherited CVEs in abandoned transitive dependencies with no upstream patch path.
• Bus factor of one (the fork owner), with no second reviewer able to validate changes.
• Divergence drift: our fork slowly becomes a private, undocumented persistence layer that new engineers misread as a third-party dependency.

Ramp-up. High relative to delivered value. The learning curve is steep and the payoff is a bespoke abstraction with three stars of documentation.

Recommendation. Do not adopt. The package fails the basic threshold questions — wrong framework, unmaintained, no dependents, no documentation — and its functional contribution is small enough to reproduce deliberately if the need is ever confirmed. Recommend closing with a documented "rejected, rationale: abandoned Symfony-only bundle, no Laravel fit" note so this does not get re-proposed.