Commerce Module Laravel Package

Getting Started

• Confirm the host app first. This is a Badaso module, not a standalone Laravel e-commerce package. You need a working badaso/badaso install before adding it. Check your Badaso and Laravel versions in composer.json; the module’s constraints are the first compatibility gate.
• Install and publish.

  composer require badaso/commerce-module
  

  Then publish config, migrations, and assets using the provider FQCN found in vendor/badaso/commerce-module/src/:

  php artisan vendor:publish --provider="Vendor\\Commerce\\Providers\\CommerceModuleServiceProvider"
  php artisan migrate
  

  If the module ships seeders for Badaso menus/permissions, run them too; otherwise the “Commerce” menu may not appear in the admin panel.
• Look here first: src/Providers/ for bindings and publish tags, routes/ for the actual API/admin endpoints, database/migrations/ for the data model, and config/ for tunables. Run php artisan route:list | grep -i commerce to see what the package actually exposes.
• First use case: log into Badaso admin (/admin), open the Commerce menu, create a product/category, then call the module’s product listing route from a storefront or Postman. That confirms install, permissions, migrations, and routing in one pass.

Implementation Patterns

• Admin-first catalog management. Use Badaso’s CRUD/admin UI for products, categories, and orders rather than building your own admin. Extend the catalog by adding fields through the module’s migrations/CRUD config, not by editing vendor files.
• Storefront integration. Treat the module as the commerce backend:
  • Same Laravel app: resolve the module’s models/services directly and wrap them in your own controllers.
  • Headless frontend: consume the module’s API routes; add your own API Resource layer if the default JSON shape is too coupled to Badaso.

  Route::get('/shop/products', [ShopController::class, 'index']);
  // ShopController can call the module service/model, or proxy the module API.
  

• Checkout/order flow. Keep your cart and checkout logic in your app unless the module provides a cart service. Persist orders through the module’s order model/service, then attach payment status. Use Laravel events/listeners around order creation and status changes so payment, email, and inventory logic stay decoupled.
• Customization without forking. Publish config, bind your own implementation over the module’s service in a service provider, or extend the module’s models. Register overrides in AppServiceProvider/a dedicated provider and keep vendor untouched.
• Permissions and menus. After install, verify Badaso roles have access to the new Commerce menus. Seed permissions in deployment scripts; otherwise developers see the menu locally but production admins do not.
• Testing. Use RefreshDatabase and build your own factories for commerce tables; do not assume the package ships complete factories. Test the API contract your storefront depends on, not just admin CRUD.

Gotchas and Tips

• Low adoption means low documentation. With 4 stars and 0 dependents, expect to read source more than README. Start with the service provider and routes; they reveal bindings, middleware, and publish tags faster than guesswork.
• Version lock is real. Badaso modules often pin Badaso/Laravel versions tightly. If Composer resolves an old Badaso, check whether the module is compatible with your app before forcing an update.
• Migrations can collide. Review migration files before running them against an existing database. Backup first; the module may create tables with generic names.
• Admin assets/menus need publishing and seeding. If the Commerce menu is missing, check vendor:publish, menu seeders, and Badaso cache commands. Clear route/config/view caches after install.
• API auth is inherited from Badaso. Check route middleware before assuming endpoints are public. Storefront calls may need Passport/Sanctum tokens or custom public routes.
• Debug with the framework. php artisan route:list, php artisan about, Laravel logs, and Telescope are more useful than package docs. Inspect container bindings in the provider when overriding services.
• Pin the version and wrap it. Use a specific Composer constraint and isolate module calls behind your own service/interface so a future module upgrade or replacement does not leak into storefront code.
• Extension points to prefer: config files, service-container bindings, model extension, and events. Avoid editing vendor/; it will be overwritten and makes upgrades unsafe.