Rich Editor Fullscreen Laravel Package

Technical Evaluation

Architecture fit. The package is a narrow, presentation-layer extension for Filament V4's RichEditor form component (Tiptap-based). It should sit entirely in Filament's front-end asset pipeline — a service provider registering a JS/CSS bundle via FilamentAsset::register() plus a toolbar/extension hook into RichEditor. That means it should not touch our domain model, persistence, or content serialization: editor content remains Filament's HTML/JSON payload, and fullscreen is purely a viewport concern. Architecturally this is a low-blast-radius addition, which is the main thing in its favor.

Integration feasibility. Expected path is composer require mdobes/rich-editor-fullscreen, then registering the plugin in the relevant PanelProvider::plugins([]), with an optional per-field opt-in. Effort is measured in minutes, not days, provided we are already on Filament V4. Because it depends on RichEditor internals (toolbar button registration, Tiptap extension surface), the real integration risk is not our code but the coupling to Filament's editor API.

Technical risk.

• Maturity signal is weak. 9 stars, 0 dependents, a single apparent release, and a composite score of ~19.9 indicate essentially no ecosystem validation. There is no evidence of production usage to borrow confidence from.
• Version coupling. Filament's RichEditor and asset APIs move between minor releases; a package this small likely declares a loose constraint it cannot actually honor. A Filament bump could silently break toolbar registration.
• Toolbar contention. Any existing custom toolbar buttons, Tiptap extensions, or other RichEditor plugins are the most likely source of conflict — button ordering, extension duplication, or Alpine/component lifecycle clashes.
• Runtime context. Fullscreen inside Livewire + Alpine + wire:navigate needs care around focus trapping, ESC handling, body scroll lock, z-index against Filament modals, and state teardown on navigation. These are the classic failure points for "small" editor plugins.
• Asset delivery. Whether it plays correctly with Filament's Vite-based asset publishing, SPA mode, and a strict CSP is unverified.

Key questions for the maintainer / spike.

1. Exact supported matrix: Filament ^4.x minors, PHP, Laravel, Livewire versions — and is it tested in CI across them?
2. Is it a Panel plugin, a per-field API (->fullscreen()), or both? Can it be scoped to selected fields?
3. Does it wrap Tiptap's official Fullscreen extension or reimplement it? What happens to toolbar customization we already own?
4. Accessibility and mobile: focus trap, keyboard exit, screen-reader labeling, touch behavior, dark mode.
5. Interaction with wire:navigate/SPA mode and with Filament modals already open.
6. Test coverage and license/contribution posture (MIT confirmed; is a fork acceptable?).

Integration Approach

Stack fit. Native to the TALL stack and specifically to a Filament V4 panel — no impedance mismatch, no new runtime, no server-side footprint. If our admin surface is Filament, this is the cheapest possible shape of dependency: a Composer package plus one provider line.

Migration path. Additive and reversible. There is no schema change or data migration to plan; content written with the plugin enabled is byte-identical to content written without it. Removal is composer remove plus deleting one array entry, with graceful degradation to the stock editor. That reversibility is the strongest argument for trying it rather than building it.

Compatibility. Two hard preconditions: (a) we must already be on Filament V4 — this is not a backport to V3; (b) our panels must not already own a conflicting RichEditor toolbar customization, or we must reconcile the two. Verify declared constraints against our locked Filament version before merging, and re-verify on each Filament minor.

Sequencing.

1. Confirm Filament V4 baseline and inventory every existing RichEditor customization across panels.
2. Spike in a non-production panel: install, register, exercise with our real custom toolbar and a large document.
3. Test the sharp edges — wire:navigate transitions, nested modals, CSP headers, mobile, keyboard-only use.
4. Roll to one production panel behind a feature flag; gather editor UX feedback for one iteration.
5. Expand to remaining panels; document the opt-in pattern and the pinning policy.
6. Record an exit plan (fork or drop) at the same time as adoption.

Operational Impact

Maintenance. The package is small enough that the honest answer is: we are one Filament minor release away from owning it. With MIT licensing and a minimal surface, forking or vendoring is a realistic and cheap contingency — budget a few hours, not a sprint. Pin the version explicitly, and add a checklist item to the Filament upgrade runbook to re-test the fullscreen toggle.

Support. Community-only: GitHub issues, single maintainer, no SLA, no security response process to rely on. Given the package executes client-side JS in an admin panel, treat it as trusted-but-unaudited and review the bundle once before shipping. Escalation path is internal, not upstream.

Scaling. Effectively free. It is client-side only, adds a modest JS/CSS payload per editor-bearing page, and introduces no server, queue, or database load. The scaling concern is organizational, not infrastructural: the number of panels and Filament versions we must keep in sync.

Failure modes.

• Silent degradation — the fullscreen button simply disappears after a Filament upgrade; low severity, high detectability if we smoke-test.
• JS exception in the editor — breaks the whole RichEditor, not just fullscreen; this is the severe case, and it argues for a feature flag.
• CSP or asset-pipeline rejection — button present but inert.
• Stale state across wire:navigate — body scroll locked or a fullscreen overlay left mounted after navigation.
• Z-index/modal collision — fullscreen editor trapped under a Filament modal.
• Bundle conflict — duplicate Tiptap extension registration alongside another editor plugin.

Ramp-up. Trivial for any Laravel/Filament developer: under an hour to first working toggle, provided README-level docs exist. The real onboarding cost is the tribal knowledge of which panels opted in and why the version is pinned — capture that in the same PR.

TPM recommendation. Adopt as a time-boxed spike with a pinned version and a feature flag, on the explicit understanding that we may internalize the code. The economics are favorable (days of avoided UI work for a small, reversible, MIT-licensed dependency), but the 9-star / 0-dependent profile means we should not treat upstream as load-bearing. The decision to revisit is any Filament minor upgrade, or the first sign of maintainer inactivity.