Product Decisions This Supports
- Extensibility roadmap: whether to ship a plugin/hook layer at all, and how deep it goes (simple filter chains vs. full plugin lifecycle with registration, discovery, and sandboxing). This package only addresses the dispatch/registration primitive — deciding that is a scoping decision, not a dependency decision.
- Build vs. buy for a commodity primitive: a filter/hook dispatcher is roughly a few hundred lines of code. Adopting this package is a decision to not spend engineering days on that primitive, not a decision to outsource a capability. Frame it as a spike-level build/buy call, not an architecture commitment.
- Customization strategy for enterprise/self-hosted customers: filter points let you expose behavior overrides (pricing rules, output transforms, validation pipelines) without forking core or adding customer-specific branches. This directly affects support cost and release cadence.
- Third-party integration surface: if you plan to let partners or internal teams extend the product, filters are the cheapest contract to publish. The decision here is whether the contract is "callables registered by key" (this package's model) or typed interfaces/events (Laravel-native).
- Use cases that fit today: request/response transformation pipelines, content or template filter chains, normalization/validation sequences, configurable rule evaluation, feature-flag-style behavior toggles. All synchronous, in-process, low-ceremony.
- Migration and lock-in posture: because it is framework-agnostic and tiny, it can sit behind an internal
HookRegistry interface in a day, making the adoption reversible. That reversibility is the main product-relevant property.
When to Consider This Package
Consider it when:
- You are building a plugin or extension system and want a minimal, MIT-licensed, dependency-free filter primitive rather than inventing one.
- You want to prototype the shape of your extension API (registration, priority/ordering, chaining) before committing to a public contract.
- You are on plain PHP or a non-Laravel framework and Laravel's
Event/Pipeline components are unavailable.
- You accept owning the code: forking, adding tests, pinning a commit, and treating the upstream as a reference rather than a maintained dependency.
Look elsewhere when:
- You are on Laravel. Native Events/Listeners and Pipeline already cover hook dispatch, come with container injection, queuing, testing helpers, and a support contract. Adding a parallel mechanism creates two extension idioms in one codebase.
- You need typed contracts, async/queued filters, observability, or per-filter authorization — none of which a bare filter registry provides.
- You require a maintained dependency: 0 stars, 0 dependents, no visible release cadence or community means no security response, no API stability guarantee, and no support path. A single unmaintained transitive dependency is a poor foundation for a public plugin API.
- Third-party code will be executed through the filter points. Sandboxing, capability limits, and review process are your responsibility regardless of package — budget for them explicitly.
- You need Laravel service-provider auto-registration, config publishing, or facade ergonomics; you would be writing that integration layer yourself.
Recommended posture: vendor or fork it behind an internal interface, or reimplement the ~1-day version in-house with your own tests. Do not expose it directly as your public extension contract.
How to Pitch It (Stakeholders)
For executives: This is a small, permissively licensed (MIT) utility for building plugin-style extension points. Cost is effectively zero and it introduces no vendor lock-in. However, it has no adoption, no community, and no maintenance signal — so it should be treated as a reference implementation and prototyping aid, not a strategic dependency. Recommendation: fund a short internal spike (1–2 days) to validate the extension-API shape; do not put it on a critical path or in a customer-facing contract without an internal fork and test suite. The real decision being made is whether we offer extensibility at all, which is a roadmap question worth more than the package itself.
For engineering: Tiny, framework-agnostic filter registry — registration and dispatch, no magic. Wrap it behind an internal HookRegistry interface so it is swappable in an afternoon. On Laravel, justify why native Events/Pipeline are insufficient before adopting; otherwise you create a second, competing extension mechanism. If we proceed, we own it: pin a commit, add tests, document the contract, and plan a path to replace it.