Social Interactions Laravel Package

Product Decisions This Supports

• Build vs. buy for engagement primitives. A package like toneflix/social-interactions covers the commodity layer of social features — attaching likes/reactions, follows, and similar interactions to Eloquent models — so we can decide to buy the plumbing rather than spend sprint capacity on polymorphic pivot tables, counter caches, and duplicate-interaction guards.
• Roadmap sequencing for community/engagement bets. If the roadmap contains likes, follows, saved items, or lightweight reactions, this is a candidate to ship the feature in days instead of weeks, freeing engineering for the differentiated parts (feed ranking, notifications, moderation).
• Scope boundary for the social layer. It is a data-model helper, not a product. It does not by itself deliver feeds, activity streams, abuse handling, or notification fan-out — those remain our build items and should be estimated separately.
• Platform lifecycle decisions. 2.0.0 is a hard cutover to PHP 8.3+ and Laravel 12/13 only, with a vendor and namespace rename (toneflix-code/social-interactions → toneflix/social-interactions, ToneflixCode\SocialInteractions → Toneflix\SocialInteractions). This makes adoption a platform-standardisation decision as much as a feature decision: it only fits if our app fleet is on, or committed to, Laravel 12/13.
• Dependency risk review. The vendor/namespace move and the Laravel 13-first support signal a maintainer reorganising under a personal vendor namespace. That is a governance input for whether this becomes a long-lived dependency or a temporary accelerator to be replaced in-house later.

When to Consider This Package

Adopt when:

• Our application (or the specific service) is on Laravel 12 or 13 with PHP 8.3/8.4 — the only supported combination in 2.0.0.
• We are greenfield on the engagement feature, or we can absorb the rename in a single, contained pull request (imports + published config).
• The interaction model we need is the generic one — "this user liked/followed/saved that model" — rather than domain-specific engagement rules.
• We want to validate demand for a social feature quickly and are comfortable with a small, single-maintainer dependency in a non-critical path.
• We can pin the version (^2.0) and vendor it or wrap it behind our own interface so a future rename or abandonment does not ripple through domain code.

Look elsewhere (or build in-house) when:

• We are still on Laravel 10/11 or PHP 8.1/8.2. This major drops that support; there is no announced shim or bridge release, so upgrading is mandatory before taking 2.0.
• We need moderation, abuse detection, rate limiting, or notification delivery — none of which a model-interaction package owns.
• We need enterprise support, an SLA, or a security disclosure process. A personal-namespace package does not provide these; treat it as community-supported.
• We require namespace/vendor stability guarantees, or our policy forbids dependencies that have already performed one vendor migration.
• A first-party or widely adopted alternative already exists in our stack, or our interaction volume demands a purpose-built store (e.g., high-write counters in Redis) rather than Eloquent relations.

Migration cost to note for existing 1.x users: composer remove + composer require toneflix/social-interactions:^2.0, then a global replacement of the namespace in imports and published config, plus a platform bump to PHP 8.3 and Laravel 12/13. This is mechanical but touches every file that references the package — budget a half-day to a day including regression testing of the interaction endpoints.

How to Pitch It (Stakeholders)

For executives — one paragraph: We are evaluating a small Laravel package that provides the standard "social interactions" layer — likes, follows, and similar user-to-object relationships — so we do not hand-build that plumbing. Version 2.0.0 is a maintenance and platform-alignment release: the package has moved to a new vendor name (toneflix/social-interactions), upgraded to require PHP 8.3+ and Laravel 12/13, and refreshed its test tooling. There are no new user-facing features in this release. The decision it informs is whether engagement features are bought as a commodity or built in-house; the cost to adopt is low (a composer change plus a namespace rename), and the principal risk is dependency governance, not engineering effort.

For engineering — the ask:

• Confirm our target apps are on Laravel 12/13 and PHP 8.3+. If not, this package is not adoptable today; that is a platform-roadmap conversation, not a package conversation.
• Treat 2.0.0 as the only version we would evaluate. 1.x is legacy: old vendor, old namespace, narrower framework support.
• Wrap the package behind an internal interface (e.g., our own EngagementService) so vendor/namespace churn and any future abandonment are contained to one adapter class.
• Pin to ^2.0, add it to the dependency-review list, and record the single-maintainer risk explicitly.

Recommendation: Worth a time-boxed spike (1–2 days) on a Laravel 12/13 app to confirm the API fits our interaction model. Do not adopt it as a critical-path dependency without the adapter layer, and do not attempt adoption while any target service remains below PHP 8.3 / Laravel 12.