Larasell Laravel Package

Getting Started

Larasell (larasell-dev/larasell) is a Laravel commerce package. As of v1.19.1 it ships without a bundled admin panel — that surface was removed in this patch release. Start from the package's service provider and config file after install:

composer require larasell-dev/larasell
php artisan vendor:publish --provider="Larasell\LarasellServiceProvider"

Then read, in this order:

1. config/larasell.php — the fastest map of what the package actually does in your app (routes, models, drivers, storage).
2. The published migrations — the real schema is the contract; models and relations follow from it.
3. The package's contracts/interfaces directory — these are the extension points you will bind against.

First use case: treat Larasell as the back-office domain layer (catalog, orders, line items, pricing) and build your own UI on top. Since v1.19.1 no longer gives you a free admin panel, the first milestone for a fresh install is a single authenticated CRUD screen (e.g. products) written against the package's models or, better, against its repository/service contracts. That exercise will tell you within an hour whether the package's abstractions fit your app or whether you should only adopt the schema and a subset of services.

If you were relying on the removed admin panel, stay on v1.19.0 until you have a replacement, and pin it exactly ("larasell-dev/larasell": "1.19.0").

Implementation Patterns

Wrap the package, don't scatter it. Create a thin application-level layer (app/Commerce/...) that depends on Larasell's contracts rather than its concrete classes. When a future release changes or removes a surface — as v1.19.1 just did — you edit one adapter instead of grepping your whole codebase.

Bind contracts in a dedicated provider. Register Larasell interface→implementation bindings in your own CommerceServiceProvider, not in AppServiceProvider. It keeps the package's footprint auditable and lets you swap implementations in tests.

Keep your own admin/UI namespace. The v1.19.1 removal is the lesson: never let your application's routes and views live inside a vendor package's panel. Own routes/web.php (or Filament/Nova resources) in your repo, calling package services. This is now the expected integration style, not just a preference.

Order/pricing flows: put multi-step operations (create order → add line items → apply totals → transition status) behind a single application service using DB transactions. Packages of this shape often expose granular model methods; composing them ad hoc in controllers is how you get partially-written orders.

Feature-test against the schema. Use RefreshDatabase with the package migrations and assert on your service layer, not the package's internals. This keeps your suite green across package upgrades.

Upgrade ritual. Because v1.19.1 is a patch release that removed a feature, adopt a hard rule: read the diff/changelog before any composer update, and upgrade patch versions in an isolated PR with the full test suite plus a smoke test of any UI you built.

Gotchas and Tips

• Semantic versioning is not being honoured for removals. v1.19.1 is a patch bump that deletes the admin panel — a breaking change. Pin the package (1.19.0 or 1.19.1 exactly, no ^) and treat every release note as potentially breaking. Consider composer.lock review as part of code review.
• Upgrading from 1.19.0 to 1.19.1 will silently break admin routes. Expect 404s rather than exceptions — Laravel will simply no longer have those routes registered. Grep your codebase for references to the package's admin route names, view namespaces (larasell::admin.*), and any published admin assets/config keys before upgrading.
• Leftover published assets/config. If you published the admin panel's views, assets, or config keys under 1.19.0, they will remain on disk after upgrading but be unreferenced. Remove them deliberately; stale config keys that the package no longer reads are a classic source of "why is my setting ignored?" confusion.
• Cache clearing after upgrade. Run php artisan route:clear && php artisan config:clear && php artisan view:clear (and optimize:clear in production deploys). Route/config caches from 1.19.0 will mask or mimic the removal and waste debugging time.
• Debugging extension points: if the package resolves services from the container, you can inspect the live binding with app()->getBindings() or php artisan tinker rather than reading vendor source. Overriding a binding is usually safer than forking.
• Don't fork to restore the admin panel. Pull the panel code from the v1.19.0 tag into your own app/ namespace if you truly need it, or migrate to Filament/Nova resources over the package's models. A fork puts you on a divergent upgrade path with no upstream fixes.
• Watch for follow-up releases. Feature removals are frequently followed by cleanup patches (dead config, orphaned migrations, doc changes). Check 1.19.2+ before investing in workarounds for 1.19.1.
• Ask upstream why. The commit is titled simply "remove admin panel" with no migration guidance. If you have a support channel, get a statement on the intended replacement before committing your team to an approach.