Weave Code
Shop Bundle Laravel Package
softspring/shop-bundle
Softspring Shop Bundle adds a ready-made e-commerce layer to your PHP application: product catalog, categories, carts, checkout, orders and payment integration, with configurable entities and templates you can extend. A practical starting point for building online stores without reinventing core sho...
A shop bundle
Frequently asked questions about Shop Bundle
- Is softspring/shop-bundle a Laravel package?
- No. It is a Symfony bundle, not a Laravel package. The -bundle suffix, the DependencyInjection extension and configuration tree, service tagging, Doctrine ORM mappings, Twig templates and a Composer Flex recipe are all Symfony-native conventions. There is no service provider, Eloquent model or Blade view layer here, so it cannot be dropped into a Laravel application as-is.
- Can I use softspring/shop-bundle in a Laravel application?
- Realistically no. There is no meaningful seam between Symfony's bundle and DI machinery and Laravel's Eloquent, Blade and service-provider model, so this would be a rewrite rather than a port. If your target application is Laravel, treat this package as out of scope and evaluate a Laravel-native commerce option instead. Record the framework decision as final before spending any further evaluation effort.
- How do I install softspring/shop-bundle?
- On Symfony the expected path is composer require softspring/shop-bundle, accept the Flex recipe, enable the bundle in bundles.php, configure the extension tree in your config directory and run Doctrine migrations. However, the public evidence base is effectively empty — no stars, no dependents, no documented install walkthrough — so feasibility should be recorded as unproven rather than assumed. Timebox a spike that installs it against your pinned PHP, Symfony and Doctrine versions and runs one end-to-end product to cart to order flow with a stub payment provider.
- Which Symfony and PHP versions does softspring/shop-bundle support?
- The published description does not state explicit PHP or Symfony constraints, so read the composer.json require block before planning anything. The realistic target is Symfony 5.4 or 6.x with PHP 8.x and Doctrine ORM, but that is unverified. Version drift matters here: a bundle that blocks your next Symfony LTS upgrade also delays security patching, so confirm upgrade headroom in the spike.
- What features does softspring/shop-bundle provide?
- It packages a modular e-commerce foundation: a product catalog with categories and flexible attributes, a cart and checkout workflow designed to be extended, order management with status tracking, and integration hooks for payment and shipping. It is a configurable Symfony bundle with sensible defaults rather than a complete storefront application. Think of it as a starting point for core shopping logic, not a finished shop.
- Does softspring/shop-bundle require other Softspring bundles?
- That is one of the first things to verify. A bundle in this family commonly presumes sibling Softspring packages for store, user, CMS and payment concerns, and each assumption becomes either a hard dependency or integration work you did not plan for. Check the composer.json requirements and the extension configuration before committing to an architecture.
- Can I extend the product, cart and order entities?
- The package is described as shipping configurable entities and templates you can extend, which is the usual Symfony pattern of overriding Doctrine mappings and Twig templates. The real question is how opinionated the domain model is: whether it owns its migrations and whether Product, Cart, Order and Payment classes are designed for subclassing or replacement. If those classes leak into your controllers, domain services or schema, exit costs grow every month, so test the extension path in the spike.
- Is softspring/shop-bundle production ready and actively maintained?
- Treat it as unproven. Zero stars, zero dependents, no scoring and a one-line description mean no third party has publicly validated the install path, no issue history demonstrates maintainer responsiveness, and no downstream project has absorbed a breaking change on your behalf. Ask for the last commit date, tagged releases and semver discipline over the last twelve months, and check whether a test suite and CI status are readable. With a single maintainer, adopting it makes your team the de facto maintainer, which is a headcount and roadmap risk, not just a code risk.
- Does softspring/shop-bundle handle payments and PCI compliance?
- It provides payment integration hooks rather than a full payment stack. Anything on the checkout path expands your PCI scope, so determine early whether payment is a pluggable abstraction or hardcoded to a specific PSP. Regardless of the answer, keep real payment handling outside the bundle and behind your own interface.
- What are the alternatives to softspring/shop-bundle?
- On Symfony, the mature comparisons are Sylius and Aimeos, both with far larger adoption and documented upgrade paths. On Laravel, evaluate Laravel-native commerce packages instead, since a Symfony bundle is not a viable option there. Weigh any alternative against the same criteria: adoption, release cadence, upgrade headroom and who internally owns it.
Weaver
How can I help you explore Laravel packages today?