Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Shop Bundle Laravel Package

kitpages/shop-bundle

KitpagesShopBundle is a Symfony bundle for building e-commerce shops, providing product catalogs, shopping carts, checkout flows, and order management with configurable entities and templates.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Domain scoping for a commerce build. The package enumerates the surfaces most commerce requirements eventually hit — cart, order lifecycle, invoice generation, shipping, discounts. Use it as a requirements checklist to catch the items that are routinely under-scoped in early roadmaps (proration, discount stacking, tax/shipping interaction with order state).
  • Build vs. buy calibration. Reading its model is a cheap way to size the "buy" option. The presence of a discount engine, invoice, and shipping layer in an alpha bundle is evidence that these modules are non-trivial — useful ammunition when estimating a homegrown cart at "two sprints."
  • Prioritization of the hard 20%. Discounts and shipping rules are where commerce projects overrun. Treat its module boundaries as a proxy for complexity weighting in the roadmap: cart and catalog are commodity; discount, invoice, and shipping are the differentiators/risk items.
  • Feature-gap analysis against competitors. Its feature list is a useful baseline to diff against modern platforms, showing what "table stakes" looked like and which capabilities (payments integration depth, multi-currency, tax engines) it simply doesn't cover.
  • Opportunity signal, not a solution. The 0.41 opportunity score plus zero dependents suggests latent demand for lightweight cart/order primitives that this specific artifact never captured. That is a market signal for a build decision, not a case for adoption.

When to Consider This Package

  • Only as a reference artifact. Viable if you need a compact, MIT-licensed example of a cart-to-invoice state model to inform your own schema or domain language.
  • Legacy Symfony 2 estate. If you already maintain a Symfony 2.x application (end-of-life since 2018) and need a shopping skeleton for an internal prototype, it is at least framework-native — though still alpha and unmaintained since 2015.
  • Never for a Laravel runtime dependency. This is a Symfony 2 bundle, not a Laravel package. There is no drop-in path; the port cost exceeds writing the equivalent domain model from scratch, and you would inherit the bundle's assumptions rather than Laravel's conventions.
  • Look elsewhere when any of these hold: you need maintained code, security patching, a supported PHP version, community support, or dependents to learn from (there are zero). Fails all maintenance gates for production.
  • Better alternatives for evaluation: Sylius or Aimeos for Symfony/PHP reference architectures, Lunar or Bagisto for Laravel-native commerce, or Laravel Cashier plus a hand-rolled cart when scope is simple. Choose those as comparison points; use this bundle only as a free design document.
  • Disqualifiers: alpha state, last release 2015-07-06, 13 stars, 0 dependents. Any one of these blocks adoption; together they mean no security response and no upgrade path.

How to Pitch It (Stakeholders)

To executives: We evaluated kitpages/shop-bundle and recommend against adopting it. It is an alpha-stage Symfony 2 bundle last released in 2015, with 13 stars and no downstream dependents — it cannot be patched, supported, or upgraded. However, it is a useful free blueprint: its cart, order, invoice, shipping, and discount modules give us a credible checklist for scoping our commerce work and a sanity check on effort estimates, particularly for discounts and shipping, which are the usual overrun areas. Net decision: zero license cost, zero integration cost, one to two days of architect reading time, and a stronger build-vs-buy case either way.

To engineering: Do not vendor this. It is Symfony 2, not Laravel, and both the framework and the bundle are unmaintained. Use it as a read-only reference for domain boundaries and invariants — how it separates cart from order, where invoice generation hooks in, how discounts compose. Extract the data model and state transitions, then implement against Laravel conventions with a maintained commerce package or our own domain layer. Treat any code you like as inspiration, not as a starting point to port; the port would cost more than the rewrite.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
diephp/sequences
users-au/socialite-provider
twidpay/twid-logger
mrnewport/laravel-plaid
mrnewport/laravel-repo
mrnewport/laravel-docsign
mrnewport/laravel-stow
mrnewport/laravel-flow
mrnewport/laravel-priceable
mrnewport/laravel-nestedterms
fredmeng/laravel-apidoc-generator
itstructure/laravel-multilingual-tools
pdustdar/elasticsearch
markupai/php-sdk
rlacerda83/lumem-microservice-shipment
uni-method/symfony-lib
tacticmedia/scim-server-bundle
neika-ai/symfony-bundle
mattleads/agent-publishing-bundle
glavweb/framework-bundle