Customer Bundle Laravel Package

Technical Evaluation

Bottom line for planning: sylius/customer-bundle is a Symfony/Sylius bundle, not a Laravel package. It is a read-only subtree split of the Sylius monorepo. For a Laravel product, the only defensible leverage is as a domain reference — a spec to port, not a dependency to install. Treat any estimate that assumes composer require as invalid until that distinction is accepted.

Architecture fit

• Tightly coupled to Sylius core abstractions: ResourceBundle resource config, ResourceInterface, the Sylius registry, Doctrine ORM mappings, and Symfony Security's ShopUser/User split. No seam for partial reuse.
• The transferable asset is the domain model, not the code: a clean separation of Customer (identity, group, addresses) from ShopUser (credentials, roles), plus customer-group hooks for pricing and promotion. That model maps cleanly onto Eloquent + Laravel guards.
• Low stars/dependents reflect the split-repo distribution model, not quality. Adoption is measured through sylius/sylius. Do not use these metrics as a build/buy verdict.

Integration feasibility

• Into Symfony/Sylius: high. Arrives transitively via sylius/sylius; there is no meaningful standalone integration.
• Into Laravel: low as a dependency (would require Symfony container, Doctrine, ResourceBundle, and Sylius conventions — effectively adopting Sylius to get a customers table). Moderate as a reference: schema, validation semantics, and flows are readable and portable.
• Realistic path: re-implement customers, customer_groups, addresses, and the shop-user link as Eloquent models, preserving the identity/credential split and group semantics. Budget for re-deriving behavior currently expressed in Sylius form types, validators, and state machines.

Technical risk

• Read-only repository: defects must be upstreamed to the monorepo or carried in a fork with permanent merge cost.
• Version coupling is strict — PHP and Symfony support is dictated by the Sylius release line.
• Large transitive surface (Doctrine, Symfony Security, Resource/Registry, validation, translation) means a wider upgrade and CVE blast radius than the package's apparent size.
• MIT license — permissive, no copyleft or attribution concerns.
• Principal risk is category error: scoping this as a drop-in PHP package under-estimates effort by an order of magnitude.

Key questions for the requester

1. Is the target stack Symfony/Sylius or Laravel? This single answer invalidates one half of any plan.
2. If Laravel: do we want the domain model ported, or are we evaluating Sylius as a platform?
3. Which Sylius release line, if any, and who owns the upgrade cadence?
4. What is the actual requirement — customer groups, multi-address, B2B pricing, guest-to-customer merge, GDPR anonymization? Only some justify this coupling.
5. Is there an existing identity/customer system of record that must be reconciled?

Integration Approach

Stack fit

• Symfony 5.4/6.x + Sylius: native, no work beyond normal Sylius install and resource configuration.
• Laravel 9+/10+/11+: no runtime fit; reference architecture only.
• Any other PHP framework: same conclusion — assumes Symfony kernel, DI, and Doctrine.

Migration path — Laravel (the likely scenario)

• Extract schema and semantics from the Doctrine mappings: customer↔address one-to-many with a default billing/shipping pointer, customer↔group many-to-one, customer↔shop-user one-to-one, plus soft-delete and anonymization fields.
• Re-implement as Eloquent models and migrations with explicit foreign keys and indexes on email, group, and customer_id.
• Map ShopUser semantics onto Laravel guards. Preserve the Customer/User split: it allows a customer record to exist pre-registration and supports guest-to-registered cart merge.
• Reproduce validation (country/zone rules, unique email per channel) as FormRequests and policies rather than porting Symfony validators.

Migration path — Sylius

• Consume transitively via sylius/sylius; avoid requiring this bundle directly unless there is a specific reason, as version alignment then becomes manual.
• Configure via Sylius resource config; extension-by-override is supported but raises upgrade cost.

Compatibility

• Pin PHP and Symfony to the chosen Sylius release matrix before committing to an LTS.
• Check fixture and translation dependencies if seeding from Sylius fixtures.

Sequencing

1. Resolve the stack question and the concrete customer-domain requirement (week 1).
2. Spike both options against identical acceptance criteria: minimal Sylius app vs. Laravel re-implementation of customer/address/group.
3. Data model review and API contract definition.
4. Auth and identity integration — highest-risk area.
5. Data migration and reconciliation if replacing an existing store.
6. Version pin, dependency monitoring, upgrade runbook.

Operational Impact

Maintenance

• On the Sylius path, the bundle rides the Sylius release train: fixes and patches arrive on their schedule, with no local hotfix unless forked. A fork converts every upstream change into manual merge work — price it before choosing to patch rather than upstream.
• On the Laravel path, maintenance transfers to the internal port, which is the point: you own the cadence, but you also own the domain bugs.
• Budget a recurring upgrade line item per Sylius minor release; treat it as standing cost, not ad hoc.

Support

• No dedicated support for this package. Community support runs through Sylius channels; commercial support exists at platform level, not per bundle.
• Knowledge concentration risk is real: one or two engineers will hold most Sylius-specific understanding on a port.

Scaling

• Domain logic, not a scaling unit; throughput is governed by query patterns and the database. Customer and address tables grow monotonically — index accordingly.
• Hot paths to review: customer-group resolution during pricing and promotion, address book reads at checkout, impersonation flows that load customer graphs, and guest-to-registered merges that can produce N+1s.

Failure modes

• Version drift between bundle and Sylius core, surfacing as confusing DI or mapping errors.
• Doctrine mapping conflicts when the app also defines Customer/ShopUser — requires override config, not parallel classes.
• Security regressions in authentication, impersonation, or password reset — outsize impact; require integration tests.
• Silent behavior changes in group or address validation across minor upgrades — pin and diff release notes.
• Incomplete anonymization on customer deletion — a compliance exposure, not a bug.

Ramp-up

• Symfony team: days to productive, weeks to confident with Sylius Resource/Grid/StateMachine conventions.
• Laravel-only team: two to four weeks to internalize the domain semantics well enough to make sound build-vs-port calls; the port itself is the larger effort.
• Primary references are Sylius documentation and the monorepo source — the split repo carries code history but not issues, PRs, or discussion.

Recommendation: Reference-only for Laravel. Do not add as a dependency. Revisit as a direct integration only if Sylius enters the platform decision; until then, use it to shortcut schema and identity-boundary discovery and to sanity-check the internal design.