Livewire Jodit Text Editor Laravel Package

Technical Evaluation

Architecture fit. The package is a thin Livewire wrapper around Jodit, delivered as a single Blade component with wire:model two-way binding. There is no service provider to configure, no persistence layer, no PHP API surface, and no second state store beyond the editor's own document. For a Laravel + Livewire app this is the right shape: the editor behaves like a form control, not a subsystem, so it neither earns nor demands architectural review time. The two surfaces we actually govern are the published Blade view (php artisan vendor:publish --tag=livewire-jodit-text-editor-views) and the global browser event update-jodit-content, optionally scoped by an identifier for multi-editor pages. That event is the one abstraction leak: programmatic writes bypass Livewire's parent/child data flow and must be treated as an imperative escape hatch, not a pattern to build features on.

What we are not buying. The scope is the editing surface only — no server-side HTML sanitization, no image/video upload or storage backend, no revision history, no approval workflow, no ACL, no asset version pinning. For expectation-setting: adoption saves roughly one to two engineering days of component plumbing. It does not save the cost of sanitization or the media upload endpoint, both of which we own under any editor choice. Anyone framing this as "rich text solved" should be corrected in the kickoff.

Integration feasibility. Low effort to first render: Composer require, then a choice between CDN <script>/<link> tags or an NPM build importing Jodit and its plugins into app.js/app.scss. Basic usage is one line. The NPM path is the only production-correct choice because it puts Jodit under our lockfile and bundler; the CDN path is an unpinned third-party runtime dependency and is acceptable solely for a spike. The genuinely uncertain area is media: the README documents loading the Jodit resizer and video plugins but never defines an upload endpoint contract. A time-boxed spike must confirm whether uploads wire through Jodit's own config via the options passthrough (v1.10) or require custom handling — before any delivery date is committed.

Technical risk — rated, with owner and mitigation trigger.

Key questions to resolve before committing.

1. Who are the authors — trusted internal staff, or untrusted or public users? This single answer decides whether sanitization is a hardening task or a launch blocker.
2. Where do uploaded images and video go — S3, local disk, an existing media library? Does the upload endpoint need auth, size limits, MIME validation, and scanning?
3. How is stored HTML rendered downstream? Inventory every raw {!! !!} output in the app; each one changes the risk profile immediately.
4. Is this one field on one admin screen, or a pattern we intend to standardize? Scale changes the maintenance calculus from negligible to a standing ownership cost.
5. Do we need capabilities the wrapper does not credibly cover — collaborative editing, comments, track changes, accessibility certification? If yes, stop now rather than after launch.
6. Does the target app run Livewire 3 or 4? Confirm before scoping; the tested path differs.
7. What is the exit cost? Low, because the integration is thin and Blade-isolated — but only if we avoid referencing the component internals or the global event name broadly across the codebase.

Integration Approach

Stack fit. Strong where the app is Laravel + Blade + Livewire 3 or 4. Weak or wrong where the front end is Inertia/Vue/React: in that case the Livewire wrapper is dead weight and the team should consume Jodit directly. The decision gate is therefore one question — is the target screen a Livewire component? — and the answer routes the work, it does not start it.

Compatibility matrix to pin in the ADR. Livewire 3 (longest field exposure), Livewire 4 (since v1.9, newer), Jodit 4.1.x (we pin exactly; package does not), PHP version per the app's existing baseline, and browser targets if authors use low-end hardware or tablets.

Migration path. Two tracks:

• Greenfield field. Composer require → NPM import of Jodit plus resizer/video plugins → publish the view only if styling demands it → place the component inside the existing form request/validation flow → wire sanitization on save.
• Replace an existing editor. Inventory current editor instances and stored HTML first. Toolbar parity is trivial; content parity is not — HTML produced by another editor may carry tags or attributes our allow-list strips on render. Plan a read-time sanitize plus a re-save pass over existing records, and budget that as data work, not UI work.

Sequencing (with decision gates).

1. Confirm Livewire version, target screens, and author trust model. Gate: go/no-go on scope.
2. Time-boxed spike: render, multi-editor page, programmatic update, and — critically — an image upload attempt through options. Gate: upload path proven or custom endpoint scoped.
3. Security work: server-side sanitizer, allow-list, sanitize-on-save and sanitize-on-render for legacy rows.
4. Media endpoint: auth, size/MIME limits, storage target, CDN/transform story.
5. Component hardening: wire:navigate duplicate regression test, error-state re-render behavior, debounce policy for wire:model.live on long forms.
6. Ship to one screen, then open a PR template and short usage doc before any second adoption.

Operational Impact

Maintenance. Assign a named owner — a front-end-capable engineer — at adoption, not after the first incident. Standing obligations: pin and bump Jodit deliberately, watch upstream releases (the changelog shows the brittle seam is Livewire lifecycle, not editing features), and keep the fork-and-own option documented. If this becomes a standardized pattern across many editors, the cost shifts from negligible to a recurring line item of a few days per year plus upgrade risk on each Livewire major.

Support. No vendor SLA. Upstream support is GitHub issues from a single maintainer; our support is our own team. Documentation is adequate for install and basic usage, thin on media upload and on server-side content handling — the two areas that generate the tickets. Write the internal runbook covering "editor duplicates after navigation," "content out of sync after validation error," and "why did my pasted content lose formatting," because those will be the first three tickets.

Scaling. Two axes. Client-side: multiple Jodit instances on one page multiply JS cost, so cap instances per screen and lazy-init where possible — low-end hardware and tablets are the constraint, not servers. Round-trip: wire:model.live sends HTML on every keystroke-adjacent change, which is heavy for long documents; use debounce or plain wire:model for large bodies. Storage: HTML blobs grow and cannot be diffed cheaply; if revision history is ever needed it is a new subsystem, not a config change.

Failure modes to plan for. Duplicate editor instances after wire:navigate (known seam, repeated fixes upstream); content desync when Livewire re-renders on validation failure; global update-jodit-content event collisions on pages with unrelated editors; unpinned CDN asset disappearing or changing; XSS through stored HTML rendered outside the trusted author group; upload endpoint abuse if it ships without limits; silent sanitization stripping content that authors believed was saved. Each one maps to a named test or a named control — none should be discovered in production.

Ramp-up. Engineering: under a day for a Livewire-fluent developer. Content authors: a short guide on the restricted toolbar and what happens to pasted formatting. QA: a specific checklist for the navigate/re-render seams, without which "the editor is broken" reports are unactionable. Product: explicit statement in the release notes that rich text fields are sanitized on save and that unsupported formatting is dropped by design.

Recommendation. Fund it as a time-boxed spike for a scoped, internal, trusted-author use case with sanitization as a launch gate. Do not mandate it as a product standard until it has survived one real feature shipped to production and one Livewire or Jodit upgrade without incident.