Laravel Likeable Laravel Package

Product Decisions This Supports

• Feature scoping for engagement mechanics. This package is the "buy" option for a single like/favorite primitive: one user, one model, one boolean state. It supports decisions like "ship Likes on posts and comments this sprint" versus "we need a full reactions system," because it tells you exactly where the cheap line is.
• Roadmap: social proof and personalization surface area. It unlocks the low-cost engagement cluster — like counts on cards, "Liked by you" state on lists, filter-by-liked views, and a positive-signal feed for recommendations — without new infrastructure.
• Build vs. buy. The alternative is a hand-rolled polymorphic pivot table plus traits, which is ~a day of work but accrues ongoing maintenance (N+1s, counter caching, toggle race conditions). Adopting this replaces that with a Composer dependency.
• Use cases to prioritize against it: likes on feed items, favorites/bookmarks, upvote-style sorting inputs, "saved for later" lists, and lightweight engagement analytics. Each is a same-package variation, so they can be sequenced without new architecture.
• Release 3.1.0 specifically de-risks the UX decision to show like state everywhere. The check for "is this model liked by the current user" now consults eager-loaded relations before querying. That directly affects the cost of rendering per-item like state on feed and list pages — the exact pattern PMs ask for and engineering usually pushes back on. It moves "show liked state on every card" from an N+1-riddled request into a supported pattern, provided the team eager-loads correctly.
• Not a signal for anything else. 3.1.0 is a performance refinement only: no new API surface, no deprecations, no breaking changes. Nothing here should move roadmap dates or trigger a migration plan.

When to Consider This Package

Adopt when most of these hold:

• The product model is genuinely one like per user per object, with no reaction taxonomy (no 😂/😍/👎), no weighted scores, and no per-reaction reporting.
• Polymorphic coverage matters — you need to like posts, comments, and future models from one table rather than building a pivot per entity.
• The stack is Laravel + Eloquent, PHP 8+, on a currently supported Laravel version.
• Expected volume is moderate: read-heavy feeds with like state, counts in the thousands-to-low-millions per object. No hard real-time requirement.
• Team is small enough that a maintained dependency beats bespoke code you'd have to own.

Look elsewhere (or plan to wrap and extend) when:

• You need multiple reaction types, vote scores, or Reddit-style ranking — that is a different data model, and retrofitting it here is more work than starting clean.
• You need denormalized counters under high write throughput, hot-row contention handling, or cached/sharded counts. The package gives you the relation, not a scaling strategy.
• You need a full audit trail of who liked, unliked, and re-liked, with timestamps for analytics or abuse review.
• You need cross-service or non-Eloquent access to like state, or multi-tenant partitioning guarantees.
• Maintenance risk is unacceptable for a core surface. This is a single-maintainer, modest-community package — low absolute risk because the domain is simple and forkable, but it is not a vendor with an SLA. Mitigate by defining an app-level LikeService / interface so a swap stays cheap.

How to Pitch It (Stakeholders)

For executives: This is a small, free, MIT-licensed dependency that converts "engagement features" from a multi-sprint build into days of integration. It gives us likes, favorites, and per-user "liked" state on any content type from one table, with no new services or infrastructure spend. The 3.1.0 release is a drop-in performance improvement that makes showing like state across a whole feed affordable, which is the version of the feature users actually notice. Downside is bounded: the domain is simple and the code is forkable, so worst case we replace it in-house without touching product behavior.

For engineering: Standard HasLikeable trait on models, polymorphic likes table, like/unlike/toggleLike/isLikedBy plus query scopes. 3.1.0 resolves the liked-state check against eager-loaded relations first, so per-item like indicators stop generating N+1s — but only if we eager-load; treat that as a review checklist item, not an automatic win. No breaking changes from 3.0.1, no deprecations, upgrade is routine. Recommend we consume it behind a thin internal interface and keep count aggregation in our own layer, since the package deliberately stops at the relation and won't solve hot-row counters or reaction taxonomies for us.