Hooks Laravel Package

Product Decisions This Supports

• Build vs. buy on an extensibility layer. Every non-trivial Laravel product eventually needs a way for modules, client-specific packages, or a partner integration to change behavior without editing core code. This package is a ready-made implementation of that seam (named actions + filters with priorities). The decision it informs: do we spend 1–2 sprints designing an internal event/filter contract, or adopt an MIT-licensed one and spend that time on features?
• Plugin / add-on ecosystem as a product surface. If the roadmap includes third-party extensions, a marketplace, or "bring your own module," you need stable, documented extension points. WordPress-style actions/filters are the most widely understood mental model for that, which lowers the barrier for external developers who are not Laravel specialists.
• White-label and per-client customization. Filters (applyFilters on price, title, summary, tax labels) let you satisfy "Client A wants prices formatted differently" and "Client B wants a different checkout summary" through configuration and small packages instead of forked codebases. This is a direct lever on support cost and release-velocity per client.
• Modular monolith decoupling. Instead of core code hard-calling optional modules (or vice versa), core fires order.placed and modules subscribe. This supports a roadmap where features can be added, removed, or feature-flagged per plan tier without touching the billing or checkout path.
• Lifecycle instrumentation without core edits. Actions at order.placed, user.registered, view.rendering give product/analytics/ops teams hook points for logging, notifications, and experiments that don't require core-team PRs.
• De-risking a future rewrite. A filter layer around display and pricing logic creates an explicit contract boundary — useful leverage if the roadmap includes replacing a subsystem later, since the boundary tells you what must stay behavior-compatible.

When to Consider This Package

Consider it when:

• You're on Laravel 10/11 and PHP 8.2+, with a genuinely modular codebase or a planned plugin/extension story.
• Multiple teams, packages, or client-specific deployments need to inject behavior into shared code paths.
• You want the WordPress extension model specifically — for developer familiarity, documentation, or because your extension authors are plugin developers rather than Laravel engineers.
• You need synchronous, in-process extensibility only, and the hook surface is on low-to-moderate traffic paths (checkout confirmation, view rendering, admin pages) rather than per-request hot loops.
• You're prepared to treat it as an owned dependency: pin a version, wrap it behind an internal Hooks interface or facade of your own, and be ready to fork. With zero stars, zero dependents, and a single-maintainer release cadence, that posture is non-negotiable.
• You need small, cheap conveniences: priority ordering, callback removal (added in 1.1.0), Blade directives for theme-level customization.

Look elsewhere when:

• Laravel's native events/listeners and Pipeline already cover it. If you want async dispatch, queued listeners, retries, or per-event subscriber discovery, native events win out of the box; this package is synchronous and adds no queueing.
• You need type-safe, statically-analyzable extension contracts. String-named hooks ('order.placed') mean typos fail silently at runtime and IDEs can't follow the call graph. If your team leans on static analysis, an interface- or enum-based approach is safer.
• Performance is on the critical path. Hook dispatch is indirection per call; fine for view and lifecycle events, wrong for a loop over 10k rows.
• Observability matters and you don't want to build it. Hook chains are hard to trace in stack traces and APM; you'll want logging or tracing around dispatch and this package won't provide it.
• Procurement, security review, or an SLA is involved. Zero dependents means no battle-testing signal, no third-party security track record, and no commercial support. For regulated or enterprise-sold products, the burden of "why this dependency?" will land on you.
• You only need one or two extension points. Two hooks is a design pattern, not a dependency — a handful of Laravel events will do it with less surface area.

Adoption shape I'd recommend: pilot in a non-critical path (admin rendering or notification hooks), instrument dispatch, and gate promotion to core paths (pricing, checkout) behind a proven track record on your own codebase.

How to Pitch It (Stakeholders)

For executives (one paragraph): We have a recurring cost: every client-specific or module-specific change to shared code requires branching or a core team PR, which slows releases and multiplies maintenance. This is a small, MIT-licensed library that gives us a standard way for modules and client packages to plug into our application without touching core files — the same extension model WordPress has used for two decades. Cost of adoption is low (a Composer dependency, a day or two of integration, roughly one engineer-week including tests and a fallback wrapper). The strategic upside is that it makes a plugin/add-on ecosystem and per-client white-labeling feasible, and it lets us sell customization without forking the product. The risk is that it's a young, single-maintainer package with no visible adoption; we mitigate that by pinning the version, hiding it behind our own internal interface so we can swap or fork it later, and piloting it on a non-critical surface first. Net: a cheap option on a capability we will need regardless, with a contained and reversible downside.

For engineering (the honest version): It's a thin, well-documented WordPress-style hooks system — addAction / doAction, addFilter / applyFilters, priority ordering (lower first, insertion order within a priority), removal APIs since 1.1.0, Action/Filter facades, and @action / @filter Blade directives. Auto-discovery means no config/app.php edits. It's PHP 8.2+, tested on Laravel 10/11, Pest test suite, Pint-formatted, and it ships Laravel Boost AI guidelines. What it does not give you: static typing on hook names, async/queued dispatch, tracing, or any community to answer questions. So: treat hook names as a public API and document them, wrap the helper functions in our own service so a future replacement is a one-file change, add a debug listener that logs every dispatch in non-production, and don't put it in a loop that runs per row. If we find we only need a couple of extension points, use Laravel events instead and skip the dependency.