Notifications Laravel Package

Product Decisions This Supports

• Build vs. buy for module scaffolding: if the product is a suite of installable modules on the noerd core, this package is the reference implementation of the module contract. Adopting it avoids hand-rolling publish/install/update plumbing per module — a recurring cost multiplied by every module shipped.
• Upgrade-path reliability as a roadmap item: v0.1.2 moves module behavior out of handle() and into declared surfaces (getConfigFiles(), publishModuleExtras(), ensureModuleSetup()). This is directly a support-cost decision: what a module publishes becomes inspectable and reviewable rather than buried in imperative code, which shortens code review and incident triage for each module release.
• Backfill of existing installs: ensureModuleSetup() now runs on install and every update, so live customers receive setup entries they never got from earlier versions. This converts a class of "missing config after upgrade" support tickets into a self-healing path — but only if ensureModuleSetup() is written idempotently, which becomes a standing engineering standard the PM should enforce in module definition-of-done.
• Platform upgrade sequencing: pinning noerd/noerd to ^0.16.35 is a deliberate correctness fix (the prior open range could resolve to a core the module cannot run on), but it also means core and module releases are now coupled. Roadmap planning must treat core upgrades as a gating dependency for module upgrades, not an independent track.
• Use cases: internal module development on the noerd core; onboarding new engineers to a predictable module shape; auditing exactly what a given module writes to a customer installation.

When to Consider This Package

Adopt when:

• The product runs on noerd/noerd ^0.16.35 or newer. Older cores do not implement this contract; the package will not run there.
• You are developing or maintaining one or more installable modules and want a consistent, declarative install/update shape across them.
• You can absorb a coordinated release cadence — core version and module version move together, and downgrading the core is not a supported path.
• You accept pre-1.0 API churn. v0.1.x carries no stability guarantee; the contract itself changed materially in this patch release, so budget for rework.
• You value upgrade correctness for existing installations over setup-code flexibility.

Look elsewhere or defer when:

• You are pinned to an older core and cannot schedule the core upgrade alongside it.
• You need a stable, semver-guaranteed public API for third-party module authors.
• Your modules need bespoke install logic that genuinely cannot be expressed declaratively — the contract will fight you.
• You have a single deployment you control end-to-end, where hand-written install code is cheaper than conforming to a shared contract.

How to Pitch It (Stakeholders)

To executives: This release makes our add-on modules declare what they install instead of hard-coding it, and it repairs existing customer installations automatically on update. The practical effect is fewer upgrade-related support tickets, lower per-module maintenance cost as the module portfolio grows, and a more auditable picture of what any module changes in a customer environment. The tradeoff is that core and module upgrades must now ship together — a scheduling constraint, not a cost increase.

To engineering: v0.1.2 aligns us with the noerd 0.16.35 declarative module contract. getConfigFiles(), publishModuleExtras(), and ensureModuleSetup() replace imperative logic in handle(), and setup runs on install and every update — so treat ensureModuleSetup() as idempotent by requirement, not convention. The core requirement is tightened to ^0.16.35 because earlier cores lack the contract; do not attempt to relax it. Version is still 0.1.x, so expect further contract movement and keep module code thin against it.