Filament Advanced Rich Editor Laravel Package

Technical Evaluation

Architecture fit

Unchanged at the core: the package is a Filament v5 form field extending RichEditor, inheriting the standard schema-component lifecycle — ->make(), state binding, validation, Livewire dehydration. Adoption remains a per-field class swap, resource by resource, behind a flag.

Two things in v1.7.0 sharpen the architectural picture:

• The editor engine is now confirmed. The release notes reference TipTap directly ("until TipTap first shows one"). That answers half of our open question — we know the engine, so CVE tracking and the ceiling on extension work are now traceable. The pinned version of TipTap is still unstated and must be verified.
• The front end has been decomposed into discrete Alpine modules. menu-position.js, image-panel.js, color-picker.js, font-size-picker.js, plus the pre-existing media browser, are now separate assets loaded via x-load-src / x-load-css. This is a better architecture than inline x-data blobs, but it means the field is now a small JS application with a lazy-loading manifest. The CSP conversation is no longer "add a nonce"; it is "verify dynamic script/style injection under our CSP, on our panel, before rollout."

The MediaSource / ReplacesMedia seam and the mediaLibraryDocuments registry remain the two extension points a TPM must own. Nothing in this release changes their shape.

Integration feasibility

Still low code churn, moderate configuration work. v1.7.0 adds two mandatory upgrade mechanics that did not previously exist:

1. Asset publishing is now load-bearing. The stylesheet is split in two; the overlay sheet (filament-advanced-rich-editor-overlays.css) is not published by the package and is loaded at editor start. Skip php artisan filament:assets and pickers, menus, media browser, find/replace and dialogs render unstyled — not broken, but visibly wrong and plausibly mistaken for a CSS bug. This must be a step in the deploy pipeline, not a README footnote.
2. Published configs drift. description_list, invisibles, and the new tools_menu entries do not appear in an already-published config. Republishing overwrites — so the upgrade procedure is publish-to-a-temp-path, diff, merge. Every minor from here on may add config keys.

Technical risk

The dominant risk remains adoption, not technology: still a single maintainer, still a thin downstream base. What v1.7.0 does change is the character of that risk — the release is a deep, measured performance pass with server timings, first-frame timings, long-task counts and byte counts quoted throughout. That is the work of someone instrumenting their own package. It is a strong positive signal on engineering quality, and it is still not a support commitment.

Risk profile changes:

• Asset surface — materially reduced. Panel-wide CSS drops from 128 KB (31 KB gzipped) to 80 KB (20 KB) on every page, with overlays deferred. Per-editor markup shrinks by tens of KB (≈50 KB from menu-position.js alone, ≈20 KB from hoisted emoji/character strings, ≈10 KB from icon de-duplication, 49 KB across five editors from the image panel). My earlier "measure the asset surface" caveat stands but is now a much smaller number.
• Render cost — reduced. Twenty editors in a repeater: 5.1s → 3.6s to first frame. Five editors: 430 → 172 ms server-side, 355 ms of long tasks → none. Multi-editor pages were the realistic worst case for us; that worst case is now roughly a third cheaper.
• Localization risk — changed shape, not removed. Twelve languages now ship, but ten are AI-translated and explicitly unreviewed by native speakers; the parity test holds them against English only. If our editors are non-English, treat these as draft translations requiring native review, not as shipped localization.
• Filament minor-version coupling — now demonstrated. A toolbar/picker positioning regression on Filament 5.10 is fixed here. Good: the maintainer tracks Filament minors. Bad: Filament minors can visibly break this field, which is the argument for pinning both sides.
• JS test surface. Behaviour that was previously asserted as strings in PHP is now tested as JavaScript. Better coverage of the things that actually break; also a new toolchain (build, test runner, four-plus lazily loaded modules) inside our dependency graph.

Unchanged risks: cascading reference rewriting on delete/replace (transactionality still undescribed — I did not see it addressed), browser-local drafts, no version support policy, no security disclosure process described.

One new behavioural risk worth naming: enabling definition lists over an existing run of paragraphs converts "every other one" into a term. That is a content-mutating edit with a plausible-but-wrong default if an editor toggles it on a pre-existing block. The feature is off by default, which is the right call.

Key questions

1. Which TipTap version ships in the bundle, and who patches its advisories? (Engine now known to be TipTap; version still open.)
2. Does delete/replace run inside a database transaction across target models, and is there a dry-run mode? (Not addressed in 1.7.0.)
3. Is reference rewriting tree-based or regex/string-based?
4. Do x-load-src / x-load-css respect a nonce-based CSP, and is that tested?
5. Is the overlay stylesheet guaranteed to be injected after the panel theme in a non-default panel (custom viteTheme, multiple panels)?
6. What is the supported upgrade procedure for published configs across minors — is there a documented diff/merge path, or is republish-and-overwrite the expectation?
7. Is php artisan filament:assets documented as a mandatory post-upgrade step, and is there a version-check that fails loudly rather than rendering unstyled overlays?
8. Is there any intent to commission native review of the ten AI translations, and which locale fallbacks are exercised?
9. How is server-side authorization enforced for delete/replace (policy vs. closure), and can it be bypassed?
10. Is there a security disclosure process, and a stated Filament major-version support window?
11. What happens to existing stored HTML on first render — is the document format backward-compatible? (Definition lists are stated to render whether or not the feature is enabled, which is a good sign for forward compatibility; the reverse direction is unverified.)
12. Does it coexist with other packages that extend RichEditor, or does it collide?
13. What are the licenses of TipTap and any vendored plugins?

Integration Approach

Stack fit

