Weave Code
Notifications Laravel Package
noerd/notifications
Laravel package for adding notification features to PHP applications. It builds on Laravel's notification system to help you send, store, and manage user alerts, keeping notification logic organized and easy to integrate into existing models and workflows.
In-app notifications for the noerd framework: a bell in the top bar with an unread badge, and one API every module sends through — a service call or a Laravel notification channel
Frequently asked questions about Notifications
- What is noerd/notifications and what does it do?
- It is a Laravel package that adds in-app notifications to applications built on the noerd framework. It provides a bell in the top bar with an unread badge, plus a single API that every module sends through, either as a service call or a Laravel notification channel. It builds on Laravel's existing notification system rather than replacing it, so sending, storing, and managing user alerts stays organized and integrates with your existing models and workflows.
- How do I install noerd/notifications?
- Install it with Composer alongside the noerd core, then run the package's Artisan install command to register the module and publish its configuration. Configuration is published through Laravel's standard publishing mechanism, so artifacts land where you expect them. Because both this package and the core are pre-1.0, pin exact versions in composer.json rather than relying on caret ranges resolving safely across a moving module contract.
- What Laravel, PHP, and noerd core versions does it require?
- You need PHP and Laravel versions acceptable to both this package and noerd/noerd, plus a core at or above ^0.16.35. That floor was tightened in v0.1.2: the previous constraint was open and could resolve to a core this package cannot run on. Audit composer.lock across every environment, since an installation created before v0.1.2 may be sitting on an unsupported core and will now be Composer-unresolvable until the core is upgraded.
- How do modules send a notification?
- Every module goes through one API, either a direct service call or a Laravel notification channel. That keeps send logic consistent across modules instead of each one inventing its own alert plumbing. Because it sits on top of Laravel's notification system, you keep the usual channels, notifiable models, and queue behavior you already know.
- Does it include the bell UI and unread badge?
- Yes. The package renders a bell in the top bar with an unread badge, so users see at a glance that something needs their attention. The module provides the notification entry point and the UI affordance; the surrounding top bar and layout belong to the host application built on the noerd framework.
- How do I publish and customize the configuration?
- Configuration is declared through the module by getConfigFiles() and publishModuleExtras(), and the core decides when and how to apply it. In practice you publish through Laravel's normal config publishing flow and then adjust the published files. Declarative registration replaced the older imperative approach in v0.1.2, which removes drift between install-time and update-time behavior.
- Is ensureModuleSetup() idempotent, and what happens when I run the update command?
- Starting with v0.1.2, ensureModuleSetup() runs on every update, not just at install, so an existing installation will receive setup entries it never had before. The release notes do not document an idempotency guarantee, so treat the first update as a potentially data-mutating event: run it in staging first and confirm it does not duplicate rows, rewrite config, or re-trigger side effects. Also check what happens if config publishing and setup partially fail between the two steps, and have a rollback plan before touching production.
- Can I use it as a plain Laravel package without the noerd framework?
- No. This is not a standalone library; it is a module that plugs into a host application (noerd/noerd) and conforms to that host's module contract. If you are on vanilla Laravel without the noerd core, it is not a drop-in, and your integration surface is effectively the contract version rather than the package's public API.
- How do I upgrade from an older version safely?
- Treat it as a two-step deploy, not one. First upgrade noerd/noerd to ^0.16.35 and validate the host application independently of this package, then upgrade noerd/notifications to v0.1.2 and run the update command. Inverting the order fails dependency resolution, and forcing it would run the new module against a core it cannot run on. Record the tightened constraint as a de facto breaking change in your changelog even though no API changed.
- Is it production-ready, and does it require queues or extra infrastructure?
- The stack fit is conventional: Composer for distribution, Artisan for lifecycle, and Laravel config publishing for artifacts, with no new runtime dependencies. In-app delivery to the bell does not require a queue or worker, though if you route through queued Laravel notification channels the usual queue rules apply. The real production caveats are pre-1.0 status on both sides, a hard floor tied to the core's release cadence, and an update path whose idempotency is undocumented, so pin exact versions, upgrade deliberately, and test updates in staging.
Weaver
How can I help you explore Laravel packages today?