Shop Bundle Laravel Package

Getting Started

Start with a reality check before you write a single line of integration code: this is a Symfony 2 bundle in alpha, last tagged in July 2015, with no dependents. It will not install into a modern Laravel app — its composer.json will constrain symfony/* to 2.x components that conflict with Laravel's v6/v7 requirements, and even with --ignore-platform-reqs you inherit an unmaintained Doctrine/Symfony graph. Treat it as a reference implementation of a shop domain model, not a dependency.

What to do first:

1. Open the Entity/ directory. That's where the value is: the bundle models cart, cart lines, order, order lines, invoice, shipping/delivery, and discount/voucher as Doctrine entities. Read these before anything else — the docs are thin and the tests are the real specification.
2. Read the Doctrine mapping files (XML/YAML or annotations) alongside the entities; they encode the cascade rules and ownership that make the aggregate work.
3. Find the manager/service classes (the Manager, Service, or Handler namespace). Controllers in this bundle are thin; the money logic and state transitions live behind those services.
4. Look at the fixtures/tests for the canonical lifecycle: add line → update quantity → apply discount → validate cart → create order → generate invoice → mark shipped.

Your first concrete use case, if you're porting: reimplement the cart-to-order snapshot. That single flow exercises pricing, tax, discount ordering, and persistence — everything the rest of the bundle hangs off.

If you genuinely want to run it as-is, you need a Symfony 2.8 skeleton on PHP 5.6/7.0, Doctrine ORM, the bundle registered in AppKernel, and doctrine:schema:update --force (there are no migrations).

Implementation Patterns

Aggregate with line items. Cart and Order are roots; lines are children with cascade persist/remove. Keep that shape in Eloquent: Cart hasMany CartLine, Order hasMany OrderLine, and never let lines be saved independently of their root. Line rows should carry a price snapshot (unit price, tax rate, discount share) taken at add-to-cart time, not a live FK to the current product price — otherwise historical orders mutate when you change a product.

Manager/service layer over fat models. The bundle puts transitions in services rather than entities or controllers. Mirror this with Laravel actions (AddToCart, ApplyVoucher, PlaceOrder) so the same logic is callable from HTTP, console, and jobs.

Status fields as a de facto state machine. Order status, invoice status, and shipping status are separate columns advanced by explicit service calls. In Laravel, promote this to symfony/workflow or a small enum + transition guard class — the bundle's implicit version is the most common source of "order stuck in limbo" bugs.

Event hooks for extension. The bundle leans on the Symfony event dispatcher for post-order hooks (invoice generation, notifications). Map these to Laravel events/listeners: OrderPlaced, InvoiceIssued, ShipmentCreated. Keep invoice PDF generation and email in queued listeners.

Discount and shipping as order-level adjustments. The pattern is: compute line subtotals → sum → apply discount → apply shipping → apply tax. Get the order of those operations fixed early and test it; it's the part every shop gets wrong once.

Payment is not here. Expect to implement the gateway integration yourself behind a small PaymentGateway interface, driven by an order state transition.

Security. Access to an order is not just "is logged in" — the bundle uses a user/session association plus (in Symfony) voters. In Laravel terms: a policy on Order checking user_id or a signed guest token stored on the cart.

Gotchas and Tips

• Alpha + 2015 + Symfony 2 EOL = no security patches. Do not put this in front of real payments. Vendor the source or copy the entities into your app; don't composer require it.
• Doctrine vs Eloquent is not a mechanical translation. Cascade semantics, UnitOfWork change tracking, and lazy collections all differ. Budget real time for the mapping, or run Doctrine inside Laravel via laravel-doctrine/orm if you want the entities verbatim.
• Money type is the first thing to audit. If any totals are floats, convert to integer minor units before you trust a single number. Check tax rounding: per-line vs per-order rounding produces cent-level mismatches that surface only in reconciliation.
• EU/French VAT assumptions are likely baked in. The authors are a French agency; verify tax-inclusive pricing defaults and multi-rate handling before shipping outside the EU.
• Discount stacking and precedence is the least-tested area. Write characterization tests against the bundle's own fixtures before you change anything, then port those tests with the code.
• Debugging tip: assert invariants (sum(lines) - discount + shipping == total) in a test that runs over fixture carts. Totals drifting from their components is the signature bug in this class of bundle.
• Extension points: override services via the bundle's DI config / compiler pass, or decorate the manager classes. If you're reading rather than running, treat those service definitions as documentation of the intended seams.
• No admin UI, no API, no migrations. You're getting a domain layer only; everything around it is yours to build.
• Practical verdict: at 13 stars and a 0.25 score, this is a study dependency. Read the entities and the cart-to-order flow, port the invariants, and write your own thin implementation in Laravel.