Dystore Laravel Package

Technical Evaluation

What shipped (1.0.15)

• API surface expansion: GET account-exists check, DELETE user endpoint, and registration without a password. These are auth/identity changes, not just commerce features — they widen the package's blast radius into security-sensitive territory.
• Domain model change: reviews now relates to orders, implying a new nullable FK and a migration, plus a change in how reviews are attributed and displayed.
• Query layer additions: product/variant availability scopes and nested collection-group filters on products. These are query-builder contracts that downstream code and API consumers will build on.
• Admin fix: Filament reviews listing no longer applies PublishedScope — behavior change for store admins (unpublished reviews now visible).
• Dependency bumps: Lunar 1.5.0-beta.6, Pest ^4.0.
• Breaking: Laravel 11 and PHP 8.2 support dropped.

Architecture fit

• Still a Laravel package layered on Lunar; auto-discovered service provider, publishable config/migrations, Filament panel resources. Fits a monolith or modular Laravel commerce app that has already accepted Lunar as its commerce core.
• The new auth endpoints and passwordless registration suggest the package is drifting from "store domain module" toward "storefront + customer account backend." That is fine if you want it, but it means it now owns identity flows you may already own elsewhere (Breeze/Jetstream/Fortify, SSO, external IdP). Overlap is the primary architectural question.

Integration feasibility

• Mechanically low-friction: composer require, publish assets, run migrations. No new infrastructure.
• Real friction is version gating: the drop of Laravel 11 / PHP 8.2 in a patch-level release means an app on L11 or PHP 8.2 cannot take this update at all, and any transitive constraint resolution will block it. Check composer why-not before planning.

Technical risk

• SemVer governance (high): removing platform support in 1.0.15 is a breaking change inside a patch bump. Treat every 1.0.x as potentially breaking and pin exact versions with a lockfile; do not use ^1.0.
• Beta upstream (high): pinning to Lunar 1.5.0-beta.6 puts a production commerce data layer on a pre-release dependency. Upstream schema/behavior churn is outside your control.
• User enumeration (medium): an account-exists endpoint is a classic enumeration vector. Needs rate limiting, generic responses, and CSRF/auth scoping before exposure.
• Destructive endpoint (medium): DELETE user needs explicit policy: hard vs soft delete, order/invoice retention for tax and accounting, review anonymization (a review with an order relation now carries PII linkage), and cascade behavior across Lunar tables.
• Passwordless registration (medium): changes the account lifecycle and recovery story; interacts with whatever verification/reset flow you already run.
• Schema migration (medium): the review→order relation needs a nullable FK plus a backfill strategy; existing reviews will have no order.
• Admin visibility change (low): unpublished reviews appearing in Filament may surprise merchandisers, and draft/abusive content becomes visible to staff who previously didn't see it.

Key questions

1. Is 1.0.x intended as SemVer-stable, or should consumers pin exact versions? Will future platform drops land in patch releases?
2. What is the GA timeline for Lunar 1.5.x, and is beta.6 API-frozen?
3. Is DELETE user soft or hard? Does it preserve order/invoice history for tax retention?
4. Is the account-exists endpoint rate-limited and non-enumerable by default, or is that the integrator's job?
5. Is the review→order relation nullable and backfillable, and does it change the public review API payload?
6. Does "registration without password" replace or augment the existing flow? Does it emit verification email and support password reset?
7. Minimum supported matrix after this release — Laravel 12.x only? Which PHP 8.3/8.4 minors are tested in CI?

Integration Approach

Stack fit

• Target state: PHP 8.3+, Laravel 12.x, Lunar 1.5.x, Filament admin, Pest 4 test suite upstream. Anything below that cannot consume 1.0.15.
• Best fit is a greenfield or recently-upgraded Laravel commerce app that already uses Lunar and does not have a competing identity layer.

Migration path

