- What is webman/event and how does it work?
- webman/event is a small plugin that adds a config-driven event dispatcher to the webman framework. You map event names to listener classes in a configuration file, then dispatch events from controllers, services, or middleware. It is a thin utility whose purpose is decoupling components and adding hooks inside a webman application. It is not a standalone PSR-14 event bus and not a Laravel package.
- Is webman/event a Laravel package?
- No. It is a plugin for webman, the Workerman/EventLoop-based long-running PHP application server, and its integration point is the webman plugin bootstrap rather than a Laravel service provider. Laravel already ships Illuminate\Events\Dispatcher with service-provider registration, queued listeners, and model events. Pulling this package into a Laravel app would mean rewriting registration and dispatch, producing a weaker version of what Laravel already provides.
- How do I install webman/event in a webman project?
- Install it with Composer as webman/event and let the webman plugin mechanism bootstrap it, then define your event-to-listener mappings in config/plugin/webman/event/event.php. The package is MIT-licensed and small, a handful of classes, so setup inside a fresh webman service is a scaffold-level task. Check the declared PHP and webman framework constraints in its composer.json before installing, since the last release dates from December 2023.
- How do I register listeners for an event?
- Listeners are registered through configuration: you map an event name to one or more listener classes in the plugin's event configuration file. Multiple listeners per event are supported, so a single dispatch can fan out to several handlers. Because the mapping lives in config rather than in code, you can add or reorder handlers without touching the dispatching code.
- How do I dispatch an event in webman/event?
- You dispatch with the plugin's static emit-style API, typically Event::emit() with the event name and payload. It can be called from controllers, services, or middleware, which is what makes it useful for decoupling layers. Keep dispatch points narrow and payloads explicit so listeners stay easy to reason about and test.
- Does webman/event support queued or asynchronous listeners?
- No. Listeners run synchronously in-process inside the long-lived webman worker, and there is no built-in queueing, ordering guarantee, or at-least-once delivery. If you need background work or retries, hand off to a real queue or message broker from inside the listener. This package only addresses intra-process decoupling within a single service.
- Is webman/event compatible with webman 2.x?
- That is unverified and should be treated as a risk. The last release was 2023-12-04, which predates webman 2.x, and the composer constraint may still pin ^1.x. Pin the plugin version, run a short compatibility spike against the exact webman version you plan to deploy, and be ready to vendor or fork the code, which is feasible given its small surface area.
- Is webman/event actively maintained and safe as a dependency?
- It has very low adoption, roughly nine stars and no dependents, so there is no ecosystem signal or downstream validation. That is acceptable for a small internal utility but disqualifying as a strategic dependency. Because the code is small, audit it and vendor or fork it if you adopt it, rather than relying on upstream releases.
- What are the production risks of running event listeners in a long-running webman worker?
- Listeners execute inside a persistent worker process, so blocking calls, unbounded loops, static state, or uncaught exceptions have a much larger blast radius than under a per-request PHP-FPM model. Keep listeners short and non-blocking, catch and log exceptions instead of letting them bubble, and avoid mutating shared state. Test listener behavior under load, not just in a single-request smoke test.
- What should I use instead of webman/event, and how should I abstract it?
- In Laravel, use the native event dispatcher; in generic PHP, Symfony's EventDispatcher or a small in-house registry are reasonable alternatives. If you adopt webman/event for a webman service, hide it behind a narrow internal interface such as App\Contracts\EventBus with dispatch() and listen() methods so the implementation can be swapped later without touching domain code. That abstraction is cheap to build and is the highest-leverage decision when depending on a low-adoption plugin.