Lilac Laravel Package

Technical Evaluation

Architecture fit. Unchanged in substance, but the new release notes sharpen the picture. Lilac is still a client-side WYSIWYG editor whose real integration surface is the browser, and v0.7.1 confirms the packaging shape: a UMD bundle exposing window.Lilac, plus a Composer package that ships alongside it, plus a Qwik-based live playground. The UMD global is a genuine convenience — it means the editor can be dropped into a Blade view via a <script> tag without a build step, which is useful for legacy admin screens and for the one-day spike. It does not change the core TPM conclusion: there is still no evidence of a service provider, config publish, migration, or extra.laravel block, so the PHP-side work — persistence, sanitization, validation, uploads, render path — remains ours. Fit remains good for content-authoring surfaces and poor for constrained/structured input.

Integration feasibility. Unchanged for the thin slice (still a day or two), and marginally improved by the UMD artifact because a no-build prototype is now possible. The expensive parts are identical: server-side HTML sanitization (mews/purifier/HTMLPurifier), a tag/attribute allowlist, an authenticated image endpoint with MIME sniffing and caps, and one canonical render path. One new feasibility question is raised by the notes: if the editor's internals are Qwik-based, check whether the Qwik runtime is bundled or required as a peer dependency — a bundled runtime inflates the payload, a peer dependency risks version conflicts with the host app. Livewire 3 binding still needs wire:ignore plus explicit $wire.set() sync and Alpine glue for toolbar state.

Technical risk. The dominant risk remains maturity, and v0.7.1 is itself evidence for it. A patch release whose sole purpose is to restore a missing dist/lilac.umd.js means the publish pipeline was silently shipping incomplete artifacts and nothing in the release process validated the packed output. That is a process signal, not a code-quality one, but TPMs should read it as: assume published tarballs are not smoke-tested, so verify every artifact you upgrade to rather than trusting the registry. Two secondary consequences. First, the project is clearly pre-1.0 (0.7.x), so minor bumps may carry breaking changes; treat 0.7 → 0.8 as a migration event, not a routine upgrade. Second, since 0.7.0 was the release that presumably introduced the Composer package / UMD / playground trio, the 0.7.0 artifact may have been broken for script-tag consumers for its entire life — any spike done against 0.7.0 must be redone. The previously flagged anomalous release date remains unexplained and still needs verification before a dependency lock. Standing risks unchanged: stored XSS via paste/import, undocumented accessibility conformance, unverified i18n/RTL, unclear canonical output format, and single-maintainer bus factor. MIT remains clean, but still check for bundled third-party code (a bundled Qwik runtime would be the obvious place).

Key questions.

1. What does composer require lilac-wysiwyg/lilac actually install — a full Laravel package with provider/config, or a thin wrapper that only publishes assets? The release notes claim a "PHP/Laravel Composer package" but nothing indicates Laravel wiring.
2. Same question as before, now more pointed: is dist/lilac.umd.js present in the published v0.7.1 tarball? Verify by inspecting the packed artifact, not the repo.
3. Is the publish pipeline covered by CI that smokes-tests the tarball contents? The 0.7.0 regression suggests not.
4. Is Qwik a bundled dependency or a peer dependency, and what is the gzipped payload with the runtime included?
5. What is the canonical persisted format — sanitized HTML, Markdown, or a JSON document tree? Can we round-trip it?
6. Does the project publish a security policy and a documented XSS/sanitization stance?
7. Accessibility conformance level; tested with screen readers and keyboard-only navigation?
8. Maintenance commitment: commit cadence, issue response time, number of maintainers with merge rights?
9. Browser support matrix and any peer-dependency conflicts with existing Vite/editor plugins?
10. Image/file handling: built-in uploader, or BYO endpoint?
11. Why is the release dated in the future, and what is the 1.0 timeline?

Integration Approach

Stack fit. Still a clean fit with Laravel 10/11/12 + Vite + Blade, with one addition: the UMD global gives a viable no-build path for <x-rich-text> on legacy or non-Vite admin pages, alongside the preferred ESM/Vite entry. Alpine pairs naturally; Livewire 3 needs wire:ignore plus explicit sync. Tailwind design systems still need token overrides. Inertia/React/Vue apps consume the ESM build directly — but confirm the Qwik runtime story before assuming it composes cleanly with an existing framework bundle.

