- Is oh/emoji-bundle a Laravel package?
- No. It is a Symfony bundle built around a Twig extension, so Laravel has no native bundle loader for it. Laravel developers should treat it as source material or wrap its conversion logic in a service, not expect Composer auto-discovery to wire it up.
- How do I install oh/emoji-bundle in Laravel?
- You should not expect a normal composer require oh/emoji-bundle flow to work cleanly in Laravel. The realistic path is to vendor the converter code into app/Support/Emoji or a first-party package, then expose it through a Blade directive or component. If you keep the dependency, pin it by commit and manually register any services.
- What does oh/emoji-bundle actually do?
- It uses iamcal/php-emoji to build a Twig extension that converts emoji characters, historically described as iPhone emoji icons, into HTML output. The portable part is the codepoint-to-shortname-to-asset mapping and formatter; the Symfony and Twig wiring is incidental.
- Does oh/emoji-bundle work with Laravel Blade?
- Not directly. Its integration point is a Twig extension, while Laravel uses Blade, so you would need to replace that layer with a Blade directive or an x-emoji component. The underlying converter can still be called from Blade if you wrap it in your own renderer service.
- Is oh/emoji-bundle safe to use in production?
- Treat it as unvetted. The package has no visible stars, dependents, tests, or CI in the assessment, so there is no production-use signal. If you vendor it, pin by commit, review the escaping behavior, and own the mapping table yourself.
- Does oh/emoji-bundle handle ZWJ sequences, skin tones, and flags?
- That is the key risk. The assessment warns that multi-codepoint grapheme clusters are hard and that a static mapping can silently miss newer emoji, including ZWJ sequences, skin-tone modifiers, flags, and keycaps. Verify behavior with tests before relying on it for user-generated content.
- Is the HTML output from oh/emoji-bundle escaped by default?
- This must be verified before use. The assessment flags that raw HTML output through Blade's unescaped syntax would create an injection vector if user content is routed through the converter. Require escaped output by default and whitelist generated markup by construction.
- What about accessibility and CSP when converting emoji to sprite HTML?
- Sprite or image replacement can strip semantic meaning unless alt text and role=img are emitted, and CSS background sprites can conflict with strict img-src or style-src policies. You also need to serve and version the sprite sheet correctly. If consistent cross-platform appearance is not a hard requirement, native emoji rendering is simpler and more accessible.
- Does oh/emoji-bundle support Laravel 10 or Laravel 11?
- There is no native Laravel version support to speak of because it is a Symfony bundle, not a Laravel package. Its composer.json likely constrains PHP and Symfony versions, which may not intersect your Laravel runtime. Test any vendored adapter on your exact Laravel and PHP versions.
- Should I use oh/emoji-bundle or native emoji rendering in Laravel?
- Start with native Unicode emoji unless you have a hard product requirement for consistent cross-platform appearance. If you need conversion, build a small first-party renderer around the mapping data and expose it via Blade, rather than adopting the Symfony bundle wholesale. Persist raw Unicode in the database and generate HTML only at the view boundary.