Cart Shipping Laravel Package

Product Decisions This Supports

• Build vs. buy, settled toward build. This is not a package you adopt; it is a spec you read. The shipping-cost domain (zone/warehouse resolution, weight and price thresholds, rule matching against a cart) is well modeled here and MIT-licensed, so it's legitimate input to your own design — but the artifact itself is a liability, not a dependency.
• Feature scoping for shipping logic. Use the source as a checklist for what a cart-shipping layer actually needs to answer: which methods are eligible, how zones and carriers are resolved, where price rules intersect with shipping rules. Useful for sizing a sprint, not for shipping code.
• Legacy triage. If you've inherited an Elcodi/Symfony 2 storefront (or are evaluating an acquisition that runs one), this is roadmap material: it tells you exactly what's load-bearing and what a migration must preserve.
• Supplier and risk review. Archived, read-only, EOL since 2016, zero dependents. That's a clear signal for any "can we just reuse this?" proposal in a roadmap or architecture review — the answer is no, and you now have the evidence.

When to Consider This Package

Consider it only as reference material, under these conditions:

• You maintain a legacy Elcodi/Symfony 2 application and need to understand existing shipping behavior before migrating.
• You're designing a shipping-rule engine and want a proven domain model to react to — reading time measured in hours, not an install.
• You're doing technical due diligence on an acquisition or a codebase audit and need to identify dead dependencies.
• You want to vendor the MIT-licensed algorithms into your own code, accepting full ownership and rewriting for current PHP.

Look elsewhere — decisively — if any of the following is true:

• Your stack is Laravel. This is Symfony 2-era componentry; the integration cost exceeds the value by an order of magnitude.
• You need PHP 8.x, PSR-compliant dependencies, or anything that receives security patches. There is no maintainer and no release since February 2016.
• You need actual carrier integration (rates, labels, tracking). This package is rules and domain objects; it does not talk to carriers.
• Your compliance posture requires a supported vendor or a software bill of materials with a live upstream.
• Note the supply-chain detail: the linked repository is the Elcodi monorepo, and this split is explicitly read-only with pull requests declined. There is no path to a fix if you find a bug.

How to Pitch It (Stakeholders)

To executives: We evaluated reusing an open-source e-commerce shipping component. It's MIT-licensed and the domain modeling is genuinely good, but the project is end-of-life, archived, unmaintained since 2016, and receives no security updates. Adopting it would trade a short-term build saving for a permanent, unpatchable liability. Recommendation: do not add it as a dependency. Budget a small amount of engineering time (a day or two) to mine it for design patterns, and build our shipping logic in-house on our current stack. Net effect on the roadmap: no delay, marginally lower design risk.

To engineering: Treat elcodi/cart-shipping as documentation, not code. It's Symfony 2 / PHP 5-era, the split is read-only, PRs are declined, there are zero dependents, and there's been no release in roughly a decade. Don't put it in composer.json. Do read the rule-matching and cart-price-rule classes for the domain model, then implement fresh — the license permits it, but anything you copy, you own and maintain forever. If someone proposes installing it, this assessment is the answer.