Sales Bundle Laravel Package

Technical Evaluation

Architecture fit: Effectively zero for a Laravel runtime. sylius/sales-bundle is a Symfony 2.x bundle — it depends on Symfony's service container, bundle bootstrapping, Doctrine ORM annotations/mappings, the Symfony event dispatcher, and Sylius-era conventions. Laravel's container, Eloquent-first persistence, package discovery, and event model do not map onto any of that. This is not a PHP library that happens to have Symfony glue; the Symfony glue is the package. A TPM should classify it as a domain design reference, not a runtime dependency.

Integration feasibility: Low. There is no plausible install path into Laravel: composer require would attempt to resolve Symfony 2.x components, Doctrine annotations, and PHP constraints that no current Laravel install satisfies. Any attempt to bridge it would require emulating bundle registration, translating service definitions, and carrying Doctrine superclass mappings alongside Eloquent — a custom shim with no upstream to lean on. The archived, read-only status, 18 stars, and zero dependents confirm there is no community path either.

Technical risk: High and asymmetric. The upside is a well-shaped order domain (Order → OrderItem → OrderItemUnit, polymorphic Adjustments, explicit state machine). The downside is every operational risk you can name: abandoned upstream, Symfony 2 EOL, no security patching, no compatibility commitment with current PHP, no one to escalate to, and an immediate fork liability the day it enters composer.json. The transferable value is readable in a couple of hours; the cost of adopting it is permanent.

Key questions:

• Are we evaluating this as a runtime dependency or as a reference model for order lifecycle, pricing, adjustments, and fulfillment states? (Almost certainly the latter — confirm this explicitly with the sponsor.)
• Which specific concepts do we actually need — unit-level order items, adjustment ledger, sequential order numbering, or just the state machine? Each has a different build cost in Laravel.
• Is there a hard constraint forcing Symfony 2 / Sylius compatibility (e.g., an existing legacy system producing order data), or is this a greenfield Laravel decision?
• What is the cost of a small Laravel-native order aggregate versus the cost of a permanent fork of archived Symfony 2 code?
• Are maintained alternatives already evaluated — current Sylius, a Laravel commerce package, or plain Eloquent + symfony/workflow?

Integration Approach

Stack fit: Very weak. The bundle assumes Symfony 2 DI, Doctrine mappings, and Sylius core services. A Laravel team gets no leverage from any of the runtime code; the only salvageable asset is the model graph and state semantics, which are framework-agnostic ideas expressed in framework-specific code.

Migration path: Do not migrate the bundle into Laravel. Instead, extract the domain model: the orders → order_items → order_item_units shape (one unit row per quantity, enabling partial refund/ship/discount without bolted-on refunded_quantity columns), a polymorphic adjustments table attaching to orders and items, derived totals rather than a mutable total column, and an explicit order state machine (cart → addressed → shipping_selected → payment_selected → confirmed → fulfilled/cancelled). Reimplement those as Eloquent models, a single workflow class (symfony/workflow works standalone, or spatie/laravel-model-states), and Laravel domain events. If legacy Symfony 2 order data exists, do a one-time ETL — never carry the bundle forward as a bridge.

Compatibility: Effectively incompatible with modern Laravel and modern PHP without significant custom glue. Archived status means no guarantees against current PHP, Doctrine, or Symfony components, and zero dependents means no documented integration path and no community pressure to keep it working.

Sequencing: Run this as a design exercise, not an install:

1. Domain discovery — read the source (Order, OrderItem, OrderItemUnit, Adjustment, configuration YAML, state machine config) and write down the model graph in our own words. That write-up is the deliverable.
2. Minimum viable reimplementation spike — one order lifecycle, adjustments, and derived totals in Laravel, ~1–2 weeks.
3. Legacy data assessment — only if existing Symfony 2 order data must be carried forward; scope the ETL separately.
4. Build-vs-buy decision — compare the in-house aggregate against a maintained commerce platform, with the archived bundle cited as prior art.
5. Explicitly deprioritize direct integration unless a hard Symfony 2 constraint is confirmed — which would itself be a roadmap-level red flag.

Operational Impact

Maintenance: High if adopted — indefinite if adopted. Archived read-only packages receive no bug fixes, no security patches, and no PHP version bumps. A Laravel team would own a fork immediately: Symfony 2 compatibility shims, Doctrine mappings, and the transitive dependency tree. That is disproportionate overhead for an order engine whose entire value is a handful of modeling decisions we can reimplement natively.

Support: Weak. No active maintainers, no vendor, no dependents, limited internal expertise. Support would depend entirely on team familiarity with Symfony 2 and Sylius internals — a specialist skill with almost no reuse in a Laravel shop. If it appears in a dependency inventory today, treat it as a legacy audit finding and quantify the exit cost rather than the support path.

Scaling: Unknown and unmeasurable from current evidence. There is no modern evidence of throughput, performance characteristics, or operational hardening. Any scaling discussion would be dominated by the Laravel↔Symfony 2 bridge rather than by the order engine, which is the wrong place for a team to spend its scaling budget.

Failure modes: Composer/dependency resolution conflicts on install; Symfony 2 container boot failures; Doctrine mapping incompatibilities with modern PHP; missing Sylius core services; unmaintained transitive dependencies; inability to patch a disclosed CVE; documentation drift and stale examples from the Symfony 2 era. In production these become release blockers and incident risks with no upstream escalation path.

Ramp-up: Slow for Laravel engineers and largely wasted. Ramping up means Symfony 2 bundle conventions, Sylius domain familiarity, and Doctrine expertise — none of which transfer to the target stack. Budget for reimplementation onboarding (a day to read and document the domain model, then normal Laravel work) rather than bundle onboarding, and treat any estimate that assumes the team will "just learn the bundle" as a hidden fork-and-maintain line item.

TPM recommendation: Do not adopt. Log it as a reference artifact for the order-domain design spike, keep it out of composer.json, and make the standing decision it surfaces explicit: fund a small Laravel-native order aggregate (or a maintained commerce platform) instead of carrying archived Symfony 2 code.