Weave Code
Persistence Bundle Laravel Package
funddy/persistence-bundle
Funddy Persistence Bundle is a Symfony bundle for wiring persistence infrastructure into PHP apps, helping organize repositories, storage services, and transactional data access while keeping domain persistence concerns out of application code.
PersistenceBundle for Symfony2
Frequently asked questions about Persistence Bundle
- Is funddy/persistence-bundle a Laravel package?
- No. Despite being submitted for a Laravel evaluation, funddy/persistence-bundle is a Symfony bundle whose entire reason for existing is Symfony's dependency injection machinery: a Bundle class, a DependencyInjection extension, service definitions and compiler passes. Laravel's container and package-discovery model is a different contract, and nothing in the repository maps onto a ServiceProvider without writing that adapter yourself. Treat it as a Symfony artifact, not a Laravel dependency.
- Can I use funddy/persistence-bundle in a Laravel application?
- Not viably as a dependency. Composer may resolve the code, but the package ships no Laravel service provider, no package-discovery entry and no Illuminate bindings, so a Laravel integration would mean re-implementing the bundle's service wiring from scratch against Illuminate's container. At that point you are reading the package as a reference design rather than using it, and the honest conclusion is to skip it.
- What does funddy/persistence-bundle actually do?
- It is glue. The bundle wires persistence infrastructure into a Symfony application, registering repositories, storage services and transactional data access through the container while keeping domain persistence concerns out of application code. It contributes roughly a few hundred lines of container wiring and no persistence implementation of its own. Its value is mostly as a design reference for repository and unit-of-work wiring.
- Does funddy/persistence-bundle include the persistence implementation?
- No. The actual component lives in the sibling package funddy/persistence, which the bundle depends on, so adopting this means adopting two artifacts. Each has its own maintenance status to audit, and the underlying component has its own consumer base and constraints to check. If funddy/persistence offers a specific abstraction you want, depend on it directly and write your own thin wiring instead of inheriting the bundle.
- Does funddy/persistence-bundle support PHP 8.2 or PHP 8.3?
- Almost certainly not. Composer constraints appear frozen at a PHP 7.x and Symfony 2 to 3 era, so PHP 8.2 and 8.3 will likely fail to resolve or fatal at runtime. Before committing, run composer why-not against your PHP version, execute any existing test suite on PHP 8.2 and 8.3, and run static analysis across the transitive tree. Budget for constraint patching and at least one round of deprecation fixes.
- Is funddy/persistence-bundle still maintained?
- There is no meaningful maintenance signal. It has three stars, zero dependents and a popularity score of 0.015, which makes it effectively a personal repository rather than a component with a user base. There is no CI signal, no release cadence, no issue triage and no documentation beyond a README, so behaviour has to be reverse-engineered from source. Plan on owning it entirely if you adopt it.
- How do I install and configure funddy/persistence-bundle?
- In a Symfony context you would require it via Composer, enable the bundle in the kernel and configure the DependencyInjection extension. Beyond the README there is essentially no documentation, so the configuration surface must be read out of the extension and service definitions in source. If you are on Laravel, installation is a non-starter because there is no bundle kernel to register it with.
- Is funddy/persistence-bundle safe for production use?
- The technical risk is high. The dependency tree is almost certainly frozen at an older PHP and Symfony generation, so you would inherit unpatched transitive dependencies and a silent security surface with no upstream fixes arriving. There is no CI, no release process and no triage, meaning any defect you find is yours to fix. Only a vendored, modernised fork with your own CI and review would be defensible.
- What Laravel alternatives should I use instead of funddy/persistence-bundle?
- Start by clarifying the requirement: repository and unit-of-work abstraction, event-sourced persistence, or plain data access. For most teams Eloquent or Doctrine DBAL already satisfies it, and if you genuinely need CQRS or event sourcing, a maintained library in that space is a far better bet. Not adopting this package closes the question at near-zero cost and leaves you with framework-native persistence you already understand.
- Can I fork funddy/persistence-bundle and vendor it internally?
- Only if you are already a Symfony shop with a concrete need and accept full ownership. Check the licence first to confirm you are permitted to fork and vendor, then confirm who internally would own the fork and for how long. Validate with a timeboxed spike of two days or less: boot it, prove one repository round-trip, run the existing tests and static analysis on PHP 8.2 and 8.3. If you go ahead, fork, modernise constraints, add CI, wrap it behind your own interfaces so it stays swappable, and document the exit path in an ADR before merging.
Weaver
How can I help you explore Laravel packages today?