awcodes/richie
Richie is a Laravel/PHP package by awcodes that brings a rich text editing experience to your applications, making it easy to add and manage formatted content with a simple, developer-friendly integration. Use it to give users a clean editor for writing and formatting text in Laravel projects.
Build vs. buy on rich text editing. Richie is a Filament form field (Tiptap/ProseMirror under the hood, Livewire/Alpine for the client interaction) plus, per its description, a JSON→HTML render path and a Blade component for output. For internal authoring surfaces — CMS pages, help-center articles, release announcements, support macros, email templates — it removes a bespoke Tiptap integration your team would otherwise staff, review, and maintain. Be honest about what the "buy" is worth: a few days of integration head start and no license cost, not a support relationship. 7 stars, one maintainer, zero dependents.
Where rich text belongs in the roadmap. This is an admin-panel capability, not a platform capability. It lets you ship an editor inside a Filament resource form this sprint, which unblocks any backlog item currently gated on "the content team can't edit this without engineering." That is the highest-leverage use: converting hand-coded content changes into self-service, and converting engineering hours into content-team hours.
The storage-format decision, which outlives the package. Persisting structured JSON as the source of truth with sanitized HTML derived at render (or stored alongside for search/indexing) determines your schema, your search indexing, your API serialization, and — most importantly — how cheaply you can swap editors later. This is the one decision the PM should insist on owning explicitly in design review, because it is the decision you cannot cheaply reverse. Editor choice is reversible; a database full of raw HTML blobs and a search index built on ProseMirror node names is not.
Two bets, kept separate. Richie only works inside Filament. If you're standardizing admin UI on Filament anyway, adopting an awcodes-maintained field reduces custom glue. If you're not on Filament, an editor requirement must not be allowed to drag a panel migration along behind it. Treat "adopt Filament" and "adopt a rich text editor" as two roadmap decisions with two business cases.
Feature sequencing and commit confidence. v0.1.3 is a correctness patch, not a capability: actions now register on the editor instance instead of globally (PR #2). That fix is exactly the plumbing behind per-field toolbars and multi-editor forms — meaning the API is still settling in the one release you're evaluating. Do not commit roadmap dates to custom tools, named toolbar profiles, or multi-editor layouts without a spike first.
Risk framing for anything customer-facing. Publicly rendered user-authored HTML is a safety surface. The repo evidences no XSS guidance, so until your own sanitization sits at the render boundary, public UGC authoring is out of scope. That is a product call — it changes who is allowed to author and where the output may be displayed — not just a ticket for engineering.
Adopt when all of the following hold:
0.1.x package should not sit on the primary customer-facing authoring path.0.1.3, not ^0.1) and absorb breaking changes on the maintainer's schedule, with at least one engineer who can read and patch the source when the docs lag. At 0.1.x, the source is the documentation.Look elsewhere when:
For executives (one paragraph): We can unblock self-service content editing for the content team in roughly a sprint, at zero license cost, using a small open-source editor field for the admin panel we already run. The commitment is deliberately small and reversible: one internal content type, pinned to an exact version, behind a feature flag, with a plain text box as the fallback. The real decision isn't the package — it's that we'll store content as structured data rather than HTML blobs, which is what keeps us free to change editors later without a migration. The risk is maintenance, not money: one maintainer, no support contract, so we name an internal owner, budget a quarterly review, and get out cheaply if the project stalls.
For engineering (the ask): Spike one editor field on one internal resource, pinned to 0.1.3. Deliverables from the spike: confirm whether the JSON→HTML renderer actually ships at this version (the README and the changelog disagree — resolve it on day one, because it decides whether we're buying an authoring tool or a rendering utility); confirm the namespace and make() signature against src/; establish whether the field ships compiled assets or puts our Vite pipeline in the deploy path of an admin form control; and write one regression test that two editors on the same form keep isolated toolbars — that's the exact failure mode 0.1.3 fixed, and it's the test that gates every future version bump.
Also in scope for the spike, because they're cheap now and expensive to retrofit: wrap the field in our own subclass so call sites never reference the vendor class; put a sanitizer at the render boundary in one place, not in per-field config; add a save-time guard that rejects empty content over an existing document (turns a silent content-loss bug into a validation error); and confirm image upload storage disk and path live in config, validated server-side.
The exit plan, stated up front: the source is small and MIT-licensed; if the project stalls we fork and vendor it, and because we're storing structured JSON behind our own wrapper class, swapping to raw Tiptap, TinyMCE, or Markdown is a UI change rather than a data migration. Re-evaluate at 1.0, or after one full release cycle without action-API churn.
How can I help you explore Laravel packages today?