Laravel Markable Laravel Package

Product Decisions This Supports

• Build vs. buy on engagement primitives. Likes, bookmarks, favorites, and emoji reactions are almost always on the roadmap and almost never a differentiator. This package turns that from a ~1–2 sprint build (polymorphic tables, toggle logic, uniqueness, cascade deletes, query scopes, tests) into a half-day integration. The decision it most directly supports: do not spend engineering capacity on the plumbing behind engagement mechanics.
• Roadmap sequencing for social/community features. Because one Markable trait + mark model covers any entity, you can ship "save for later" on courses, "like" on posts, and "reaction" on comments from a single dependency. That makes it cheap to sequence engagement features incrementally instead of committing to a monolithic "social layer" epic.
• Which engagement mechanic to ship first. The package supports likes, bookmarks, favorites, reactions, and arbitrary custom marks. This lowers the cost of the experiment, so the PM decision shifts from "which one can we afford to build?" to "which one do we hypothesize moves retention?" — a materially better question.
• Reaction-set as a product surface, not an engineering task. allowed_values (including wildcard * and BackedEnum classes as of 3.0.0) makes the reaction palette a config change. You can A/B test a 3-emoji palette against a 6-emoji palette, or scope different palettes per mark type, without a deploy-cycle negotiation with engineering.
• Segmentation and audience features. whereHasLike($user) / whereHasReaction($user, 'heart') scopes make "things I've saved/liked/reacted to" and "things this cohort reacted to" cheap to build — directly enabling personalization, digest emails, and re-engagement campaigns.
• Scoping the analytics ask. The package counts marks (Like::count($model)) but is not an analytics or aggregation layer. This is useful as a boundary-setting decision: engagement counters live here; funnels, cohorts, and time-series belong in your warehouse/event pipeline.
• Deferring moderation investment consciously. There is no built-in rate limiting, abuse detection, or moderation queue. The PM decision this forces is explicit: engagement features ship with a moderation/throttling story, or you accept the risk knowingly for a v1.

When to Consider This Package

Adopt it when:

• You're on a modern Laravel version and the models in question are Eloquent models — the integration is a trait, a $marks array, and published migrations.
• You need polymorphic engagement: the same "like" or "bookmark" concept applied to multiple entity types (posts, courses, comments, listings).
• You want engagement state queryable in SQL — filtering feeds, building "my saved items" pages, and joining marks into existing queries — rather than pushing it into a cache or an external service.
• You want the reaction/mark taxonomy to be type-safe (PHP backed enums) and configurable without schema changes.
• You're comfortable owning the migrations. Per-mark tables are an explicit performance trade-off (fast single-mark queries, more tables) and the package asks you to publish only the ones you need — good, but it means schema evolution is your responsibility.
• Your team is small enough that the maintenance burden of ~a dozen small tables and a thin third-party dependency is clearly cheaper than first-party code.

Look elsewhere — or budget for significant wrapping — when:

• Scale of counters is a core concern. If you need millions of mark writes per day, denormalized hot counters, idempotent bulk writes, or sub-10ms count reads at high fan-out, plan on Redis/denormalized counters alongside this (or instead of it).
• You need engagement as an event stream. There are no model events, webhooks, or outbox hooks documented for mark add/remove. If downstream systems (notifications, feeds, recommendations, warehouse) must react to every like, you'll be adding that instrumentation yourself — factor it into the estimate.
• You need built-in abuse controls. No throttling, duplicate-collision policy beyond mark semantics, moderation states, or soft deletes.
• Vendor assurance matters. This is an agency-maintained (maize-tech) package, MIT-licensed, ~760 stars. That's respectable community validation for an application-layer library, but it is not a de-facto standard with broad enterprise adoption. The Dependents: 0 figure is a weak signal for app-level packages (few packages depend on them by nature) but should be read as: limited third-party evidence of long-term stability. 3.0.0 landed in April 2026 with a breaking major, which is a normal but real upgrade cost.
• You need rich social-graph semantics — mutual follows, permissions on who can react, weighted reactions, or nested threading. This is a mark table, not a social graph.
• You're not on Laravel, or your persistence layer is Postgres/MySQL with heavy custom partitioning needs that conflict with the per-mark-table pattern.

Diligence items before committing: confirm the supported Laravel/PHP matrix against composer.json (changelogs show Laravel 10 and 11 support added; verify 12), confirm cascade-delete behavior on your own model deletions (1.0.1/1.0.2 addressed this, but re-verify on your schema), and confirm the JSON metadata column is sufficient for your attributes rather than needing first-class columns with indexes.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: We have a recurring class of features — likes, saves, favorites, reactions — that every product team ends up hand-building, and that none of our customers buy us for. maize-tech/laravel-markable is a small, MIT-licensed, actively maintained Laravel package that provides that plumbing out of the box: one trait, published migrations, and a clean API for adding, removing, toggling, checking, and counting marks across any entity in our app. Adopting it converts a multi-sprint engagement epic into days of integration work, with no licensing cost and no vendor lock-in — it's a thin layer over our own database, so the exit cost if we ever outgrow it is low. The trade-offs are honest ones: it doesn't handle analytics, notifications, rate limiting, or high-volume counter caching, so we'd scope those as explicit follow-ons rather than assume them. Recommendation: adopt for engagement mechanics, keep our analytics and abuse-prevention in our own stack, and treat the dependency as replaceable.

For engineering — why this is the right shape: It's an idiomatic Laravel package, not a framework. A Markable trait plus a $marks array registers marks on a model; each mark gets its own table (explicit, documented perf trade-off: fast per-mark queries), keyed by user_id + morphs('markable') + nullable value + JSON metadata + timestamps. The API is static and readable — Like::add/remove/toggle/has/count — with optional metadata payloads. Reaction values are validated against allowed_values in config, support a * wildcard, and accept BackedEnum cases for type safety (3.0.0). Eloquent relations (->likes, ->likers with value as pivot) and dynamic scopes (whereHasLike, whereHasReaction) mean we compose engagement into existing queries instead of bolting on a second data path. Custom marks are a migration plus a class extending Mark. Our integration work: publish only the migrations we need, add the trait to target models, and decide where moderation/throttling and any event dispatch must be layered on — those are our responsibility, not the package's. Budget accordingly: roughly a day to integrate, plus scoped work for abuse controls and any downstream eventing.