Customer Bundle Laravel Package

Technical Evaluation

Architecture fit

• The package is a Symfony bundle, not a Laravel package: it ships CustomerBundle with a DependencyInjection extension, service definitions, Doctrine ORM mapping, and configuration trees consumed via config/bundles.php. None of that model exists in Laravel, so the phrase "Laravel/PHP package" is a category error — the correct framing is "Laravel/PHP stack, Symfony-bundled artifact."
• Domain scope is narrow and reasonable: a Customer entity (email, names, phone, gender, birthday), factory, repository, manager, and a security/login flow built on Symfony's security firewall. If we need a "customer profile attached to a user" primitive, the modeling is roughly transferable; the code is not.
• It is a read-only split repository from the Monofony monorepo. That means pull requests are not accepted here, issues may be ignored, and the canonical source lives elsewhere. Any fork we depend on becomes our own maintenance burden.
• Hard dependency reality: this bundle assumes Doctrine ORM, Symfony Security, Symfony EventDispatcher, and Sylius-adjacent conventions (CustomerInterface, resource factories). Pulling it into Laravel means porting, not installing.
• v1.10.0 changes essentially nothing structurally. "Add support for PHP 8" is a runtime-floor change only — no Symfony version bump, no Doctrine/DBAL modernization, no DI or security-config migration. The bundle remains a Symfony 4.4/5.x-era artifact that happens to now parse on PHP 8.

Integration feasibility

• In Laravel: not feasible as a dependency. Composer will resolve it on PHP 8, but the bundle's service container wiring will never execute under Laravel's kernel. Realistic paths are (a) reimplement the domain model in Eloquent, or (b) run Symfony alongside Laravel as a separate service — both are weeks-to-months decisions, not a sprint task.
• In Symfony/Sylius: feasible, but only as a reference implementation or for a legacy Monofony-flavored app. PHP 8 support removes one (and only one) blocker — the Symfony 6.4/7.x DI signature changes, PasswordEncoder → PasswordHasher rename, and Doctrine DBAL 3/4 typing changes all remain unaddressed.
• Effort framing for a TPM: "adopt" vs "mine for patterns." I would budget this as a design-reference asset (a few days of engineering reading) rather than a vendor/OSS dependency (zero days, because we should not depend on it).

Technical risk

• Abandonment risk: high (downward-adjusted, not resolved). A single PHP 8 compatibility commit after a multi-year quiet period is a maintenance signal, not a maintenance commitment. Still 1 star, ~0 dependents, no release cadence, no visible CVE-response path, and no community to escalate to. Treat v1.10.0 as "someone unblocked the build," not "the project is alive."
• Compatibility risk: high, marginally reduced. PHP 8 is now nominally in scope — but "PHP 8" in a 2021-era bundle usually means 8.0, not 8.1/8.2/8.3; we would need to verify against our actual runtime. A 2021 Symfony bundle still will not drop into a Symfony 6+/7 application without patching: TreeBuilder/Configuration signatures, service autowiring, attribute-vs-annotation mapping (this will use annotations), and PasswordEncoder → PasswordHasher renames all bite. None of these were touched in v1.10.0.
• Security exposure: moderate. The bundle includes authentication surfaces (login/logout, customer resolver, password handling). Unmaintained auth code is the worst kind of unmaintained code. A PHP-version compatibility patch is not a security-maintenance signal — if anything, it invites adoption of a still-unwatched auth surface. If we did depend on it, we would own the CVE triage.
• Licensing risk: none. MIT, clean.

Key questions

