Engageify Laravel Package

Product Decisions This Supports

• Adopting a prebuilt engagement layer instead of building one. Engageify gives you polymorphic engagement records and per-engager counters (likes, reactions, upvotes — whatever your Verb enum expresses) that attach to any model. That removes a whole class of sprint work: schema design, counter reconciliation, unique-index correctness, polymorphic relation plumbing.
• Shipping emoji/reaction-style features on the roadmap. The v2.1.2 fix confirms the package models reaction type as a backed enum value that can be an emoji. If your roadmap includes reactions rather than a binary like, this is directly supported — but only on a version where the collation bug is fixed (see below).
• Database choice is no longer a blocker. Through v2.1.1, MySQL and MariaDB were effectively unsupported: the engagement_counters table could not be created at all due to a 69-character auto-generated index name against MySQL's 64-character limit. Any product decision that assumed "we're a MySQL shop, so we can't use this" should be revisited. v2.1.2 is the first v2 release installable on MySQL/MariaDB.
• Build-vs-buy framing: buying (adopting) is defensible for the counter/polymorphic layer. It is not a decision to outsource engagement UX — feed ranking, notification fan-out, abuse handling, and analytics remain yours.
• Multi-emoji per user per object is now viable on MySQL. Previously, utf8mb4_unicode_ci gave many emoji identical sort weights, so the unique index collapsed an entire emoji set into one row and one counter. If your product spec says "a user can add multiple distinct reactions," that spec is only satisfiable on MySQL from 2.1.2 onward.

When to Consider This Package

Consider adopting when:

• You need engagement primitives (likes/reactions/upvotes) attached to more than one model, and you don't want to hand-roll polymorphic tables and counters.
• You are on Laravel and comfortable with vendor:publish + migration-based install.
• Your production engine is MySQL/MariaDB (now supported) or SQLite/Postgres.
• Your enum values may include emoji, and you need each distinct emoji to be a distinct counter.
• You can pin a minimum version (^2.1.2) and add a migration smoke test in CI.

Look elsewhere or proceed with caution when:

• You are on MySQL/MariaDB and cannot pin v2.1.2+. Earlier v2 releases simply do not install. Treat 2.1.2 as the floor, not a nice-to-have.
• You write raw SQL against engagements.type. The column is now pinned to utf8mb4_bin on MySQL/MariaDB, which is byte-exact and therefore case-sensitive. The package itself always writes and matches enum values verbatim, so internal behavior is unchanged — but any hand-written query using differently-cased text will silently stop matching. Audit reporting/BI queries before upgrading.
• You require vendor CI coverage on your engine. MySQL and MariaDB are not in the package's CI matrix; the suite runs on SQLite. The bug fixed here is precisely the class of defect that SQLite-only CI misses. Mitigate with your own migration test against a real MySQL instance rather than assuming parity.
• You need a counter rebuild path. Not applicable to MySQL (no v2 install existed there), but worth noting the release explicitly states no rebuild is needed only because of that fact.
• You're already on v2.1.1 on SQLite/Postgres and don't use emoji values. The upgrade is low-risk and largely a no-op outside MySQL, so this is a "take it in the normal cadence" case rather than an urgent one.

Upgrade action (for engineering): re-publish migrations and migrate — php artisan vendor:publish --tag="engageify-migrations" then php artisan migrate. This applies pin_engagement_type_collation, which converts the type column in place on both tables and is a no-op on non-MySQL drivers.

How to Pitch It (Stakeholders)

For executives: We evaluated Engageify, a Laravel package that provides the engagement plumbing behind likes, reactions, and upvotes — the counters and polymorphic links, not the UI. The headline is that a long-standing blocker is gone: the previous v2 releases could not be installed on MySQL or MariaDB at all, which is our engine. As of v2.1.2 the package installs and works correctly across supported databases, including distinct counters for distinct emoji reactions. Recommendation: adopt at ^2.1.2 if engagement is on the roadmap; it replaces custom-built counter infrastructure with a maintained dependency at low integration cost.

For engineering: v2.1.2 makes MySQL/MariaDB installs possible for the first time in the v2 line — an unnamed index overflowed MySQL's 64-character identifier cap and the table creation failed outright; the index now has an explicit name. It also pins engagements.type and engagement_counters.type to utf8mb4_bin on MySQL/MariaDB, because utf8mb4_unicode_ci gave many emoji identical sort weights and the unique index was merging them into a single row. Practical consequences: (1) pin ^2.1.2 as the minimum; (2) type is now case-sensitive on MySQL, so audit any raw queries against that column; (3) the package's CI still runs only on SQLite, so add a migration smoke test on MySQL in our own pipeline before rollout. Upgrade is re-publish migrations plus migrate; the collation migration is in-place and a no-op on other drivers, and no counter rebuild is required.

Bottom line: the release converts a hard "no" into a qualified "yes." The qualification is our own test coverage, not the package's feature set.