Laravel Emoji Laravel Package

Product Decisions This Supports

• User-generated content rendering (posts, comments, chat, DMs, notification emails). This package turns stored shortcodes (:smile:) into rendered emoji through the emoji() helper and @emoji Blade directive. It underpins the decision to store portable shortcodes in the database and render at display time rather than persisting raw emoji glyphs — which keeps content readable across exports, emails, SMS/push fallbacks, and search indexing.
• Platform upgrade sequencing (PHP 8.3+ / Laravel 13). 3.0.0 is the version that lives on the Laravel 13 baseline. That makes it a dependency gate on the Laravel 13 migration roadmap: the upgrade is now unblocked for any surface that renders emoji, and it must be scheduled inside — not after — the framework upgrade workstream.
• Vendor/licensing risk on emoji assets. The fix replacing the obsolete Emojione client with JoyPixels retires a client whose upstream is no longer the supported path. For a PM this is a compliance-adjacent cleanup: fewer "why are we shipping an abandoned third-party renderer?" questions at review.
• Build vs. buy. Do not build emoji shortcode parsing, a shortcode-to-glyph map, or a Blade directive in-house. The scope is small, the regression surface is well understood (11 assertions against the original helper), and the cost of ownership in-house is permanently higher than a pinned dependency.
• Support matrix and docs hygiene. Corrected documentation and config publishing tag means onboarding and internal runbooks can be trusted; the removal of cghooks lifecycle scripts restores normal composer install, which removes a recurring "install fails on a clean machine" support ticket class in CI and new-hire setup.

When to Consider This Package

Adopt when:

• You are on PHP 8.3+ and Laravel 13 (hard requirement in 3.0.0) and need shortcode → emoji rendering in Blade or PHP.
• You store user content with shortcode syntax and want consistent rendering across web, email, and API surfaces from one code path.
• You want a thin, single-purpose integration rather than a full emoji picker or moderation stack — this package renders; it does not provide the picker UI, search, or moderation.
• You value a small dependency with a documented, tested upgrade path over a bespoke helper.

Look elsewhere (or stay pinned) when:

• You are still on PHP < 8.3 or Laravel < 13 — 3.0.0 will not install. Stay on 2.x and treat the upgrade as blocked on the framework migration; do not fork to "just make it work."
• You only ever handle native Unicode emoji end to end. If nothing in your pipeline emits shortcodes, you are paying a dependency for a conversion you never perform.
• You need custom/branded emoji sets, sprite hosting, or CDN asset control — plan for your own asset pipeline on top; this package resolves a client, it does not manage your emoji art.
• You require heavy supply-chain assurance (multi-maintainer, formal security SLA). This is a small, single-maintainer utility; scope it accordingly and rely on Composer audit in CI rather than assuming vendor guarantees.
• You need richer content features (reactions, pickers, autocomplete) — those are product features to build or buy separately; this is only the rendering primitive.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, low-risk presentation-layer dependency that we already rely on, and the new major version is the one that keeps us compatible with our Laravel 13 / PHP 8.3 platform plan. The upgrade carries no product-facing behaviour change beyond retiring an obsolete emoji renderer, and it has been regression-verified against the existing helper. Cost is measured in engineering hours, not roadmap scope; the risk of not taking it is accumulating an unsupported dependency on a framework version we are leaving behind.

To engineering: Treat 3.0.0 as a platform floor bump, not an API redesign — the helper and Blade directive signatures are unchanged, so migration effort is version pinning plus verification. Three things to check before merging:

1. Confirm the runtime matrix in CI (PHP 8.3/8.4/8.5, Laravel 13) matches our production target; older images must be upgraded or the package stays pinned.
2. Re-publish config if we ever published it — the documented config publishing tag changed in this release, so stale published config will silently point at the wrong values.
3. Diff rendered output on a sample of real user content: the switch from Emojione to JoyPixels can change glyph/asset rendering. Visual QA on the feed, comment thread, and notification email templates is the actual acceptance test.

Run composer audit and the code style checks in CI, ship behind the Laravel 13 upgrade branch, and keep the 2.x pin available for rollback until the visual diff is signed off.