1. Decide now, per environment: if any production service is on Laravel 11 or PHP 8.2, stay on 1.0.14 and pin it exactly; do not float.
2. For services already on L12/PHP 8.3: upgrade path is PHP 8.3 → Laravel 12 → Lunar 1.5.0-beta.6 → dystore 1.0.15, in that order, each step independently verifiable.
3. Budget for the Lunar beta step as the long pole — it is a data-layer upgrade, not a dependency refresh. Run it against a production-shaped database snapshot.
4. Publish and review migrations before running: confirm the review↔order FK is nullable and that backfill of historical reviews is handled or explicitly acceptable.

Compatibility

• Audit composer.json constraints and any first-party packages that pin Lunar 1.4.x or Laravel 11 — those are hard blockers, not warnings.
• Check Filament version alignment with the Lunar 1.5 line; admin panel breakage is the most common upgrade casualty here.

Sequencing

1. Pin current version and record the baseline.
2. Upgrade PHP and Laravel in a branch; run existing test suite.
3. Upgrade Lunar to 1.5.0-beta.6; re-run migrations on a snapshot; verify catalog, cart, checkout, order flows.
4. Adopt dystore 1.0.15.
5. Verify Filament admin: reviews listing (published scope removed), order-linked reviews rendering.
6. Gate the new HTTP surface: account-exists, delete-user, passwordless registration — implement rate limiting, authorization policies, and enumeration-safe responses before enabling routes.
7. Adopt availability scopes and nested collection-group filters in application queries only after confirming index coverage and response-time parity.
8. Ship behind a feature flag; canary a small traffic slice.

Operational Impact

Maintenance

• This package tracks Lunar closely and releases frequently; expect to upgrade roughly in lockstep with Lunar. Reserve recurring capacity each Lunar release, not a one-off migration budget.
• Pin exact versions. Given platform drops in patch releases, "stay current" is a deliberate, scheduled activity rather than a passive composer update.
• Maintain a fork-or-patch escape hatch: the package is small and single-maintainer-driven, so the ability to vendor a fix matters.

Support

• Bus-factor risk: changelog shows one dominant contributor. There is no vendor SLA, LTS branch, or security-response commitment. Plan internal ownership of the code path.
• Upstream support burden concentrates on Lunar; dystore issues will often resolve to "wait for Lunar." Establish a triage rule for that.

Scaling

• Availability scopes and nested filters are a net positive for catalog read paths, but nested collection-group filtering can generate deep whereHas/join chains. Load-test product listing under realistic category depth and collection nesting; watch for missing composite indexes on availability + collection pivot columns.
• Reviews→orders adds a join to review listing queries; verify the admin reviews page and storefront review endpoints at expected volume.
• New auth endpoints are cheap individually but are unauthenticated by nature — they are a rate-limiting and abuse-surface concern more than a throughput one.

Failure modes

• Locked out of upgrades entirely by the Laravel 11 / PHP 8.2 drop while other dependencies block the L12 move.
• Lunar beta regression breaking catalog or checkout after a routine upgrade.
• User enumeration or account-deletion abuse if the new endpoints ship with default middleware.
• Orphaned or PII-bearing reviews after account deletion; accounting/tax gaps if orders are cascaded away.
• Merchandisers confused or exposed to unreviewed content when PublishedScope was removed from the Filament listing.
• Silent breakage of API consumers if the review payload shape changed with the order relation.

Ramp-up

• Engineers need Laravel 12, Filament, and Lunar domain familiarity; Lunar's data model (products, variants, collections, orders) is the real learning curve, not this package.
• Estimate roughly 1–2 weeks for a mid-level Laravel engineer to be productive on catalog/order work, plus dedicated security review time for the new auth endpoints — that work should be owned by someone with an application-security background, not learned on the job.
• Produce a short internal runbook: pinned version, upgrade order (PHP → Laravel → Lunar → dystore), migration commands, feature flags, and the rollback point (1.0.14).