Migration path. Content migration is unchanged: if Lilac reads and writes HTML, moving off TinyMCE/CKEditor/Quill/Trix is a re-sanitization pass, not a transform. Leaving Lilac stays cheap only if the stored format is plain HTML; a proprietary JSON document model turns exit into a rewrite, so negotiate for HTML export on every save regardless. Keep the one-time batch re-sanitize-and-diff job before cutover.

Compatibility. PHP version remains irrelevant. Constraints are Node version for the build, the browser matrix, Qwik runtime/peer-dependency interaction, and — newly relevant — artifact integrity: pin exact versions (0.7.1, not ^0.7) because the publish pipeline has a demonstrated failure mode of omitting build outputs, and because pre-1.0 minor bumps are breaking by policy. Coexistence with an incumbent editor on separate screens remains low-risk and a good sequencing tactic; two editors in one form does not.

Sequencing.

1. Artifact verification (½ day): install v0.7.1, confirm dist/lilac.umd.js is actually inside the published package, inspect the Composer package contents, record gzipped size and Qwik dependency shape. This replaces the earlier "does the artifact exist" spike step and must precede everything else.
2. Sanitization pipeline first: land mews/purifier config, allowlist, output helper before the editor ships.
3. Wrapper component + upload endpoint: Blade component, Livewire binding pattern, authenticated image endpoint with validation and storage abstraction.
4. Accessibility and browser audit: keyboard-only pass, screen-reader pass, document gaps vs WCAG 2.2 AA.
5. Pilot behind a feature flag: one low-traffic authoring surface, two-week soak with error tracking on save and render.
6. Progressive rollout: surface by surface; keep the incumbent editor for rollback until the pilot cohort is clean. Add a rendering regression suite over fixture content before the second surface goes live.

Operational Impact

Maintenance. Assume ownership. Zero dependents means no community absorbing upgrade pain, and v0.7.1 demonstrates the specific hazard: an upgrade can deliver a broken or incomplete artifact rather than a broken API, so failures surface as "the editor doesn't load" in production, not as a failing test. Budget for a pinned-version policy, a documented upgrade runbook that includes post-install artifact checks, and a vendored fork if the project goes quiet. Track upstream commits monthly; treat 0.8.0 as a planned migration, not a patch.

Support. Community-only, no SLA, no escalation. Internal load lands on the platform team: formatting bugs, paste-from-Word corruption, "content disappeared" tickets — plus, now, packaging questions from developers ("why is the bundle 404ing?"). Establish a triage owner and known-issues doc before launch; capture editor HTML output in error reports so bugs are reproducible.

Scaling. Server-side load essentially unchanged — client-side editing, text-column storage. Watch the authoring page's JS budget (the Qwik runtime, if bundled, is the variable to measure) and lazy-load the editor only on screens that need it. The upload endpoint remains the real scaling surface: rate limits, size caps, object storage from day one, or it is an unbounded disk-fill vector. Cache public rendering of stored HTML as with any content.

Failure modes.

• Stored XSS via paste, HTML import, or an allowlist gap — highest severity; mitigate with server-side purification and CSP.
• Incomplete published artifact (the 0.7.0 → 0.7.1 class of failure) — mitigate by pinning exact versions, verifying tarball contents in CI on upgrade, and monitoring editor-load errors as a first-class alert rather than a generic JS error.
• Silent content loss on autosave/Livewire sync failure — debounced save, localStorage draft, visible save-state indicator.
• Upgrade breakage with no upstream test suite — pinned versions plus a rendering regression suite over fixture content.
• Upload endpoint abuse (oversized files, SVG with script, polyglots) — MIME sniffing, image re-encoding, separate serving origin.
• Abandonment — keep the integration surface thin and fork-ready so swapping editors is weeks, not quarters.
• Accessibility regression blocking a compliance commitment — audit before rollout, not after.

Ramp-up. Developer ramp-up stays low (half a day; the UMD global lowers it slightly for no-build prototypes), but the team ramp-up is still dominated by sanitization and content-security literacy. Author ramp-up is near zero if the toolbar is trimmed to exactly the tags the sanitizer permits — ship both allowlists from one config, since an editor offering formatting the backend strips is the single most common source of "the editor ate my formatting" complaints.