Likeable Laravel Package

Product Decisions This Supports

• Build vs. buy for engagement primitives: v1.0.0 provides a complete, production-shaped likes/favorites layer, so teams can avoid custom schema, polymorphic relationship plumbing, idempotency handling, cleanup jobs, and event wiring for a common feature.
• Roadmap acceleration for social proof and engagement: Enables likes, favorites, saved items, “helpful” markers, and similar lightweight signals across any model without per-entity implementation work.
• Cross-entity product features: Polymorphic likers and likeables mean one implementation supports liking users, posts, comments, products, courses, or internal objects, including a model that both likes and can be liked.
• Feed and list UX decisions: withLikedBy() and isLikedBy() support showing liked state for lists in one query, which is directly useful for activity feeds, search results, catalogs, and dashboards without N+1 queries.
• Event-driven product behavior: Liked and Unliked events dispatched after commit enable notifications, analytics, recommendations, audit trails, and downstream automation without coupling to the like action.
• Data lifecycle and hygiene decisions: Automatic cleanup on model/liker deletion plus scheduled pruning through model:prune reduces orphaned-like issues and supports retention/compliance expectations.
• Platform standardization: Configurable connection, table, and default liker model lets teams fit existing tenancy, database, and domain conventions rather than adopting a fixed schema.
• Scope control for reaction strategy: The package is a strong fit for a simple like/favorite primitive, but product decisions requiring multiple reaction types, ratings, weighted scoring, or feed ranking should treat this as a foundation or a build-vs-buy comparison point, not an out-of-the-box solution.

When to Consider This Package

Consider adoption when:

• You are building on Laravel/PHP and need a simple like, favorite, or save mechanism across one or more Eloquent models.
• Multiple entities should be likeable, and/or multiple entity types should be able to like, including cases where a model needs both capabilities.
• You want idempotent like/unlike behavior without custom logic for duplicate likes.
• You need to display liked state efficiently in lists and detail views—withLikedBy() and isLikedBy() are directly relevant.
• You expect to react to likes through events for notifications, analytics, or engagement scoring.
• You want lifecycle hygiene—cleanup on deletion and scheduled pruning—without writing and maintaining custom jobs.
• You need configuration flexibility for database connection, table name, and default liker model.
• You are standardizing a common engagement pattern across teams or product areas.

Look elsewhere or plan additional build when:

• The product needs multiple reaction types such as love, celebrate, support, or emoji reactions with per-type semantics.
• The roadmap includes ratings, reviews, upvotes/downvotes with scoring, weighted ranking, or recommendation logic; this package covers the like primitive but not ranking or scoring models.
• You require real-time counters at very high scale with denormalized counts, sharded storage, or stream processing beyond standard Eloquent patterns.
• You need complex moderation, abuse detection, audit history, or policy enforcement around likes.
• The application is not Laravel/PHP or cannot adopt Eloquent conventions.
• You need a full social graph, follow relationships, notifications, or activity-feed infrastructure; this package is a component, not a complete engagement platform.

How to Pitch It (Stakeholders)

For executives: v1.0.0 gives us a ready-made, Laravel-native likes/favorites capability that can be reused across products and entities. It reduces custom build effort for a common engagement feature, supports faster experimentation with social proof, and includes data cleanup and event hooks that lower operational and compliance risk. It is a focused primitive, not a full reactions or ranking engine, so it is best positioned as a cost-effective foundation for engagement features rather than a complete social platform.

For engineering: The package provides contracts and concerns for both likers and likeables, polymorphic relationships, idempotent like()/unlike()/hasLiked(), efficient liked-state queries for lists, configurable models/connections/tables, cleanup on delete, scheduled pruning, and post-commit events. It fits Laravel conventions and avoids bespoke migration, relationship, and job work. It is appropriate when the requirement is a single like/favorite semantic; teams should layer additional product logic for reaction types, scoring, moderation, or high-scale counter strategies.