• Is the actual requirement "customer profile CRUD attached to an existing user/account" — in which case Laravel's users + a customer_profiles table is a 2–3 day build and the bundle is irrelevant?
• Are we evaluating this because someone assumed it was a Laravel package? If so, close the ticket: the premise is wrong, and v1.10.0 does not change that.
• What exactly does "PHP 8" mean here — 8.0 only, or 8.1+/8.3? Does the release note correspond to a real CI matrix, and was anything else (Symfony, Doctrine, security) touched? Our answer changes the compatibility section from "high risk" to "moderate risk," and we should not assume it.
• Is v1.10.0 a one-off unblock, or the start of a release cadence? One release is not a trend. Re-evaluate only if a second, substantive release lands within two quarters.
• Does the target service run Symfony/Sylius already, or Laravel? The answer determines whether this is a "no" or a "maybe, as reference only."
• If we did fork it, who owns the upstream-tracking and CVE-response obligation, and for how many years?
• What is the trigger condition that would make a Symfony sidecar service acceptable in our architecture — or is a polyglot runtime a non-starter?

Integration Approach

Stack fit

• Laravel application: no fit. Different container, different ORM, different auth pipeline, different config model. There is no adapter layer that makes a Symfony bundle's DI extension meaningful inside Laravel's service container. PHP 8 support changes nothing here — the incompatibility is architectural, not runtime.
• Symfony/Sylius application: partial fit. Conceptually aligned (Sylius resource conventions), and v1.10.0 modestly widens the set of runtimes that will at least boot. But Symfony 6/7 and Doctrine DBAL 3/4 drift still make it a porting exercise. Treat the bundle as a specification: copy the entity shape, factory/manager split, and resolver pattern into our own code with modern attributes and our own tests.
• Polyglot (Laravel + Symfony sidecar): technically possible — the bundle could own a customer service behind HTTP — but the operational cost of a second runtime for a 5-field entity is not defensible.

Migration path

• Recommended path: none — do not migrate. Build the customer domain natively. v1.10.0 does not move this recommendation.
• If we must preserve Monofony/Sylius data: extract only the schema and the mapping contract (customer ↔ user, email uniqueness, soft-delete semantics), write a one-way importer into our own tables, and never let the bundle's code run in production.
• If a legacy Monofony app already depends on it: v1.10.0 is a lower-risk pin than the 2021 release if and only if we can confirm it boots on the legacy app's exact Symfony/Doctrine versions — which is the opposite of what a PHP-8 compatibility bump is for. Realistically: pin the exact release, vendor it via Composer path/vcs or a fork under our org, and freeze the Symfony/Doctrine versions on that service. Do not attempt an in-place Symfony 6 upgrade of a Monofony app on this bundle without a dedicated modernization project.

Compatibility

• PHP: previously characterized as 7.2–8.0 era; v1.10.0 adds PHP 8 support. Verify the exact minor version — assume 8.0 until proven otherwise, and test on 8.2/8.3 explicitly rather than trusting the changelog line.
• Symfony: unchanged — still targets ~4.4/5.x; Symfony 6+ requires code changes to DI and security config. This is now the primary compatibility blocker now that PHP 8 is addressed.
• Doctrine: unchanged — annotation driver assumptions; DBAL 3/4 typing changes will surface.
• Laravel: no compatibility surface at all — there is nothing to be compatible with.

Sequencing

1. Day 1 — Verify the release, don't trust it. Diff v1.10.0 against the prior tag (or the monorepo equivalent): confirm the change is scoped to PHP constraints/CI and that no Symfony, Doctrine, or security code was silently altered. Exit the whole evaluation if the diff touches auth code without a corresponding security note.
2. Day 1 — Validate the premise. Confirm target runtime (Laravel vs Symfony) and confirm the requirement is genuinely a customer profile, not a full CRM. Exit early if Laravel — v1.10.0 is irrelevant to that path.
3. Week 1 — Pattern extraction. If Symfony is in play, read the bundle for the entity/factory/manager/resolver split and the customer↔user mapping; write a one-page design note. Timebox: 2 days.
4. Week 2 — Native implementation. Ship customers table, model, factory, repository, profile-update endpoints, and validation in our own stack with our own tests. No code inheritance from the bundle.
5. Week 3 — Data path only (if legacy data exists). One-way importer + reconciliation report; no runtime dependency on the bundle.
6. Ongoing — Do not add to the dependency manifest. Record the decision and the v1.10.0 review in the ADR, noting explicitly that PHP 8 support was evaluated and judged insufficient to change the outcome, so this does not resurface next quarter.

