Event Laravel Package

Product Decisions This Supports

• Build vs. buy for extension points. If the product needs hookable behavior inside a template render pipeline (inject custom filters, directives, or pre/post-render steps), this package answers "do we build our own event bus?" with a "no." It is a small, MIT-licensed dispatcher scoped to Phug's lexer/parser/compiler/renderer lifecycle, so the decision becomes "wire listeners" rather than "design and maintain an internal pub/sub layer."
• Plugin/extension architecture on the roadmap. A priority-ordered listener model is the prerequisite for offering third parties (internal teams, agencies, marketplace vendors) a supported way to extend rendering without forking core. This is a roadmap enabler for a customization tier, white-labeling, or a partner integration surface.
• Observability and debugging features. Pipeline events give a natural seam for render-time telemetry: per-stage timing, slow-template detection, cache hit/miss instrumentation, and debug tracing. These are cheap to ship as listeners rather than as core patches — useful for internal tooling and a "why is this page slow" support workflow.
• Caching and invalidation strategy. Hooking compiler/renderer stages lets the product invalidate compiled-template caches on deploy, config change, or content-type switch without owning a bespoke mechanism. That is a reliability decision, not a feature decision, and it is easier to justify than a custom cache-busting subsystem.
• Risk containment for a low-adoption dependency. With 1 star and 0 dependents, the PM decision is not "standardize on this ecosystem." It is "use it where we are already committed to Phug, isolate it behind an internal interface, and keep the swap cost to one adapter class." The opportunity score (28.87) supports this framing: it is infrastructure, not differentiation.

When to Consider This Package

Adopt when:

• The product is already running Phug (or a Phug-based framework) and the team needs pipeline hooks that the engine does not expose natively.
• You need third-party or team-level extensibility without maintaining a fork — the listener/priority model is the lower-cost path.
• The requirement is internal tooling: instrumentation, tracing, cache control, dev-mode diagnostics. Low blast radius, high leverage.
• You can accept a single-maintainer, low-visibility dependency and can pin the version, vendor the source if needed, and wrap it in your own abstraction.
• MIT licensing and a small surface area matter more than community size or long-term support guarantees.

Look elsewhere when:

• The stack uses Twig, Blade, or Latte — those have first-class extension/event mechanisms; adding a Phug-adjacent dispatcher is pure overhead.
• You need a general-purpose, PSR-14-compliant event system across the whole application. Use Symfony EventDispatcher or League Event; do not let a template-engine-scoped dispatcher creep into domain events.
• You require vendor support, SLAs, or a large contributor base. One star and zero dependents is a credible signal that bug reports may be answered by you.
• The event surface is undocumented or unstable relative to your release cadence — verify the actual event names and payload contracts before committing, since the package's value is entirely in that contract.
• The need is a one-off hook. A single listener is not worth a dependency; a direct patch or a thin decorator may be simpler to own.

How to Pitch It (Stakeholders)

To executives: This is a small infrastructure dependency, not a product bet. It gives our rendering layer a supported way to be extended and instrumented — the plumbing behind customization, white-labeling, and performance visibility — at effectively zero licensing cost (MIT) and minimal code footprint. The honest caveat: it is a niche package with a single-maintainer profile, so we adopt it only inside our existing template engine choice and wrap it behind our own interface. If it stalls, we replace one adapter, not the product. Treat it as a "keep the extension door open" investment, sized accordingly.

To engineering: It is a priority-ordered event dispatcher bound to the Phug render lifecycle. We use it to attach listeners for instrumentation, cache invalidation, and custom directives instead of forking the engine. Constraint we accept: we pin the version, we own the upgrade testing, and we do not let these events become our application-wide event bus — domain events go through a separate, PSR-14 dispatcher. Success looks like new render-stage behavior shipping as listeners with no core patches.