Laravel Likeable Laravel Package

Product Decisions This Supports

• Reactions as a v1 feature, not a bespoke build. Like/dislike on any Eloquent model means one implementation covers posts, comments, videos, reviews, and Q&A answers. That removes the "which content type do we add reactions to first?" debate from roadmap planning — the polymorphic design means the second and third surfaces are near-free.
• Build vs. buy for a low-differentiation feature. Reactions are table stakes in community, marketplace, and UGC products. The honest framing for a roadmap review: this is roughly 1–2 days of internal work to replicate, so the decision is really about maintenance burden, not capability. Buying (via Composer, MIT) is defensible because it offloads schema, toggling edge cases, and counter drift to someone else.
• Like-only vs. likes + dislikes as a product decision. The package makes them mutually exclusive at the model level, which forces an explicit product call. Dislikes are a meaningful moderation and sentiment signal on editorial content, but they're a known harm surface on user-generated content and creator platforms (downvote pile-ons). Use this package's design as a prompt to decide deliberately rather than defaulting to both.
• Popularity-ranked feeds and "best of" surfaces. orderByLikesCount, orderByDislikesCount, and likesDiffDislikesCount (a net score, Reddit/HN-style) directly enable sort-by-top, trending modules, and digest emails without a separate ranking service. This is a scoping lever: it lets you ship a "top this week" surface without a data pipeline.
• Social proof and engagement instrumentation. liked, likesCount, collectLikers() support the UI affordances (filled vs. outlined icon, "liked by X and 42 others", liker lists) and give you the numerator for engagement-rate metrics without instrumenting a custom event stream.
• Targeted notifications and activity feeds. ModelWasLiked / ModelWasDisliked events are the hook point. Product decision: do likers get notified when someone likes their content? Do we batch? The event contract lets you defer that call without blocking the initial launch.
• Analytics and ML feature inputs. whereLikedBy($user->id) and whereDislikedBy($user->id) give you per-user signal queries for recommendations, "because you liked…" modules, and negative-signal filtering — a cheap way to validate whether a recommender is worth investing in before committing to a real system.
• Operational trust in counters. The likeable:recount Artisan command is an admission that denormalized counts can drift, but it's also a mitigation you can point at during a launch readiness review. Product-visible counts that silently go stale are a trust bug; having a remediation command in the runbook matters.

When to Consider This Package

Adopt when:

• You're on Laravel 10–13 and PHP 8.3+, and reactions are a supporting feature rather than a core differentiator.
• You need reactions on more than one model type — this is where the polymorphic design pays for itself over a hand-rolled likes table.
• You want likes and dislikes with mutual exclusivity and net-score sorting out of the box, and you don't want to write toggle/unlike/undislike state transitions yourself.
• You're comfortable forking or vendoring. MIT license and a small, readable surface (contracts, traits, one service class) make this low-risk to internalize if the maintainer disappears.

Look elsewhere — or build in-house — when:

• Support risk is unacceptable. 9 stars and 0 dependents is the headline caveat. There is no ecosystem pressure testing this against edge cases you'll hit. For anything on a critical path, treat this as code you are adopting, not a vendor you are relying on: fork it, pin the version, and own it.
• You need rich reaction types. This is binary like/dislike only. If the roadmap includes emoji reactions, multi-reaction pickers, or per-reaction analytics, you'll be migrating off this schema.
• Moderation and abuse are hard requirements. There's no rate limiting, no brigading detection, no reputation weighting, no shadow-ban hooks. A dislike feature on a platform with harassment risk needs those. Budget for them separately and be honest that this package provides none.
• You need API endpoints, UI components, or caching. None are included — you're getting domain logic and a migration, nothing user-facing.
• You need weighted or per-tenant scoring (e.g., likes from verified users count double, or scores isolated per workspace). The interface bindings let you swap the service, but at that point you're writing the interesting part yourself.
• Multi-tenancy, soft deletes, or high write volume are central concerns. Verify these against your schema before committing; a recount command exists precisely because counters are eventually-consistent.

Migration note for the plan: adoption is three commands (composer require, vendor:publish, migrate) plus a trait on each model — genuinely low switching cost in both directions, which is why the reversibility argument is strong here.

How to Pitch It (Stakeholders)

For executives: "Reactions are expected in every UGC product we're planning — community, reviews, marketplace. Rather than fund a bespoke build for each surface, this is a free (MIT), drop-in component that works across all our content types at once. It's roughly a day of integration versus a sprint of internal work, and it's small enough that if we ever want to own it, we can absorb the code in an afternoon. Low cost, low lock-in, and it unblocks popularity sorting, engagement metrics, and notification hooks in one pass."

For engineering: "Composer package for Laravel 10–13, PHP 8.3+. Trait + contract on any model; polymorphic likes/dislikes table comes from a published migration. Fluent API (like, unlike, likeToggle, liked), query scopes (whereLikedBy, orderByLikesCount), events on all four transitions, and a likeable:recount command for counter reconciliation. Everything is container-bound behind contracts, so Like, LikeCounter, and LikeableService are all swappable — that's our escape hatch. 79 tests, CI across PHP 8.3–8.5 and Laravel 10–13, Larastan and Pint in the pipeline. The real caveat is maintenance: one maintainer, 9 stars, no downstream dependents. Recommendation: pin the version, fork into our org, and treat it as internal code with an upstream we occasionally sync from. That gives us the time-to-value without the bus-factor problem. Confirm before we start: soft-delete behavior on likers, our counter-drift tolerance, and whether we need rate limiting at the application layer — the package doesn't provide that and we'll own it."