- Is flexible-ux/lexical-bundle a Laravel package?
- No. It is a Symfony bundle that ships a FormType rendering Meta's Lexical editor through AssetMapper, a Stimulus controller, and UX Icons. Laravel has no FormType abstraction and no AssetMapper, so the package cannot be installed as a Composer dependency and used directly. For Laravel teams the transferable value is the pattern, not the code: treat it as a reference implementation to port into a Blade component with Vite.
- How do I install flexible-ux/lexical-bundle?
- You install it with Composer into a Symfony 6.3+ or 7.x application that already uses AssetMapper, since the bundle requires symfony/ux-stimulus, symfony/ux-icons, and the AssetMapper pipeline. After installation you map the Lexical packages into your importmap and register the bundle's Stimulus controller. There is no Laravel service provider, config file, or artisan command, so nothing about the install path applies to a Laravel app.
- Can I use this editor in a Laravel application with Vite?
- Not as-is. AssetMapper is a hard dependency and conflicts with Webpack Encore while sitting awkwardly next to Vite, so you would be changing your asset pipeline before even evaluating the bundle. The realistic Laravel route is a port: a Blade component that mounts Lexical, a Vite entry that pulls lexical plus the packages needed for your toolbar, and a Stimulus or Alpine controller to drive it. Budget that as a build, not an install.
- What Symfony, PHP, and Lexical versions are supported?
- The documented target is Symfony 6.3+ and 7.x on PHP 8.1+, with UX Stimulus and UX Icons required. The supported Lexical JS version matrix is not documented, and it is unclear whether the @lexical/* dependencies are pinned or floating. Check the repository's composer.json and importmap before committing, and pin Lexical yourself in a port so an upstream release cannot silently break the editor.
- Does the form type persist HTML or Lexical JSON, and how do I render it server-side?
- This is the single biggest unknown. Lexical's canonical state is a serialized JSON node tree, not HTML, and the bundle does not document clearly which format its form type binds to. If JSON is persisted, every downstream consumer such as search indexing, email rendering, PDF export, RSS, and API responses needs a PHP-side JSON-to-HTML renderer that almost certainly does not exist. If HTML is persisted, you must verify round-trip fidelity on every editor load before trusting it.
- Does the bundle handle XSS sanitization?
- No. Sanitization sits outside the bundle's scope, and a rich-text widget that accepts pasted input with a server-side persistence path always needs it. Add a sanitization layer on save and again on render, using Symfony HTML Sanitizer or HTML Purifier, and define an allowed tag and attribute list. In a Laravel port the equivalent is a dedicated sanitizer step in your form request or model mutator, never trusting the browser.
- How does AssetMapper resolve the @lexical/* JavaScript packages?
- Through importmap:require, which is the usual friction point for third-party packages. Lexical is a multi-package dependency tree, so importmap resolution on a cold install is the practical unknown and should be tested before adoption rather than assumed. If you are porting to Laravel with Vite, this problem disappears because npm resolves the graph for you, but you take on a build step instead.
- Is the bundle production-ready and actively maintained?
- Treat it as pre-adoption. The project has roughly nine stars and zero dependents, which means no production validation, no community bug surface, and a likely bus factor of one. Before relying on it, check commit cadence, whether there is any CI or end-to-end coverage of editor bootstrapping, and who responds to issues. The persistence-format and sanitization gaps are the risks that matter more than raw code quality.
- Can I adopt it for a single field and migrate existing CKEditor or TinyMCE content?
- In Symfony the form type is drop-in at the add('body', LexicalType::class) call site, so you can swap one field behind a feature flag, keep the old editor elsewhere, and compare output for a release cycle. Content stored by a legacy editor will not carry over automatically, because Lexical works with its own node schema rather than raw HTML. Plan a conversion pass and decide up front whether you are storing Lexical JSON or normalized HTML.
- What are the alternatives for a Laravel team that wants Lexical?
- You can build a thin Lexical integration yourself with a Blade component, Vite, and a Stimulus or Alpine controller, which gives you full control over serialization and sanitization. If you would rather not own that, TipTap and Trix have mature Laravel-friendly wrappers, and CKEditor and TinyMCE remain the low-risk HTML-first options. The Lexical bundle is worth reading for its editor-mounting approach, but it is not a dependency a Laravel codebase can adopt.