Cart Shipping Laravel Package

Technical Evaluation

Architecture fit. Weak. elcodi/cart-shipping is a Symfony-flavored e-commerce component from a suite explicitly "built on top of Symfony." Its natural integration surface is the Symfony DI container, EventDispatcher, Doctrine ORM mappings, and (depending on the bundle variant) Symfony validators/forms. Laravel is built on Illuminate's container, Eloquent, its own event bus, and Laravel-native validation. That is not a superficial difference — it means the package's wiring, persistence, and extension points do not map onto a Laravel application without an adapter layer, and possibly not even then. The parts most likely to be portable are plain value objects (carrier, shipping method, zone/range, price rule) and pure calculation logic; the parts least likely to be portable are exactly the parts that make it useful out of the box.

Integration feasibility. Low, and it fails at the first gate: Composer. A 2016 release will carry constraints around PHP 5.5/7.0 and Symfony 2.7/3.x. Any Laravel version worth targeting (Laravel 9/10/11) requires PHP 8.1+ and Symfony 6/7 components, so composer require will either refuse to resolve or force a global downgrade that breaks the rest of the stack. Beyond resolution, the code will need PHP 8 remediation (dynamic properties, removed functions, string-offset syntax) and Doctrine ORM version alignment if it persists entities. Realistically this is a fork-and-rewrite exercise, not an integration.

Technical risk. High, across every dimension:

• Lifecycle risk: EOL, archived, read-only, zero dependents, last release February 2016. No upstream fixes for CVEs, PHP releases, or carrier API changes.
• Correctness risk: shipping/tax calculation is financially material. A silent miscalculation (wrong zone match, stale weight bands, rounding) overcharges customers or eats margin; this is a business incident, not a bug ticket.
• Dependency risk: an abandoned transitive dependency will trip SCA tooling (Dependabot/Snyk) and can block CI/CD pipelines by policy.
• Knowledge risk: support channels (Gitter, elcodi.io docs, Twitter handle) are almost certainly dead a decade on. The code is the only documentation.

Key questions.

1. What is actually in the package — a framework-agnostic PSR-4 domain library, or a Symfony bundle with container/Doctrine coupling? The answer decides whether extraction is days or weeks.
2. Does it contain real carrier integrations, or only rule-based price/zone calculation? (Historically Elcodi shipping is rules, not carrier APIs — which means the "value" is a domain vocabulary we can reimplement cheaply.)
3. Which Laravel and PHP versions are in scope, and is there an existing Symfony/Elcodi application we are migrating from?
4. Is the intent to (a) depend on it, (b) fork it, or (c) mine it for domain design? Only (c) is defensible at score 2.34 / opportunity 0.31.
5. What maintained alternatives were compared — Sylius Shipping, Laravel-native shipping packages, or direct EasyPost/Shippo SDKs?

Verdict: do not adopt as a dependency. Treat it as a reference implementation and a source of domain vocabulary (carrier, shipping method, zone, weight range, price rule) for a Laravel-native build.

Integration Approach

Stack fit. Poor as a dependency, acceptable as a pattern source. The only realistic path is an anti-corruption boundary: port the concepts into app/Domain/Shipping, back them with Eloquent models and Laravel migrations, dispatch Laravel events, and validate with Laravel's validator. Do not attempt to boot Symfony's container inside Laravel to satisfy the package — that is a permanent tax for a 2016 component.

Migration path. Three options, in order of preference:

1. Reimplement in Laravel (recommended). Extract the rule semantics from the source (read it, don't require it), write a small shipping-rule engine with Eloquent-backed shipping_methods, zones, ranges, rates, and a ShippingCalculator service behind an interface. Estimate 2–4 weeks including tests.
2. Fork and strip. Fork MIT-licensed code, delete the Symfony bundle/DI layer, keep and modernize the value objects and calculation services, publish internally as acme/shipping-domain. Viable only if the domain logic is substantial; estimate 3–6 weeks plus perpetual ownership.
3. Direct dependency. Not viable — Composer resolution against a modern Laravel app will fail, and forcing it creates an unmaintainable baseline.

If migrating from an existing Elcodi application, treat shipping as a bounded context: ETL the method/zone/range/rate tables into Laravel schemas, then run the new calculator in parallel with the old one and diff results before cutover.

Compatibility. Assume PHP 8.x and Symfony 6/7 conflicts, Doctrine ORM 2.x vs 3.x mapping differences, and deprecated PSR/EventDispatcher contracts. Any fork must re-pin constraints, run PHPStan at a meaningful level, and add a PHP 8 compatibility matrix to CI. Verify the MIT license text is preserved in the fork.

Sequencing.

1. Timeboxed spike (3–5 days): clone, inspect composer.json, run composer why-not against the target Laravel app, run static analysis, inventory Symfony/Doctrine coupling. Exit criteria: coupling is shallow enough to extract, or stop.
2. Domain extraction: isolate value objects and rule logic; write characterization tests against the original behavior so porting is verifiable.
3. Adapter layer: Eloquent repositories, Laravel event dispatch, config-driven rate tables, feature flag.
4. Parallel run: calculate shipping with old and new paths, compare on real carts, alert on variance.
5. Cutover and decommission: flip the flag, remove the fork from the dependency graph, archive the internal package with a named owner.

Operational Impact

Maintenance. High for the code size. Forking means we own PHP upgrades, security patches, and carrier/zone changes forever, with no upstream to rebase against. Budget an internal owner, PHPStan/SAST in CI, and a recurring dependency-review item. If we reimplement instead, maintenance collapses to our own small, tested service — the cheaper long-term option.

Support. Effectively none. Repository is read-only, issues are redirected to a parent project that is itself EOL, and the listed community channels (Gitter, elcodi.io docs, Twitter) are stale. Stack Overflow coverage for a 2016 Symfony e-commerce component is thin. Institutional knowledge will live with whoever reads the source, which is a real onboarding cost disproportionate to the business value delivered.

Scaling. Runtime scaling is a non-issue — shipping calculation is CPU-light and cacheable per cart/address, and rule tables are small and read-heavy, so Redis/CDN caching covers peak checkout traffic. The real scaling risk is functional: a frozen 2016 domain model will not express modern requirements (dimensional weight, multi-origin, carrier rate-shopping, duties/DDP, per-marketplace rules), and retrofitting those into an abandoned model costs more than building them once in Laravel.

Failure modes.

• Hard: Composer resolution failure on install/upgrade; fatal errors on PHP 8; Doctrine mapping conflicts if Eloquent and Doctrine coexist.
• Silent (most dangerous): incorrect zone or weight-band matching producing wrong shipping charges, tax base errors, or free-shipping thresholds misfiring — customer-facing and financially material.
• Process: SCA/Dependabot flags an abandoned dependency and blocks CI; a PHP minor upgrade breaks the build with no fix path.
• Organizational: knowledge holder leaves; fork drifts with no upstream to compare against. Mitigations: characterization tests, parallel-run diffing before cutover, a feature flag with instant fallback to flat-rate shipping, and a documented exit plan.

Ramp-up. The component itself is small, but the Symfony DI/Doctrine idioms are foreign to a Laravel team and the EOL context provides no scaffolding. Expect 1–2 weeks for the spike and assessment alone, 3–6 weeks for a fork-and-extract, versus 2–4 weeks for a clean Laravel-native shipping-rule engine that the team already knows how to operate. Given the EOL status, zero dependents, 2016 last release, and a 2.34 score, the recommendation is to consume this package as design input only — reimplement the domain in Laravel and keep the dependency out of the stack entirely.