Assortment Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, and largely a category error. sylius/assortment-bundle is a Symfony 2 bundle, not a framework-agnostic PHP library. It ships a Bundle subclass, a DI extension and compiler passes, and Doctrine ORM mappings in the Symfony 2 era (PSR-0 autoloading, Symfony\Component\HttpKernel\Bundle\Bundle base class). Laravel's service-provider/container model has no bridge to this contract, and even modern Symfony (5+/6+/7) removed the bundle conventions it depends on. There is no adapter path that preserves the package's value; any integration would be a rewrite wearing the package's namespace.

Integration feasibility — effectively zero as a runtime dependency. Composer resolution against a current PHP/Laravel constraint set will fail on PHP version, Doctrine ORM/DBAL versions, and transitive Symfony 2 components. The only environment where it could technically load is a legacy Symfony 2.8 application, which has been end-of-life since 2018. Treat "install this in our Laravel app" as not a viable story.

Technical risk — critical. Archived repository, ~20 stars, zero dependents, no upstream maintainer, no security response process, and an unmaintained transitive dependency graph. Running EOL PHP 5.x-era code in a modern estate means unpatchable CVEs, fatal errors on PHP 8 upgrades (dynamic properties, return types, Doctrine DBAL 3/4 API removal), and full ownership of any fork with no ability to rebase.

Key questions for the intake conversation:

• What is the underlying requirement — product catalog with variants, options, and properties? The score's high opportunity (0.74) against a low overall score (0.245) suggests the domain need is real and the package is not; confirm which signal prompted the request.
• Is there any legacy Symfony 2 code still in the estate that this was meant to match?
• Target stack and PHP version — Laravel 10/11 on PHP 8.2+?
• Do we need multi-channel, multi-currency, or inventory-per-variant behavior that the original model did not cover?

Integration Approach

Stack fit — do not integrate; harvest the model. The durable asset here is the domain design, not the code: Product → ProductVariant, ProductOption / ProductOptionValue with a variant-option join, and ProductProperty / ProductPropertyValue for non-variant attributes. That vocabulary became the canonical Sylius product model and is still the right conceptual starting point.

Migration path — none incremental; go greenfield. There is no upgrade route, no shim, and no partial adoption. The realistic options, in order of preference:

1. Reimplement natively in Eloquent — six or so models, migrations, and factories, using the bundle's schema as a reference spec only.
2. Adopt a maintained Laravel commerce package (Lunar PHP, Aimeos Laravel, Bagisto) if catalog requirements extend into pricing, carts, and checkout.
3. Adopt current Sylius — only if the target stack is Symfony, not Laravel.

Compatibility — assume none. PHP 8.2+ will surface deprecations and hard failures; Doctrine mappings predate attributes; PSR-0 will not autoload cleanly under modern Composer. Do not budget for "making it work" — that is a rewrite with extra steps.

Sequencing:

1. Extract the entity relationships and cardinalities into a written domain spec (half a day; this is where the value is).
2. Schema design review against actual requirements — flag where the original EAV-style property/option tables will hurt query performance.
3. Timeboxed spike: native Eloquent models plus a variant/option query, one sprint.
4. Decision gate: build vs. buy against the maintained-package shortlist, using the spike as the estimate baseline.
5. Formally close the "integrate the bundle" track and record the rationale so it doesn't resurface.

Operational Impact

Maintenance — total ownership, no upstream. Archived means no bug fixes, no dependency bumps, no PHP-version compatibility work. A fork becomes an internal long-lived artifact requiring full-time-equivalent care that no team will budget for.

Support — none. Zero dependents and ~20 stars indicate no community, no Stack Overflow corpus, and no third-party consultants. Escalation path is the internal engineer who read the source.

Scaling — not applicable, but the design has known costs. The property/option value tables are EAV-adjacent: variant resolution and catalog filtering become multi-join queries that degrade as SKU counts grow, and they resist clean indexing and caching. If we reimplement, plan for denormalized read models or materialized catalog views early rather than after the first performance incident.

Failure modes:

• composer install fails outright on a modern constraint set — the most likely and least damaging outcome.
• If forced into a legacy container: fatal errors on PHP upgrade, silent data issues from stale Doctrine mappings.
• Security exposure through unpatchable transitive dependencies — the outcome that actually requires a risk acceptance signature.
• Scope trap: a team spends a sprint "modernizing" the bundle before concluding a rewrite is needed, burning the schedule for the same end state.

Ramp-up — asymmetric. Low to read: the model is small and legible, and a mid-level engineer can absorb it in a day. High to safely reimplement: variant/option combinations, default-variant selection, and property inheritance all carry subtle edge cases that only appear in production data, so budget a design review and a data-shape test suite rather than a straight code translation.

Recommendation: do not adopt. Close the integration track, retain the domain model as an architectural reference, and fund a native Eloquent implementation or a maintained Laravel commerce package. The 0.74 opportunity score is a signal about the catalog problem, not about this repository.