Customer Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the customer/account domain. This bundle is a mature reference implementation of the customer bounded context — Customer, CustomerGroup, addresses (multiple per customer with default billing/shipping), registration, profile editing, password reset, guest-to-customer conversion, and soft-delete/anonymization. It gives you a costed baseline for scoping "build accounts ourselves" rather than a blank page, especially on the fiddly parts teams under-estimate.
• B2B and segmentation roadmap. CustomerGroup is the hook most commerce roadmaps eventually need — wholesale/tiered pricing, tax zones, catalog visibility, promotion eligibility. Reviewing this model early forces the decision of whether segmentation lives on the customer entity or in a separate pricing service, and that decision is expensive to reverse.
• Identity boundary as a product decision. The bundle cleanly separates customer (commerce profile, addresses, groups) from user/shop-user (credentials, roles, auth). That split is worth copying even if we never touch Sylius: it lets ops and support edit customer data without touching auth, lets a customer exist before registration, supports guest-to-registered cart merge, and lets us swap auth providers (SSO, social) without migrating order history.
• Platform selection input. If Sylius is on the table as a commerce engine, this bundle is representative of what we inherit — complete domain coverage, but Symfony-coupled and released only as part of a monorepo split. It sharpens the scorecard for a buy-vs-integrate call.
• Compliance and data lifecycle. The customer/address anonymization semantics are a useful reference for GDPR deletion design — the kind of requirement that is cheap to spec now and expensive to retrofit.
• Not a decision driver: 3 stars and 0 dependents carry no adoption signal here — they reflect a read-only subtree split, not quality or traction. Treat popularity metrics as noise and this package as documentation.

When to Consider This Package

Consider it when:

• You are scoping account management, multi-address profiles, or B2B customer groups and want a validated schema and flow model before committing to migrations and API contracts.
• You are already on Sylius/Symfony and need to extend customer behaviour (custom entity fields, group-based pricing rules, template overrides). In that case you consume it transitively via sylius/sylius — never as a direct dependency.
• You want to stress-test our own customer/user separation against a model that has survived real commerce workloads.
• You need to estimate the true cost of the customer domain — the bundle shows how much behaviour (validation, factories, state, forms) hides behind a "simple" customers table.

Look elsewhere when:

• You expect a Laravel package you can install. There is no service provider, no Eloquent, no Laravel auth integration. Adopting it means adopting Symfony's container, Doctrine, ResourceBundle, and Sylius conventions — i.e. adopting Sylius to get a customer table. The realistic Laravel path is to port the model, not the code.
• You need a standalone identity or customer package with its own release cadence. This is a read-only split; fixes must go upstream or into a fork with a permanent merge burden.
• You need community support or a maintenance guarantee. There is none at this package level, and version alignment is dictated by the Sylius release line.
• You need anything outside the customer context — cart, checkout, orders, payments, promotions live in sibling bundles, so this alone delivers no working capability.
• Your actual requirement is narrow (e.g. just an address book). The full coupling isn't justified; build the small thing.

How to Pitch It (Stakeholders)

To executives: "This is a component of the Sylius e-commerce framework, not a product we can adopt on our stack. It's free (MIT) and it is a complete, mature model of how customer accounts, addresses, and customer groups work in an online store. My recommendation is to use it as a design reference for our own account and B2B segmentation work — it saves us real discovery time on schema, address handling, and the customer/user split — but we do not put it in our dependency list. It's built for Symfony, it's a read-only mirror of a larger repository with zero external consumers, and adopting it would effectively mean adopting Sylius. Low cost, low risk, no production dependency."

To engineering: "Read the Customer, CustomerGroup, and address/registration flows before we design ours. Copy the customer/user separation (commerce profile vs. credentials) and the address model (one-to-many with default billing/shipping pointers), plus the group semantics for pricing tiers and the soft-delete/anonymization approach. Don't copy the code — it's Symfony- and Doctrine-bound with no seam for partial reuse, and the read-only split means no version to pin and no community to lean on. Budget for re-deriving the behaviour that lives in the Symfony form types and validators as Laravel FormRequests and policies. Revisit only if Sylius enters the platform decision at a strategic level."

Recommendation: Reference-only. Do not add as a dependency. Revisit if and when Sylius becomes a platform candidate.