Unchanged hard gate: Laravel 11/12, PHP 8.2+, Filament v5, Livewire 3, Alpine. Spatie Media Library v11 for the attachment feature. Filament v3/v4 estates cannot use this and there is no downgrade path.

One addition: because the package now ships a JS build with lazy-loaded modules and an unhashed overlay stylesheet, the deployment target must run php artisan filament:assets as part of release, and the panel must permit runtime x-load-src / x-load-css under whatever CSP is in force. If assets are baked into an immutable container image, the publish step belongs in the image build, not at container start.

Migration path

Per-field swap remains mechanical. The non-mechanical parts are unchanged (content round-trip fidelity, media marker syntax backfill) plus one new one: config drift. Published configs from a prior 1.x will not gain description_list, invisibles, or the new tools_menu entries. Plan a publish-and-diff step into every minor upgrade rather than treating the config as static.

If we are already running a 1.x, treat 1.7.0 as a deploy-gated change: publish assets, publish-and-merge config, smoke-test the overlay UI (pickers, menus, media browser, find/replace) before promoting.

Compatibility

• Verify CSP against x-load-css and x-load-src specifically, not just the main bundle.
• Verify overlay stylesheet ordering against a custom panel theme — the notes state it is placed ahead of the panel theme so theme overrides keep winning, but this needs to be observed in our panel, not assumed.
• Pin the package version and Filament minors together. The 5.10 toolbar regression is the proof case: a Filament patch release broke picker positioning.
• Confirm no collision with existing RichEditor extensions in the same panel.

Sequencing

1. Spike (1 week). Install in a scratch panel, exercise every advertised feature against a copy of real production content. Record round-trip fidelity, bundle size, and measured multi-editor render time against our own repeater shapes — the release notes give numbers, but ours will differ.
2. Upgrade mechanics. Wire php artisan filament:assets into the pipeline. Establish the publish-and-diff config procedure. Both before any content work.
3. Media decision. Spatie Media Library vs. a MediaSource implementation over the existing DAM.
4. Registry build. Enumerate every model+column that embeds media; this defines mediaLibraryDocuments.
5. Authorization design. Restrict mediaLibraryDeletable to a named admin role; replace to content leads. Policies written before the UI is enabled.
6. Pilot. One resource, one team, feature-flagged. Keep stock RichEditor selectable at runtime.
7. Progressive rollout by resource type, gated on no content-integrity incidents in the previous wave.
8. Contingency. MIT permits forking; keep a maintained fork branch and a named internal owner from day one. The fork now includes a JS build, which raises the cost of a fork slightly — budget for it.

Operational Impact

Maintenance

Assume we may own patches. Budget roughly 1–2 engineer-days per month for dependency tracking (Filament minors, TipTap, Spatie Media Library) plus unplanned fixes; the 5.10 positioning regression is a realistic example of the unplanned kind. Assign a named maintainer. Track TipTap advisories directly — we now know the engine, so there is no excuse not to.

Two new maintenance line items: the asset-publish step must survive in the deploy pipeline (someone will "optimise" it out), and published configs must be re-diffed on each minor.

Support

Still no commercial support, no SLA, GitHub issues only. Internal support cost is unchanged and dominated by editor helpdesk tickets. v1.7.0 adds visible tools that will generate questions — "Show blocks" (which labels everything P, H2, LI) and "Show invisible characters" are power-user views that will alarm non-technical editors if discovered accidentally. Both are non-destructive and reset per page load, but the editor guide should name them and say what they are for. The AI-translated locales should not be presented to non-English editors as reviewed translations.

Scaling

• Front-end weight — improved. Panel-wide CSS is down ~37% (128 → 80 KB raw, 31 → 20 KB gzipped), with overlays deferred until an editor starts. Editor markup is substantially smaller. This was my largest scaling concern and it has been addressed with evidence.
• Multi-editor pages — improved. Repeaters were the pathological case; 20 editors at 5.1 → 3.6s first frame and long tasks eliminated at five editors makes dense forms viable.
• Storage/CPU — unchanged. Spatie still re-runs conversions on replace; queue sizing still required.
• Rewrite cost — unchanged. Reference propagation is still O(records referencing the file). A logo in 400 documents is still 400 rows in one request. Chunk or queue before it becomes an incident.
• Drafts — unchanged. Browser-local, no server cost, no cross-device continuity. Copy must say so.

Failure modes

Ramp-up

Developers: low, with one addition — whoever owns the deploy pipeline must understand the asset-publish and config-diff steps, or the first minor upgrade ships a broken-looking editor. Content editors: medium, unchanged in substance; add a line to onboarding about the two new view toggles so nobody files a ticket about the ¶ symbols. The definition-list command needs a one-line warning: don't toggle it on a block of existing paragraphs you care about. Ops/admin: moderate, focused on storage growth and shared-file deletes.

Verdict for a TPM

v1.7.0 materially improves the two operational objections I raised in the previous assessment — panel-wide CSS weight and multi-editor render cost — and does so with quoted measurements rather than adjectives. It also fixes a Filament 5.10 regression, which is the first evidence that the maintainer tracks Filament minors in practice rather than in principle. Combined with the move from PHP string assertions to real JavaScript tests, this is a package being engineered rather than merely published.

None of that changes the structural position: still a single maintainer, still a thin downstream base, still no support policy. Adoption posture is unchanged — internal admin tooling where we can tolerate and patch breakage, feature-flagged with a stock-RichEditor fallback, a fork kept warm, and nothing customer-facing or compliance-critical until it has survived a full Filament upgrade cycle in our hands. What has changed is the cost of that posture: the runtime overhead argument against it is now much weaker, and the upgrade checklist is longer by two items (asset publish, config diff).