Customer Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the customer/account domain. This bundle provides a ready-made customer model (customer entity, address book, groups, customer provider wired into Symfony's security layer). It remains a credible reference for scoping a build: it shows the commodity surface area you would otherwise pay an engineer to design from scratch.
• Roadmap scoping for identity and profile features. Use it to sanity-check the minimum viable customer model — registration, profile editing, multiple addresses, customer groups — before committing roadmap capacity to auth, MFA, or GDPR-grade privacy tooling, none of which this bundle covers.
• Reuse decision inside a Sylius/Monofony stack. If the product already runs on Sylius or Monofony, this is effectively "in-family" code and avoids duplicating a customer bounded context that the platform already assumes exists.
• Dependency-risk and maintenance-burden assessment. With 1 star, 0 dependents, a READ-ONLY split from a monorepo, and a long gap since the prior release, this remains a data point for a standing "third-party dependency policy" decision: what bar must a package clear before it ships in production, and who owns it afterward. The v1.10.0 release adding PHP 8 support is a narrow compatibility signal, not evidence of an active security-response process.
• Fork-or-adopt decision. Because changes must flow through the upstream monorepo (or a fork), adopting this is implicitly a commitment to owning a patched fork. That is a resourcing decision, not just a technical one.

When to Consider This Package

Consider it when:

• The product is already on Sylius/Monofony and you want the customer model to match the platform's expectations rather than inventing a parallel one.
• You need a commodity customer + address-book domain and are prepared to vendor or fork the code under MIT, treating it as a starting point rather than a supported dependency.
• You are on PHP 8 and a Symfony version contemporary with the 2021 release line (Symfony 4.x/5.x era). The v1.10.0 release specifically adds PHP 8 support, but it does not by itself establish Symfony 6.x/7.x compatibility — verify with a spike before committing.
• Time-to-first-customer-record matters more than long-term upstream support — for example, a prototype, internal tool, or proof of concept that may be rewritten.

Look elsewhere when:

• You are on a modern Symfony LTS (6.x/7.x). A single PHP 8 compatibility release after a long gap is not enough to treat the package as actively maintained; compatibility work would still likely fall on you.
• Authentication is in scope. This bundle manages customer data and a customer provider; it is not a solution for password hashing policy, MFA, session hardening, or breach response.
• Privacy and compliance are in scope. GDPR export/erasure, consent tracking, and retention policy are not part of the package — budget for them separately.
• You need an API-first or headless customer service (API Platform, separate identity provider). Do not adopt a server-rendered Symfony bundle as the foundation for that.
• Procurement requires an actively maintained dependency with a security response process. A PHP 8 compatibility release improves the compatibility story slightly, but it does not supply a security process or named maintainership.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed Symfony bundle that supplies a standard customer and address-book data model. The license cost is zero, but the real cost is ownership: it has effectively no community (one star, zero dependents), and the recent v1.10.0 release is limited to adding PHP 8 support. That helps with runtime compatibility but does not meaningfully change the maintenance-risk profile. The recommendation remains to treat it as a reference implementation and code donor, not a supported dependency — use it to accelerate design and to avoid re-deriving a commodity domain, then fork it and assign clear internal ownership. Do not let it enter the production dependency list without a named maintainer and a patching commitment.

To engineering: Adopt selectively. The value is the domain shape — customer entity, addresses, groups, and a customer provider for Symfony security — plus consistency with Sylius/Monofony conventions. The v1.10.0 release adds PHP 8 support, so rerun the compatibility spike specifically on our target PHP 8 and Symfony version before deciding. The broader risks remain: stale release cadence, likely Symfony-version drift, upstream fixes arriving only via the monorepo, and zero downstream users to surface bugs. If the spike passes, vendor the code into our tree and own it. If it does not, copy the model and skip the bundle. Either way, assume authentication, authorization, and privacy compliance are our problem, not the package's.