Laravel Reaction Laravel Package

Technical Evaluation

Architecture fit The package remains a conventional Laravel sidecar: service provider registration, publishable config/migrations, a polymorphic Reaction model, and trait-based composition (HasReaction on content models, CanReact on user models). That shape fits standard Laravel application architecture well and is the least invasive integration pattern available. The addition of CanReact as a separate trait is architecturally sound — it decouples "who can react" from "what can be reacted to," which most applications need (guests, multiple user types, admin impersonation). The introduction of a dedicated InvalidReactionSourceException and new events suggests a more explicit domain model than the previous Like implementation, which is good for observability but implies more integration surface to wire up.

Integration feasibility Feasible but non-trivial, because 3.0.0 is a near-total rename rather than an incremental change. Every public identifier a consuming codebase touches changes: package name (laravel-reaction), model (Like → Reaction), traits (HasLike → HasReaction), migration table and morph column (likeable → reactable), config keys/table, enum types (removed), and event class names. Any application referencing the old symbols, enum cases, or column names will fail at boot or at runtime. Integration is only "easy" for greenfield adopters; for existing 2.x consumers this is a coordinated code + schema + data migration.

Technical risk

• Data migration risk (highest): changing the migration table and renaming likeable to reactable implies either an in-place column rename or a new table with backfill. If the package ships only a fresh-install migration, existing reaction/like rows are orphaned unless the team writes its own backfill. This is unrecoverable if run carelessly in production.
• Morph map drift: renaming the morph column means existing polymorphic type values must still resolve; if class names or morph aliases changed alongside the Like → Reaction rename, historical rows can silently fail to resolve.
• Removal of LikeType enums: any code branching on enum cases (e.g., distinct reaction types) breaks with no drop-in replacement documented in the notes. The "complete" HasReaction/Reaction redesign implies a different way to express reaction types that is not yet evidenced.
• Composer identity change: renaming the package means a dependency swap, lockfile churn, and possible namespace changes — a supply-chain/CI surface change, not just a code change.
• Semantic versioning discipline: 3.0.0 is correctly major, but the changelog is a flat list without an upgrade guide or deprecation path.

Key questions

1. Is there a published upgrade guide or codemod from 2.x, and does 3.0.0 ship a compatibility shim/alias layer for the old trait and model names?
2. Does the migration rename existing columns/tables in place, or create new ones — and is a backfill provided for existing like data?
3. What replaces LikeType for teams that modeled multiple reaction kinds? Is a type column, enum, or separate model expected?
4. What is the supported Laravel and PHP version matrix, and why does the package now pin core to 1.20?
5. Are the new events and InvalidReactionSourceException documented with expected dispatch order and failure semantics?
6. Does CanReact change authorization semantics for existing user models (e.g., does it become required, or optional)?

Integration Approach

Stack fit Good fit for Laravel applications already using polymorphic interactions, and a better conceptual fit than 2.x for products with multiple reactable entities and multiple actor types. Teams on non-Laravel or older Laravel versions should verify the matrix before committing.

Migration path Treat 3.0.0 as a re-adoption, not an upgrade:

1. Pin 2.x in production; do not float the constraint.
2. In a branch, swap the composer dependency, install CanReact and HasReaction, and resolve all renamed symbols to green.
3. Republish config and migrations into a scratch environment; diff against existing schema to determine whether the package migration is additive or destructive.
4. Author a one-off data migration for likeable → reactable (and any type/enum data) with explicit rollback, validated on an anonymized production snapshot.
5. Run the prune-days config against a copy to confirm the new pruning behavior does not delete historical rows unexpectedly.

Compatibility Assume no backward compatibility: old and new symbols should not be mixed in one codebase. If incremental rollout is required, keep 2.x running and expose reaction behavior behind a feature flag rather than attempting to run both packages.

Sequencing Contract review (upgrade guide, supported versions) → dependency swap in isolation → symbol migration → schema diff → backfill dry run → events/exception wiring → staging soak → production cutover in a maintenance window → 2.x dependency removal and cleanup of unused files/config.

Operational Impact

Maintenance Neutral-to-positive long term: the rename consolidates naming, removes unused files, and adds tests, docs, factories, and contributing rules — all signals of a maintainable package. Short term it is a cost center: the team absorbs a full symbol and schema migration plus a package-identity change in the dependency graph.

Support The new language line, headers config key, and documentation updates reduce onboarding friction for new adopters. Support burden concentrates on 2.x users mid-migration, who will need internal documentation that the upstream changelog does not currently provide (no upgrade guide in the notes). Recommend the team write its own migration runbook.

Scaling Reactions are a higher-cardinality model than likes — more rows, more distinct actors, more reactable types. Verify composite indexes on (reactable_type, reactable_id) and on the actor side, and confirm the morph column rename preserves index coverage. The new prune-days setting is a genuine scaling lever for high-volume installs but must be tuned against retention requirements and analytics needs.

Failure modes

• Orphaned or unresolvable historical rows after the morph column rename — silent, and only visible in reporting.
• Boot-time failures from unresolved Like/HasLike/LikeType references and stale published config.
• Duplicate or unconstrained reactions if the new schema drops a uniqueness constraint present in 2.x.
• Pruning jobs deleting rows that downstream analytics or audit depend on.
• Package identity confusion in CI/cache (stale composer lock, duplicated provider registration).
• Event listeners firing twice if both old and new providers remain registered during cutover.

Ramp-up Moderate. Developers familiar with Laravel traits and polymorphic relations will pick up HasReaction/CanReact quickly; the real ramp-up is institutional knowledge around the data migration and the new reaction-type model that replaced the enums. Budget a spike plus a paired migration rehearsal, and designate one owner for the production cutover.