Product Decisions This Supports
- Build vs. buy — reframed as an ownership question. The package is ~100 lines of glue that hooks closure callbacks onto a Nova resource's create/update/delete lifecycle. As a vendor decision it's noise; as an ownership decision — "who owns post-save behavior in our admin write path?" — it's a real roadmap input. The evidence (20 stars, zero dependents, single maintainer, no release since June 2022) makes the PM's job to force the question, not to approve the composer require.
- Scoping the recurring admin ask: "when an admin saves this record, also do X." Notify the account manager, sync to CRM, write an audit row, bust a cache, enqueue a job. Nearly every internal admin tool accumulates these. This package gives the requirement a concrete, demoable shape in an afternoon, which is far cheaper than commissioning an eventing design before the need is validated.
- Deciding where admin-only side effects live. Three candidates: model observers (framework), Nova resource classes (presentation), domain events/services (application). Adopting this is an implicit vote for the presentation layer. That's right when the behavior should fire only when a human clicks save in Nova, and wrong for anything the API, console, or CSV import must also honor. Make the distinction explicit early and you avoid a whole class of "why didn't this fire?" tickets.
- De-risking a roadmap item with a throwaway spike.
composer require plus one method on a resource class — no migrations, no config, no assets. Small blast radius makes it viable as proof-of-concept tooling: prove the workflow, then reimplement deliberately instead of adopting by inertia.
- Tech-debt triage with a scheduled exit. If it's already in the codebase, the finding is the maintenance signal, not a feature gap. That justifies putting removal/inlining on the next Nova upgrade rather than patching around it.
- Capacity and cost honesty. The real cost isn't the dependency — it's the paid, closed-source Nova license (CI needs
NOVA_USERNAME/NOVA_PASSWORD) plus enablement: deciding the callback-vs-observer convention, writing canary tests, and adding a Nova-upgrade runbook entry with a named owner. Budget enablement effort, not a spike.
When to Consider This Package
Consider it when:
- You're pinned to a Nova version contemporary with the 2022 release, it resolves cleanly, and a failing test proves callbacks still fire.
- The side effects are genuinely admin-panel-scoped — they should fire on a Nova save and nowhere else — so co-locating them with the resource is semantically correct, not just convenient.
- You need a demo or spike and want to skip boilerplate.
- The team already vendors small MIT glue packages and is prepared to fork.
Look elsewhere, or write it yourself, when:
- Maintenance risk is unacceptable. No release in ~3 years, no downstream users, no community backpressure. A Nova major will likely break it and nobody upstream will fix it — and because it sits in the admin write path, breakage shows up as silently missing side effects on production writes, not a failed build.
- The logic must be authoritative. Callbacks are invisible to API, console, and import paths. Business rules belong in model events, domain events, or services.
- You need transactional or failure guarantees. Callbacks run in-request after the write: the record persists, the side effect throws, the user sees a 500, retries, and duplicates the effect. No queue integration, no logging, no retry, no idempotency guard.
- Bulk paths matter. Nova Actions, Lenses, and CSV imports bypass resource
store/update, so callbacks almost certainly won't fire — producing product-visible inconsistency depending on how the row was created.
- Nova core already ships equivalent lifecycle hooks on your version. Verify before adding a dependency that duplicates a first-party feature.
- Other Nova extensions already wrap
store/update (redirects, tabs, action styling). Trait-ordering collisions are not something you want to debug from a support ticket.
Gating questions before commitment: which Nova majors composer.json permits and whether it resolves against your pin; whether callbacks fire on create, update, both, and for inline-created related records; whether the write plus callbacks are transactional; and whether the API is stable enough to hide behind an interface. Pin those semantics with a failing test before adoption.
How to Pitch It (Stakeholders)
To executives: A small MIT-licensed helper that attaches "after save" behavior to admin screens. Strategic value is low and the risk is contained — but not zero. It lives in the admin write path, and with no release in three years and zero downstream users, we'd be the only ones who notice when it breaks on a Nova upgrade. Recommendation: don't adopt it as a dependency. The capability is small enough to own in-house, and replicating it costs hours, not sprints.
To engineering: It solves a real ergonomics problem — post-save side effects declared next to the Nova resource instead of scattered across observers and controllers. Use it as a reference implementation and spike tool, then port the pattern into a first-party trait we control. Keep it off critical paths. If adopted in the interim: put it behind an AfterSaveAction interface so exit is a one-file change, pin both Nova and Laravel majors, treat every Nova upgrade as a breaking change requiring re-validation of each registered callback, keep callback bodies to a single dispatch() (the queue gives retries and failed_jobs for free), make them idempotent, and enforce in code review that the callback never carries a business rule a non-admin code path also needs.