Operational Impact

Maintenance

• As a dependency: full ownership transfer. Effectively no external maintainers, read-only mirrors, no upstream backports beyond occasional compatibility patches. Every Symfony/Doctrine/PHP upgrade becomes our patch. That is a permanent tax on a bundle that solves a small problem.
• As a reference: near-zero. A design note and a handful of copied ideas; no ongoing obligation.
• Updated read on v1.10.0: it demonstrates someone can still merge a PHP constraint, which lowers the odds of total rot — but it does not create a support contract. The relevant operational fact is no longer "no release since 2021" but "one compatibility release in four years, with authentication code inside." That is still disqualifying for a production dependency graph.

Support

• No vendor, no commercial support, effectively no community (1 star, ~0 dependents). Slack/issue escalation is not a real channel; the read-only split means even a well-formed bug report has no guaranteed destination.
• Internal support would fall to whichever engineer forked it — a single point of failure with no documentation handover beyond the code itself.
• For the Laravel ask specifically: our own team's Eloquent expertise is the correct support model, and it is available today.

Scaling

• The bundle itself is not a scaling concern — customer records are low-volume, low-QPS, and cache-friendly. Doctrine + a customers table scales to the sizes we care about. PHP 8 support has no bearing on throughput or capacity planning.
• The real scaling cost is organizational: a second runtime, a second ORM, a second auth stack, and a second upgrade cadence for one entity. That is disproportionate to the domain.
• If the customer domain needs to serve other services later, the answer is an API boundary we own, not a Symfony bundle we inherited.

Failure modes

• Silent DI failure: bundle registered but extension not loaded → services not wired, auth resolver returns null, customers can't log in. Debug cost is high because the failure is config-shaped, not code-shaped.
• Annotation mapping breakage: Doctrine annotation reader removed/deprecated → entity mapping silently ignored or hard-fails on cache warmup. Unchanged by v1.10.0.
• Security regression: obsolete password hashing or session handling carried forward into a modern app, producing an auth bypass or a forced mass password reset.
• False-confidence trap (new, specific to this release): v1.10.0 makes the package install on PHP 8, and "it's maintained again, it supports PHP 8" becomes the argument that carries it into the dependency manifest. The runtime floor moved; the Symfony/Doctrine/security posture did not.
• PHP-8-window ambiguity: assuming "PHP 8" means our 8.2/8.3 runtime, then discovering deprecations or hard failures in production rather than at evaluation.
• Composer resolution trap: it installs cleanly, which creates a false signal that integration succeeded; the real failure appears at runtime, after sprint commitment.
• Mirror divergence: patching the read-only split while the monorepo moves on — or doesn't — leaving us maintaining a fork with no upstream to rebase against.

Ramp-up

• For a Laravel team: negative ramp-up. Engineers must learn Symfony bundle conventions (DI extensions, service tags, security firewalls, Doctrine mapping) purely to evaluate code they will not ship. Cost with no return — and v1.10.0 offers that team nothing.
• For a Symfony team: low, ~1–2 days to read the entity/factory/manager/resolver pattern and decide what to reimplement. Add a half-day to verify the v1.10.0 diff and PHP 8 compatibility claim.
• Recommended ramp plan: one senior engineer, two-to-three-day timebox, deliverable is a half-page "build vs. reuse" memo plus an Eloquent schema sketch. If that memo does not justify reuse — and given 1 star, ~0 dependents, one compatibility release in four years, and an untouched Symfony 6/7 gap — it will not. Close the evaluation and build the domain natively.