Getting Started

Install with composer require dystcz/dystore-product-notifications, then publish and run the migrations/config (php artisan vendor:publish --tag="dystore-product-notifications-config" and ...-migrations, followed by php artisan migrate). The package builds on Dystore/Lunar, so a working Dystore store (products, variants, stock, customers) is a prerequisite.
Look first at: the published config (channel/queue/notification class bindings), the migrations (the subscription/"notify me" table and its unique constraints), the notification classes (mail/database payloads), and the service provider bindings that let you swap implementations.
The canonical first use case: a customer lands on an out-of-stock product/variant and subscribes to be notified; when stock is replenished, the package dispatches a queued notification. Wire the subscribe action to your product page form, update stock through the normal Lunar Stock model, and verify a notification lands in Notifications/Mailhog.
This release (1.0.15) is a patch bump with only a compare link — no documented breaking changes, new features, or deprecations. Start on ^1.0 and treat the prior 1.0.x behavior as the baseline.

Implementation Patterns

Storefront subscription endpoint: validate the product/variant ID, normalize the email, and rely on the package's uniqueness constraint (email + product/variant) to make the "Notify me" button idempotent. Return a generic success response so you don't leak stock/subscriber data.
Stock-triggered dispatch: trigger notifications from stock replenishment rather than from product saves. Update inventory through Lunar's Stock model/actions so the package's observers/events fire; a raw DB::table('...')->update() will silently skip notifications.
Queue everything: notifications should implement ShouldQueue; set a dedicated queue (e.g. notifications) in config and run workers. This is the difference between a working feature and a request-timeout bug when a popular product restocks.
Overriding behavior: swap the notification class or channel strategy via the config/container binding rather than forking. Keep your own subscriber-facing controller thin and delegate to the package actions so upgrades stay cheap.
Unsubscribe flow: store a signed URL/token per subscription and expose an unsubscribe route. This doubles as your compliance path for marketing-adjacent email.
Testing: use Notification::fake() and assert assertSentTo/assertSentOnDemand; create subscriptions via factories, then move stock and assert dispatch. Add a test that a second restock does not re-notify already-notified subscribers.

Silent no-send: nine times out of ten the cause is a missing queue worker, a cached config pointing at the wrong channel, or stock updated outside the model layer. Check php artisan queue:work logs and failed_jobs first.
Duplicate sends: restocks often happen in multiple increments. Guard with a notified_at/status column and only notify on the transition from zero/out-of-stock to in-stock.
Migration ordering: run Dystore/Lunar migrations before this package's migrations; a fresh-install ordering mismatch produces foreign key errors on the subscription table.
Config caching: after changing channels, queue, or notification classes, run php artisan config:clear/config:cache — stale cached config is a common "my override isn't used" trap.
Localization: notification copy usually lives in translation files; publish/override them and set the recipient's locale before dispatch if you support multiple locales.
Extension points: prefer config + container bindings + events over subclassing package internals; internals are the most likely thing to shift in a 1.0.x patch.
Upgrade check: 1.0.15 ships no release notes beyond the diff. Pin ^1.0, run your notification tests after bumping, and skim the GitHub compare for the 1.0.14→1.0.15 diff before deploying to production.