Hooks Laravel Package

Technical Evaluation

Recommendation: conditional adopt — small, low-cost, high-ecosystem-risk. The code surface is tiny and MIT-licensed, so the technical downside of trying it is low; the strategic downside is that you are re-implementing a capability Laravel already ships and taking a dependency on a package with effectively zero adoption (0 stars, 0 dependents, single maintainer).

Architecture fit

• Overlaps with Illuminate\Events\Dispatcher. Laravel events already give you named events, listener registration, subscribers, queued listeners, wildcard listeners, and (via a custom dispatcher) priority. The package's genuine value-add over native events is the filter primitive — a value threaded through an ordered callback chain — which Laravel only approximates with Illuminate\Pipeline\Pipeline.
• The "actions" half is a service-locator-style extension point. That is defensible for modular/plugin ecosystems (you want third parties to attach behavior you never enumerated), but it is an anti-pattern for intra-application decoupling where normal events or explicit interfaces are clearer and statically analyzable.
• Helper functions (addAction, doAction, applyFilters, …) are declared as global functions. In a large codebase this is a namespace-pollution and collision risk, and it hurts IDE/static-analysis discoverability compared to facades or injected services.
• Facade aliases Action and Filter are registered globally and are extremely generic names — meaningful collision risk with existing app facades, test helpers, or future framework additions.

Integration feasibility

• Low effort. Composer install, auto-discovery registers HooksServiceProvider, BladeDirectiveServiceProvider, and the two aliases. No config/app.php edits. A pilot can be stood up in under a day.
• Real blocker to sequence first: the package has no hook registry or discovery command. Laravel gives you artisan event:list; here a typo in a hook string is a silent no-op in production. Any adoption must be paired with an app-side naming convention, a constants/enum file for hook names, and tests asserting each documented hook has at least one listener.

Technical risk

• Escaping / XSS: @filter(...) echoes the filter result directly. If a filter ever returns user-influenced content, the Blade directive bypasses {{ }} escaping. This is the highest-severity technical risk and needs a documented rule: only use @filter for trusted, developer-controlled output.
• No failure isolation: callbacks execute in the caller's stack. An exception inside a listener propagates and breaks the originating request/job unless each callback author wraps its own work. There is no documented try/catch, timeout, or "listener failed but action completed" semantics.
• Recursion: a callback that dispatches the same hook re-enters unbounded. No re-entrancy guard is documented.
• Closure removal gotcha: removeAction/removeFilter compare callables, so anonymously-constructed closures (fn() => ... passed inline) cannot be removed later. 1.1.0 added removal APIs, but the ergonomics require holding a variable reference — a support-ticket generator.
• Version/test-matrix skew: requirements state PHP 8.2+, while CI was standardized on PHP 8.4. The claimed lower bound is effectively untested.
• Metadata oddity: last release dated 2026-07-20. Treat release provenance and tag integrity as something to verify before pinning.

Key questions

1. What is our actual use case — third-party/plugin extension, or internal modularity? If internal, why not native events + pipeline?
2. Who owns the hook namespace convention, and what prevents typo-silent-failure?
3. Do we accept synchronous, non-isolated execution, or do we mandate that callbacks dispatch queued jobs?
4. Are we prepared to fork and vendor this if the maintainer disappears? (Cost is low; is it budgeted?)
5. Have we validated the Action/Filter alias names against our existing codebase?

Integration Approach

Stack fit

• Laravel 10.x/11.x is the tested envelope; PHP 8.2+ required. Confirm Laravel 12 behavior explicitly before committing — the README does not claim it.
• Best fit is a modular monolith or a package/plugin surface where you deliberately expose extension points. Poor fit for a conventional CRUD app with an existing event-driven architecture.

Migration path

• Do not migrate existing Event::dispatch / listeners. Rewriting working event code to hooks buys nothing and loses queueing, wildcards, and event:list.
• Apply hooks only to new extension points you are deliberately publishing, and treat the hook name strings as a public API contract (version them, document them in a HOOKS.md).
• Wrap the package behind a thin internal service — e.g. App\Support\Hooks — that delegates to Action/Filter. This costs ~50 lines and makes a future swap to native events, Pipeline, or a fork a one-file change.

Compatibility

• Resolve the facade alias collision question in staging before rollout; check config/app.php aliases and any class_alias usage.
• Verify the package's facade binding resolves under Octane if you use it — singletons holding registered callbacks must be safe for long-lived workers (they are read-mostly, but confirm no request-scoped state leaks).
• Add it as a direct dependency with a pinned minor (^1.2) and commit composer.lock; do not float.

Sequencing

1. Week 1 — spike: install in a branch, wire one action and one filter in a non-critical path, write the escaping and exception-isolation guidelines, measure nothing (overhead is negligible).
2. Week 2 — guardrails: internal wrapper service, hook-name constants, HOOKS.md, a test that asserts every declared hook has at least one listener, and a Pint rule set.
3. Week 3+ — pilot: one real extension point in a single module. Instrument for errors attributable to callbacks.
4. Decision gate: only after the pilot, decide whether to expand, fork-and-vendor, or revert.

Operational Impact

Maintenance

• Bus factor 1. Zero stars and zero dependents means no downstream users are pressure-testing releases. Budget for fork-and-vendor as the default contingency — the package is small enough (two service providers, two classes, helpers, Blade directives) that a fork is a day of work, not a quarter. Mirror the repo internally.
• Dependency surface is small (Illuminate/Support, Symfony transitively), so CVE exposure via this package is low and inherits mostly from Laravel itself.

Support

• No community, no commercial support, no Stack Overflow corpus. Every "how do I…" becomes an internal answer that you must write down. That documentation cost is the real operational expense here, not the package.

Scaling

• Execution is in-process and synchronous. Under load, a slow callback directly inflates request latency — enforce a rule that callbacks do bounded work and delegate to queued jobs.
• Callback registration cost is trivial; no caching/compilation needed. No horizontal-scaling concerns beyond normal Octane caveats.

Failure modes to plan for

• Silent no-op from a misspelled hook name (highest frequency, hardest to detect) → mitigate with constants + coverage test.
• Callback exception aborting the originating request or job → mitigate with per-callback try/catch convention and error reporting.
• Infinite recursion when a callback re-dispatches its own hook → mitigate with a documented prohibition and a depth guard in the wrapper.
• Unescaped output via @filter in Blade → mitigate with a written policy limiting @filter to trusted values.
• Undetachable inline closures → mitigate by requiring named callables or stored variables for anything removable.

Ramp-up

• Very low: a competent Laravel developer is productive in 2–4 hours given the README. The facades and helpers are familiar, and WordPress-style hooks are widely understood.
• The non-obvious learning is not the API but the discipline: naming conventions, escaping rules, exception isolation, and removal ergonomics. Put those in the team's contribution guide or they will be relearned painfully per developer.