Filament Lexical Editor Laravel Package

Technical Evaluation

Architecture fit. The package is a thin Filament form-field wrapper around Meta's Lexical editor: a PHP Field subclass, a Blade view, and a JavaScript bundle that mounts Lexical against a Livewire-bound state property. That is the right shape for the TALL stack — no server-side rendering service, no separate Node process, no database opinions imposed. It slots into a panel's form schema the same way the native RichEditor does, so the architectural blast radius is confined to the authoring surface.

The critical misalignment is the data contract. Filament's native RichEditor is Trix-based and stores HTML. Lexical persists an EditorState as a versioned JSON tree. Swapping fields is therefore a storage-format migration, not a drop-in replacement — and the package does not ship a PHP or headless-JS renderer to turn that JSON back into HTML for Blade views, emails, PDFs, API responses, or search indexing. Until that render path exists and is owned internally, the package is half a solution. This is the single largest architectural gap and should drive the adoption decision.

Integration feasibility. Mechanically trivial: composer require, register the field's assets in a service provider or panel config, add LexicalEditor::make('content') to a schema. A competent Filament developer reaches a working demo in an afternoon. Production readiness is a different number — realistically 2–4 weeks of engineering for the render pipeline, sanitization, validation rules, migration of one content type, and end-to-end tests.

Technical risk. High, and concentrated in vendor risk rather than code risk:

• Ecosystem signal is near-zero. 16 stars, 0 dependents. No downstream projects means no proven integration paths, no community-discovered edge cases, and no de facto regression testing against new Filament releases.
• Bus factor of one. Filament ships a major version roughly annually with breaking changes to form-field APIs and asset registration; Livewire majors land on a similar cadence. A solo maintainer with no dependents has little incentive to keep pace, and no external pressure forcing it.
• Lexical is a moving target. Meta's editor has historically shipped 0.x releases with breaking changes and, importantly, a node-versioning/migration model for serialized state. A wrapper that pins an old Lexical build will eventually fail to deserialize content authored in a newer one — and that failure is silent data corruption, not a visible bug.
• Sanitization is unowned. Rich-text JSON can carry arbitrary node types, links, and pasted HTML. The package almost certainly does not implement Filament's file-attachment, image-node, or content-sanitization affordances that the native editor provides.
• Livewire payload weight. Editor state round-trips on every wire:model dehydration; long documents can bloat requests and trip size limits without debouncing and dehydrateStateUsing discipline.

Key questions to put to the maintainer (or answer by reading the source):

1. Support matrix: Filament v3 vs v4, Livewire 3, Laravel 10/11/12, PHP 8.1+?
2. Does it ship prebuilt dist/ assets, or require npm install && npm run build inside vendor/? The latter is a serious CI/Docker constraint.
3. What is the documented storage format, and is there any supported JSON→HTML renderer?
4. Which Lexical plugins are exposed (mentions, tables, images, code blocks, links) and how extensible is the plugin surface?
5. Is there CI, a test suite, and dependency automation? What is the maintainer's stated support commitment?
6. How are paste sanitization and file uploads handled, if at all?

Integration Approach

Stack fit. Laravel 10–12, Livewire 3, Filament 3.x, Alpine for the mount lifecycle, Tailwind for chrome. No new runtime infrastructure. The only new build-time dependency is the editor's JS bundle.

Migration path. Do not migrate existing RichEditor columns. Introduce Lexical as a parallel field on new content types, or add a content_json column alongside the existing content_html, dual-writing during transition. Legacy HTML→Lexical backfill is lossy and should be treated as a separate, explicitly-scoped project — not a launch prerequisite.

Compatibility posture. Pin the package to an exact version, commit the lockfile, and vendor or publish the built assets into your own repo so a composer update cannot silently change editor behavior. Treat the package as a fork-from-day-one: mirror it into an org namespace you control.

Sequencing.

1. Spike (2–3 days). Sandbox panel; confirm asset registration, Livewire binding, persistence, and paste behavior. Explicitly test the npm-build question and a Filament minor upgrade.
2. Render path (1–2 weeks). Decide client-side headless render vs. a PHP converter; build it, sanitize with HTMLPurifier, and add a golden-file test corpus of editor states.
3. Server-side validation. Editor constraints are advisory only — enforce node allowlists, length caps, and link policies in FormRequests.
4. Pilot one low-risk content type in an internal admin surface, not customer-facing.
5. Harden. Playwright/Dusk coverage for mount, save, reload, and a Lexical-version upgrade.
6. Codify the fork policy — owner, cadence, and upgrade runbook — before the second consumer adopts it.

Operational Impact

Maintenance. Budget for internal ownership within two quarters. A 16-star, single-maintainer package with no dependents should be assumed to be unmaintained at some future point; the fork is the mitigation, not the contingency. Ongoing cost is small but non-zero: Lexical version bumps, Filament major upgrades, and npm advisory triage.

Support. No SLA, no paid tier, GitHub issues only. Internal runbook and a named owner are mandatory. Escalation ends at your own engineers.

Scaling. The Lexical core plus plugins adds meaningful client JS weight to the admin bundle — acceptable behind auth, not acceptable for public pages. JSON state is materially larger than equivalent HTML; plan for JSON/LONGTEXT columns, consider compression for large documents, and watch Livewire request sizes. If content is ever rendered on public pages, the JSON→HTML path becomes a latency and SEO concern requiring caching.

Failure modes to instrument:

• Assets not published after deploy → editor renders blank; add a smoke test on every deploy.
• Lexical node-version drift → previously saved content fails to deserialize; add a deserialization check in CI against a stored corpus.
• Editor crash on paste → unsaved content loss; require autosave/draft persistence independent of the field.
• Oversized Livewire payload → 413/validation errors on long documents; debounce and cap.
• Fork divergence from upstream → security patches missed; schedule quarterly upstream diffs.

Ramp-up. Filament-familiar developers are productive in hours; the new skill is Lexical's node/plugin model and its serialization contract, which is a genuine 1–2 day investment per engineer plus documentation. Because the ecosystem has no tutorials or community answers for this specific wrapper, internal docs are the only knowledge base — write them during the pilot, not after.

Recommendation. Conditionally viable for an internal, low-blast-radius authoring surface with a small number of content types, provided the team accepts the fork and owns the render path. Not recommended for customer-facing, long-lived, or high-volume content without that ownership commitment in place. Decision gate: proceed past the spike only if the render path and asset-build story are resolved and the maintainer answers questions 1–3 satisfactorily.