Laravel User Guest Like Laravel Package

Product Decisions This Supports

This release is a support-matrix change, not a feature release: 1.5.0 adds Laravel 13 compatibility and drops Laravel 11. Everything else in the changelog is Dependabot housekeeping on CI actions (checkout, fetch-metadata, release-to-Discord). Treat it as a maintenance signal, and use it to inform:

• Framework upgrade sequencing. If your product is still on Laravel 11, this package will no longer receive fixes or install cleanly on your stack. That is a forcing function for your Laravel 11 → 12/13 roadmap, and it will gate any "adopt this package" decision until the upgrade lands.
• Build vs. buy for engagement primitives. Likes/reactions with polymorphic (many model types) support and dual user/guest actors is a classic "two days to build, forever to maintain" feature. This package covers the write path (like/unlike), the polymorphic relation, and the guest path — the parts that are tedious rather than differentiating. The buy case is strong if your requirements are vanilla.
• Guest engagement as a product bet. The headline capability is letting non-authenticated visitors like content. That is a real acquisition/activation lever (lower friction, higher top-of-funnel engagement) but it has product consequences you must decide on deliberately: guest likes are device/session-scoped, so they can be duplicated across devices, cleared by cookie resets, and cannot be attributed to a person in your warehouse. Decide up front whether guest likes (a) count equally to user likes, (b) count but are visually or analytically separated, or (c) are a soft signal only.
• Metric integrity. If likes feed ranking, social proof, or "trending" logic, mixing anonymous and identified actors makes the denominator murky and opens a trivial abuse vector. Any adoption decision should be paired with a rate-limiting/dedupe decision, which is not something this package solves for you.
• Buy vs. build for the abuse surface. Session-based guest identity means you will likely need your own throttling, IP heuristics, or a "prompt to sign up after N guest likes" flow. Budget for that as custom work regardless of package choice.

When to Consider This Package

Adopt when:

• You are on Laravel 12 or 13 (post-1.5.0) and plan to stay current — the maintainer tracks new major releases promptly, which is the single best health signal for a small package.
• You need likes/reactions across multiple model types and want the polymorphic plumbing plus a guest path without writing migrations, traits, and toggle logic yourself.
• Engagement is a supporting feature, not your core product. The package removes boilerplate; it does not give you a reaction taxonomy, moderation, notifications, aggregation pipelines, or an abuse-prevention layer.
• You are time-boxed (MVP, validation experiment) and want to ship the interaction this sprint.

Look elsewhere / build in-house when:

• You are locked to Laravel 11 for the foreseeable future — 1.5.0 hard-drops it.
• You need more than likes: reactions with types, weighted signals, per-community scoping, or a high-volume aggregation path (counter caches, event streams). At that point you are extending a dependency rather than using one.
• Guest likes are a load-bearing input to ranking or trust. You want your own identity/dedupe model rather than inheriting a cookie-scoped one.
• Governance risk is unacceptable. This appears to be a single-maintainer package (author dsbilling, org kilobyteno) with a mostly-automated release cadence — the substance of 1.5.0 is one human PR plus eight bot PRs. There is no visible second maintainer, no stated LTS policy, and no evidence of a security review process. If a like feature is on your critical path, fork it or vendor it with your own tests. If it is a nice-to-have on a small surface, the dependency is cheap and reversible.
• You need compatibility guarantees or support SLAs — not available here.

On this specific release: no action required beyond pinning. If you already depend on the package, upgrade only after your app is on Laravel 12+, since 1.5.0 removes Laravel 11 support. If you are evaluating fresh, 1.5.0 is a reasonable starting point but note that CI action bumps are being surfaced as release notes, which means you cannot read the changelog to infer product direction — watch the commit history instead.

How to Pitch It (Stakeholders)

To executives: A small, free, open-source component that gives us "likes" on any piece of content, including from logged-out visitors. It removes roughly a sprint of undifferentiated plumbing, and the maintainer has just added support for the newest Laravel version — a good sign it is being kept alive. The trade-off is that it is one person's side project, so we should treat it as a replaceable convenience rather than infrastructure. Estimated impact: days of engineering saved, no licensing cost, low switching cost if it goes stale.

To engineering: Adds Laravel 13 support and drops Laravel 11 in 1.5.0. The rest of the release is Dependabot. It handles the polymorphic like/unlike write path for both authenticated users and guests; it does not handle throttling, dedupe, notification, or aggregation — those are ours. Assessment: fine to adopt behind a thin internal interface (a small service or repository wrapper) so we can swap or fork it without touching product code. Pin the version, and do not upgrade past it until we are off Laravel 11. Recommend a spike to confirm the guest-identity mechanism (assumed session/cookie-scoped) matches our abuse and analytics expectations before we commit — that is the one detail that would change the recommendation.