Likes For Laravel Laravel Package

Product Decisions This Supports

• Broadcast payload contract change — this one is not housekeeping. 1.1.2 changes the values of actor_type and likeable_type in the Liked, Unliked, and ReactionChanged broadcast payloads from the PHP class name (App\Models\User) to the class basename (User). This is a wire-format change visible to every subscriber of the likeable's channel, so it belongs in a release note and an upgrade plan, not a routine composer update.
• Consumer inventory is now the gating task. Any listener, front-end handler, mobile client, or third-party integration that matches on the literal string App\Models\User / App\Models\Post will silently stop matching. Because the change is silent (no exception, just no match), the product risk is missed notifications or broken reaction feeds rather than a loud failure — plan a search for string matches in your own code and in any external consumer contracts.
• Information-disclosure / coupling improvement. Emitting fully-qualified class names leaked your application namespace (App\Models\...) to every channel subscriber and hard-coded your internal model layout into the payload. Basenames are a cleaner, more portable contract — a modest correctness and hygiene win, not a feature.
• Channel names are unchanged. Subscription topology, authorization callbacks, and presence/private channel setup are untouched. The blast radius is limited to value matching inside payloads, which makes this a contained but real migration.
• Morph-map behaviour change is a second, quieter decision. Previously, with a morph map registered, these fields carried the alias; now they carry the basename regardless. Teams that deliberately used morph aliases as a stable public identifier (e.g. user, post) lose that indirection. Decide explicitly whether basename is an acceptable long-term contract for you; if not, this is a reason to wrap the payload in your own DTO rather than consume it raw.
• Release-process signal — negative. A behaviour-breaking payload change shipped in a patch version (1.1.1 → 1.1.2) with no major bump and no deprecation window. That is a semver-hygiene concern for a package on a critical path: it means you cannot rely on version numbers to predict upgrade cost. Weigh this in "keep vs. build vs. wrap" decisions, and consider pinning to an exact version with a deliberate review before each bump.
• Upgrade scheduling. Unlike 1.1.1, this needs a scheduled change, an owner, and a verification step (send a test like/reaction and assert the listener fires). It is small in effort but not zero-risk, and it cannot be validated by CI alone if the matching logic lives outside this repo.
• Maintenance items are neutral. Dev testing ^1.6 and PostgreSQL/MySQL CI legs on tmpfs affect maintainer throughput, not our integration. No roadmap impact.

When to Consider This Package

• Consider adopting/upgrading when: you consume these broadcast events and want to stop leaking fully-qualified class names to subscribers; you control all listeners and can update them in the same deploy; and you are comfortable treating the basename (User, Post) as your long-term payload contract.
• Upgrade with sequencing when: any consumer is not deployable atomically with the backend — SPA bundles cached in browsers, shipped mobile apps, third-party webhooks or analytics pipelines. In that case, make listeners accept both the old and new values for a deprecation window before removing the old match, and only then bump the package.
• Defer when: you are mid-freeze, or you rely on morph-map aliases as a stable external identifier and have no wrapper layer. Nothing here is a security emergency; the disclosure improvement is minor. Deferring costs you only the hygiene win.
• Look elsewhere / wrap when: you need a stable, versioned event contract. Given a breaking payload change in a patch release, the pragmatic option for a critical path may be to consume these events through your own thin adapter or DTO that normalises actor_type/likeable_type, so upstream naming changes stop being your migration. That is a genuine build-vs-buy input this release surfaces for the first time.
• Validate separately before committing: maintainer count, open-issue velocity, and whether the maintainer documents breaking changes outside major versions. "Actively maintained" is still true, but 1.1.2 shows maintenance activity and contract stability are not the same thing.
• Caveat for this assessment: we still have no feature documentation, no usage data, and no record of how many of our own listeners or external clients read these fields. The recommendation above is scoped to what 1.1.2 implies; the actual go/no-go depends on the consumer inventory, which must be gathered before scheduling the bump.

How to Pitch It (Stakeholders)

For executives: This release is small but not purely cosmetic. It changes the contents of our real-time like/reaction notifications: the actor and subject are now identified as User / Post instead of the full internal class path. Functionally the events still fire and the channels are unchanged, but any client or integration that was matching on the old string must be updated at the same time or it will quietly stop responding. The upside is that we stop exposing our internal code namespace to everyone subscribed to those channels, and the payload becomes more portable if we ever restructure our models. The cost is a short, contained engineering task plus a coordination step for any mobile or third-party consumer. Two things worth flagging upward: it is a one-time migration, not an ongoing cost, and because the vendor shipped a behaviour change in a patch version, I'd recommend we pin the exact version and review future bumps rather than auto-updating.

For engineering: 1.1.2 changes actor_type and likeable_type in the Liked, Unliked, and ReactionChanged broadcast payloads from the FQCN (App\Models\User) to the basename (User), both with and without a morph map — previously a registered morph map produced the alias, now it produces the basename. Channel names are untouched, so no subscription or authorization changes are needed. Before bumping: grep for literal App\Models\ and for morph aliases in listeners, front-end event handlers, and any outbound webhook or analytics consumer. Update in-repo listeners and the package version in the same deploy so matching stays atomic. For consumers we cannot redeploy atomically (cached SPA bundles, shipped mobile apps, external partners), accept both old and new values behind a short compatibility check and remove the old branch after the client population has rolled over. Verify with an end-to-end like/unlike/reaction in staging, asserting the handler actually fires — a mismatch here fails silently rather than erroring. Also note this shipped as a patch with a breaking payload change; pin to 1.1.2 exactly rather than a caret range, and raise the semver question with the maintainer if this package is on a critical path. The dev testing ^1.6 and CI tmpfs items need nothing from us.