Event Like Laravel Package

Product Decisions This Supports

• Build vs. buy for engagement primitives. "Likes" look trivial in a roadmap deck and are deceptively expensive in practice: polymorphic targets (posts, comments, photos), idempotency, counters, notifications, feed ranking, moderation, and analytics all hang off it. This package informs that decision by showing the eventing slice of the problem only — it gives you a canonical domain event when a like or unlike happens, which is the seam you'd otherwise hand-roll.
• Event-driven architecture choices. If the product already runs on Symfony's EventDispatcher, adopting a standard LikeEvent/UnlikeEvent contract lets notifications, activity feeds, analytics pipelines, and anti-abuse rules subscribe instead of being wired directly into controllers. That is an architectural decision worth making early, before like-handling logic leaks into five places.
• Roadmap sequencing for social proof features. Deciding whether "likes" is a v1 differentiator or a v2 nice-to-have. A thin dependency like this one signals that the event contract is cheap to standardize now, while the storage, ranking, and moderation work — the actual cost — remains yours to schedule.
• Scope containment. It clarifies a useful product boundary: reactions are a domain event, not a feature. This supports deferring the "reactions with emoji, counts, and who-liked lists" backlog item until you have a reason to own that surface area.
• Third-party dependency policy. With zero stars and zero dependents, this is a live test case for your team's policy on unvetted, single-maintainer, Bitbucket-hosted dependencies. The decision it most directly supports is whether your default is "vendor it" or "write the twelve lines yourself."

When to Consider This Package

Consider it only when all of the following hold:

• The application is a Symfony app — note the description says "Symfony bundle," not Laravel. If your stack is Laravel, this is a non-starter without an adapter layer, and the adapter would cost more than the package saves.
• You want a standard event name and payload shape for like/unlike so multiple subscribers (notifications, metrics, feed) can attach without coupling to your controllers.
• You are comfortable owning a fork — assume you will vendor or pin it, and that upstream maintenance is not a thing you can rely on.
• The like feature is genuinely peripheral to your product, so a small unproven dependency carries low blast radius.

Look elsewhere (or build it yourself) when:

• You need persistence. This package is an event layer; it does not appear to solve storage, uniqueness constraints, counter aggregation, or read models. Those are the hard parts and they remain 100% yours.
• You need production guarantees. Zero stars, zero dependents, no visible community, Bitbucket-only hosting. There is no signal of test coverage, release cadence, or security review. Treat it as sample code, not a dependency.
• You need polymorphism, moderation, rate limiting, or analytics-grade event volume. None of that is implied by a thin event bundle.
• Licensing or Symfony/PHP version compatibility is unverified. Confirm the license and the composer.json version constraints before it enters any design doc — an incompatible constraint is the most likely failure mode.
• The real requirement is small. If all you need is dispatch-on-like, a hand-written event class plus a dispatcher call is a half-day of work with zero supply-chain risk. That is usually the correct answer here.

How to Pitch It (Stakeholders)

Executives: There is an off-the-shelf PHP component that standardizes the "someone liked something" event, which is the plumbing that notifications, feeds, and reporting all listen to. It is not a like feature — it will not store likes, count them, or moderate them. Adoption risk is high and payoff is modest: the project has no measurable user base, no visible maintainer activity, and lives on a non-standard host. My recommendation is not to adopt it as a dependency. Instead, use it as a reference design and have engineering implement the equivalent event contract in-house — roughly a day of effort, no vendor risk, and full ownership of the parts that actually matter (storage, counts, abuse).

Engineering: This bundle gives you LikeEvent/UnlikeEvent wired to Symfony's dispatcher. It solves the smallest part of the problem. Before we spend any time on it: verify license, composer.json PHP/Symfony constraints, and test coverage. If those check out, the most we should do is read it for naming and payload conventions and then write our own event classes — the interface is the reusable artifact, not the code. If anyone wants to spike it, time-box to half a day and keep it behind a feature branch; do not add it to composer.json on the main line until we have a reason to justify an unmaintained, zero-adoption dependency in the supply chain.