Dystore Laravel Package

Product Decisions This Supports

• Build vs. buy for the commerce API layer. Dystore is an API-first (JSON:API) commerce backend on top of Lunar, so it answers the "do we hand-roll our own product/order/cart API or adopt one" question. This release strengthens the buy case by filling in standard storefront primitives rather than bespoke ones.
• Account lifecycle and compliance scope. The new "check if account exists" endpoint and "delete user" endpoint are the plumbing for signup flows, guest-to-account conversion, and GDPR/CCPA right-to-erasure. If account deletion was previously on the roadmap as custom work, it can be removed from the backlog.
• Passwordless / invitation-based onboarding. "Update registering users without password" unlocks magic-link, social-only, or admin-invited account creation. This is a product decision about onboarding friction and support burden, not just an engineering one — worth a deliberate call rather than letting it default.
• Merchandising and availability rules. Product and variant availability scopes let the storefront hide or surface items by stock/status without bespoke queries. This directly enables "hide out-of-stock," "show backorderable," and per-channel availability — common roadmap items that would otherwise be custom scope work.
• Navigation and catalog UX. Nested collection group filters on products support faceted and hierarchical category browsing. This is a roadmap accelerator for catalog discovery, mega-menus, and filtered listing pages.
• Reviews as a first-class commerce object. Adding the order relation to reviews connects feedback to verified purchases; the Filament admin fix (removing the published scope) is a moderation-workflow decision — moderators can now see unpublished/pending reviews. This matters for trust & safety staffing and SLAs.
• Platform upgrade planning. Dropping Laravel 11 and PHP 8.2 is a roadmap constraint: it forces a platform baseline decision (Laravel 12 / PHP 8.3+) and should be sequenced against other Laravel-dependent work.

When to Consider This Package

Adopt when:

• You are committed to Laravel + Lunar as your commerce foundation and want a ready-made headless API rather than building one.
• You need an API-first / headless storefront (SPA, mobile app, or multiple channels) and are comfortable with JSON:API conventions.
• Your team is small and you value shipping catalog, cart, order, account, and review endpoints over bespoke API design.
• You are already on, or can move to, Laravel 12+ and PHP 8.3+ — mandatory as of this release.
• You want Filament-based admin out of the box for catalog and review moderation.

Look elsewhere when:

• You are pinned to Laravel 11 or PHP 8.2. This release is a hard break, and staying on 1.0.14 means forgoing the new endpoints and filters — treat this as a forcing function, not an optional upgrade.
• You need a stable, slow-moving dependency. The package tracks Lunar 1.5.0-beta.x; a beta upstream means API churn and beta-grade risk on core commerce paths.
• Your domain is marketplace, multi-vendor, or B2B quote-to-cash — those need capabilities well beyond what these release notes indicate.
• You are not on Laravel/PHP, or your team cannot absorb JSON:API semantics.
• You need enterprise SLAs, vendor support contracts, or long-term support guarantees — this is a community package with a single visible maintainer committing across this release.

How to Pitch It (Stakeholders)

For executives: This release closes several gaps that would otherwise have been custom engineering — self-service account deletion (a compliance requirement), passwordless registration, storefront availability rules, and better catalog filtering. Those are direct reductions in build cost and time-to-market for the storefront. The trade-off is a platform baseline bump: the package now requires Laravel 12 and PHP 8.3+, so adopting version 1.0.15 means committing to that upgrade. That is a one-time infrastructure cost we should schedule deliberately rather than absorb accidentally. Overall risk is moderate: the package sits on a beta version of Lunar, so we should expect upstream churn and budget maintenance time accordingly.

For engineering: Upgrade path is clear and this release is worth taking — the new endpoints, availability scopes, and nested collection filters replace work we would otherwise own. Be explicit that 1.0.15 drops Laravel 11 and PHP 8.2; the PHP/Laravel bump must land first or in the same change. Also note the dependency now pins Lunar 1.5.0-beta.6 — review release notes for that beta before merging, and pin versions rather than floating. The reviews admin fix removes a published scope so unpublished reviews appear in Filament; confirm that is the intended moderation behavior before rollout.

Recommendation: Adopt 1.0.15, paired with a scheduled Laravel 12 / PHP 8.3 upgrade. Do not delay past the next sprint — staying on 1.0.14 accumulates drift against Lunar's beta line and forfeits the compliance and onboarding features above.