Ux Quill Laravel Package

Product Decisions This Supports

• Build vs. buy for rich text editing. This bundle removes the need to hand-roll a Quill + Stimulus integration: QuillType drops a full WYSIWYG into any Symfony form, stores HTML in a hidden field, and handles the two-way sync plus native input/change events that form validation and Live Components depend on. That is roughly the scope of a 1–3 sprint frontend task converted into a composer dependency.
• Platform fit check first. Despite the framing, this is a Symfony UX bundle, not a Laravel package. It requires symfony/stimulus-bundle, Symfony Forms, and Symfony 6.4/7/8. It has no bearing on a Laravel roadmap — for Laravel the equivalents are Filament's RichEditor, Livewire-based editors, or a standalone Quill/Alpine integration. Treat this release as relevant only if the product surface in question is Symfony.
• Roadmap enablement for content-authoring features. CMS pages, marketing copy, email-template bodies, help-center articles, and product descriptions are all "needs a WYSIWYG" tickets. This bundle is a candidate shared component for that whole class of work rather than a per-feature integration.
• Admin-tooling decisions. QuillAdminField is a one-liner for EasyAdmin, which makes this a cheap upgrade to internal back-office editing without committing to a JS build pipeline (works with both AssetMapper and Webpack Encore).
• Vendor/editor selection. Choosing Quill v2 as the standard editor is a multi-year decision. This release makes Quill cheaper to adopt, but it does not settle Quill vs. Tiptap/ProseMirror vs. CKEditor/TinyMCE — those differ on document model, collaboration, and licensing, not on form integration.
• Risk posture and release gating. This is v0.1.0, explicitly experimental, with no backwards-compatibility guarantee between releases. That is a decision input: acceptable behind admin/internal surfaces with a pinned version; not acceptable as a dependency of a customer-facing editor with an SLA, absent a version lock plus an owner for upgrade churn.

When to Consider This Package

Adopt for a spike or a low-risk surface when:

• The application is Symfony 6.4, 7.x, or 8.x and already uses Symfony Forms; symfony/stimulus-bundle >= 2.9.1 is present or easy to add.
• You need an inline WYSIWYG inside an admin panel (EasyAdmin, custom back office) or a form-heavy internal tool, and shipping it without a JS build step is worth more than API stability.
• The team has limited frontend bandwidth and would rather configure a toolbar than maintain a Stimulus controller and Quill lifecycle.
• You want an escape hatch for customization: the quill:options, quill:connect, and quill:change events, custom toolbar configs, snow/bubble themes, readOnly, and minHeight cover most product asks (preview mode, custom toolbars, autosave-on-change) without forking.
• You can accept the maintenance contract: pin the version, read each release note, and budget for occasional breaking changes across 0.x.

Look elsewhere when:

• The stack is Laravel. Nothing here applies; use a Laravel-native editor. Note this explicitly so the dependency is not mis-scoped into a Laravel evaluation.
• You require a stability guarantee, LTS support, or a vendor SLA — v0.1.0 with "BC not guaranteed" is disqualifying for regulated or revenue-critical paths.
• You need collaborative editing (multiplayer cursors, presence, conflict resolution) or real-time co-editing. Quill v2 core does not provide this out of the box, and this bundle adds nothing on top.
• You need structured document storage (portable JSON/ProseMirror-style schema) rather than HTML strings. This bundle is HTML-in-a-hidden-input by design; the document model is whatever Quill emits.
• Sanitization and XSS are hard requirements. The release notes describe HTML being stored and synced but say nothing about server-side sanitization or allowed-tag policy. That is not a reason to reject the package, but it is a reason to treat sanitization as your deliverable — budget an HTML purifier step on input and on render, and decide the allowed tag/attribute set before rollout.
• Image handling matters. Quill's default image button inserts base64 data URIs. The notes do not mention an upload adapter, so if you need real file uploads, storage, and CDN serving, plan custom work via the quill:options/quill:connect events or look at a batteries-included editor.
• You are on PHP < 8.1 or Symfony < 6.4, or you are not using Stimulus at all.

Evaluation checklist before committing: run a one-day spike covering (1) a form with validation failing server-side, (2) Live Component re-render, (3) EasyAdmin field, (4) a custom toolbar, (5) paste-from-Word and paste-as-plain-text, (6) sanitize-on-save, (7) keyboard-only accessibility and screen-reader behavior of the toolbar.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free, open-source Symfony bundle that embeds the Quill 2 rich text editor into standard Symfony forms with no custom JavaScript. It converts a recurring "we need a WYSIWYG here" build item into a configuration task and works with our existing asset pipeline, so it is cheap to trial and cheap to remove. The caveat is maturity: it is a first, explicitly experimental release with no compatibility promise between versions. The right posture is to pilot it on an internal admin surface, pin the version, and expand only if it holds up — not to standardize it across customer-facing editors this quarter.

For engineering: Integration is a Symfony form type (QuillType) plus an optional EasyAdmin field; the editor state is a normal hidden input emitting native input/change events, so existing validators and data-live-ignore Live Components keep working. Customization is deliberately open: three Stimulus events (quill:options, quill:connect, quill:change) let us adjust config, hook initialization, and react to content changes without patching the bundle. Two things are on us, not the bundle: HTML sanitization on save/render, and an image upload adapter if we want anything beyond base64 inline images. Version-pin it and assign an owner for upgrade reviews.

For product/design: We get the expected editing surface immediately — headings H1–H3, bold/italic/underline/strike, ordered and unordered lists, blockquote, code block, links, images, clear-formatting — plus two layouts (snow toolbar, bubble floating) and per-field control over placeholder, read-only preview mode, and minimum height. Custom toolbars are configurable, so we can ship a reduced toolbar per content type rather than one compromise toolbar everywhere. Ask for accessibility validation and a paste-behavior decision (rich vs. plain text) during the pilot; those are product choices the package will not make for us.

Recommendation: Approve a time-boxed pilot on an internal admin form; pin to v0.1.0; define a sanitization policy and an image-handling decision as pilot exit criteria; revisit standardization once the package reaches a stable 1.x or after two clean upgrade cycles.