Event Like Laravel Package

Getting Started

composer require bnnvara/event-like

There is no Flex recipe for this bundle, so registration is manual. Check composer.json for the PSR-4 prefix before wiring it up — the namespace may not match the vendor/package name:

// config/bundles.php  (Symfony 4+/5+)
return [
    // ...
    Bnnvara\EventLike\EventLikeBundle::class => ['all' => true],
];

For Symfony 3.4 the same goes in app/AppKernel.php under registerBundles().

Where to look first, in order:

1. README.md — likely thin, but it will show the intended event name(s) and any config keys.
2. composer.json — symfony/event-dispatcher and php constraints tell you immediately whether this targets Symfony 3.4/4.x or 5+. Treat that as the first compatibility gate.
3. src/Event/ (or Event/) — the event classes are the public API; everything else is plumbing.
4. DependencyInjection/*Extension.php + Resources/config/services.* — confirms whether the bundle auto-registers listeners and what the config tree (event_like:) accepts.
5. DependencyInjection/Compiler/ — if there is a compiler pass, it may be doing tag collection you need to opt into.

First use case: subscribe to the like event and increment a counter or write an activity record, without touching the bundle's internals.

// src/EventListener/LogLikeListener.php
final class LogLikeListener
{
    public function __construct(private LoggerInterface $logger) {}

    public function onLike(object $event): void
    {
        // Inspect the event class first — accessor names vary.
        $this->logger->info('like', ['event' => $event]);
    }
}

# config/services.yaml
App\EventListener\LogLikeListener:
    tags:
        - { name: kernel.event_listener, event: bnnvara.event_like.created, method: onLike }

Confirm the event alias from the bundle source before running — with a package this small, the string is often only documented in the class that dispatches it.

Implementation Patterns

Dispatch from your own domain code. The bundle supplies the event objects; your like/dislike service is what normally fires them. Dispatch after EntityManager::flush() so listeners can read the persisted ID:

$em->persist($like);
$em->flush();

$dispatcher->dispatch(new LikeCreated($like), LikeEvents::CREATED);

Note the signature difference: Symfony 4.3+ uses dispatch($event, $eventName = null); pre-4.3 is dispatch($eventName, Event $event). Verify against the constraint in composer.json before copy-pasting.

Prefer EventSubscriberInterface for multi-event work. If the bundle exposes created/deleted (and possibly toggled) events, a subscriber keeps them in one class and gets picked up automatically with autoconfigure: true:

final class LikeSubscriber implements EventSubscriberInterface
{
    public static function getSubscribedEvents(): array
    {
        return [
            LikeEvents::CREATED => ['onCreated', 10],
            LikeEvents::DELETED => 'onDeleted',
        ];
    }
}

Fan out heavy work through Messenger. Like events are a natural trigger for notifications, feeds and analytics. Keep the listener thin and enqueue a message rather than doing SMTP or HTTP inside the request:

public function onCreated(LikeCreated $event): void
{
    $this->bus->dispatch(new SendLikeNotification($event->getLikeId()));
}

Guard against duplicate likes. A like button double-tap or a retried webhook will dispatch twice. Enforce uniqueness on (user, subject) at the database level and let the listener be idempotent — check by ID, not by object identity.

Testing. Assert on the dispatcher rather than on side effects:

$dispatcher = $this->createMock(EventDispatcherInterface::class);
$dispatcher->expects($this->once())
    ->method('dispatch')
    ->with($this->isInstanceOf(LikeCreated::class));

For the listener side, instantiate it directly and pass a hand-built event — this package is small enough that you never need to boot the kernel to test it.

Gotchas and Tips

• Zero dependents and no stars is the headline risk. No community means no one has hit your bug before you. Pin it to an exact version ("bnnvara/event-like": "1.2.*") and read the full source — it's likely a few hundred lines. If it becomes load-bearing, vendor-fork it under your own namespace so an abandoned upstream can't block a Symfony upgrade.
• Symfony version drift is the most likely breakage. A bundle like this, targeting event-dispatcher 3.x/4.x, will still install on 5.x in many cases but the dispatch() argument order changed. Check composer.json constraints, not just whether composer require succeeded.
• Doctrine flush ordering. Dispatching inside the entity's lifecycle callback (or before flush) gives listeners an entity with a null ID. Dispatch from the service layer after flush.
• Recursion via listeners. If a listener persists and flushes, and your entity has a postPersist hook that dispatches the like event again, you get an infinite loop. Keep dispatch in the service, never in entity callbacks.
• Missing autoconfigure config. On older Symfony setups, autoconfigure may be off; a listener without an explicit kernel.event_listener tag silently does nothing. If nothing fires, that's the first thing to check — then run bin/console debug:event-dispatcher <event.name> to confirm your listener is registered at all. (Requires symfony/event-dispatcher-debug on some versions.)
• Event-name strings are brittle. If the bundle exposes a constants class, use LikeEvents::CREATED rather than a literal — a patch release that renames the string won't be caught by static analysis otherwise.
• Extension points are limited by design. The realistic levers are: your own listeners, decorating event_dispatcher, or wrapping the bundle's dispatcher call in a thin application service you control. Do that thin wrapper early — it's the seam that lets you drop the bundle later without touching call sites.
• Check for a config tree you didn't notice. A Configuration.php with no README mention often hides a class: override or a dispatch_async: true flag that changes behaviour. Dump it with bin/console config:dump-reference event_like.