Filament Wysiwyg Json Formatter Laravel Package

Product Decisions This Supports

• Content storage model: structured JSON vs. rendered HTML. This package sits at the point where a rich-text editor's JSON output is formatted for display inside a Filament admin panel. Adopting it is effectively a decision to treat rich text as portable structured data rather than a blob of HTML — which is the decision that determines whether content can later be re-rendered into a mobile app, email template, PDF, or headless API without re-authoring.
• Build vs. buy for the editor layer. Rather than building a bespoke JSON→view formatter (sanitization, node mapping, unknown-node handling, empty-state rendering), the team takes a small, single-purpose dependency. This is a classic low-cost "buy" that frees engineering time for differentiation.
• Rendering safety / XSS posture. Because content is persisted as JSON and rendered through a formatter rather than {!! $html !!}, the attack surface for stored markup injection is materially reduced. This supports a security decision, not just a UI one.
• Admin panel scope (Filament-native). It only makes sense if the roadmap keeps internal tooling and editorial surfaces on Filament. That is a platform-standardization decision, and this package is a cheap confirmation that the Filament ecosystem covers the editorial use case.
• Roadmap option value: content reuse and migration. JSON content is easier to migrate between schema versions and to re-target at new channels than stored HTML. Choosing this now lowers the cost of a future "publish to N surfaces" initiative.
• Explicitly not supported: workflow/approval, versioning, media/DAM management, localization pipelines, or publishing scheduling. Do not let this package's presence imply those problems are solved.

When to Consider This Package

Adopt when:

• The product is already on Laravel + Filament and the admin panel is the primary editorial surface.
• The editor in use emits JSON (TipTap/ProseMirror-style document trees) and you need read-only or form display of that JSON inside Filament resources.
• You want structured content for downstream reuse (API, mobile, email) and want to avoid baking HTML into your schema.
• The team is small enough that maintaining a custom node-to-component renderer is a poor use of time.
• You are willing to pin the version and validate rendering against your specific editor node set before rollout.

Look elsewhere when:

• You need a full CMS capability set — versioning, editorial workflow, scheduling, roles, media library. Evaluate a dedicated CMS layer (e.g., Statamic, or a fuller Filament content plugin) instead; this package is a formatter, not a content platform.
• Your content is Markdown-first, or your editor emits HTML/portable-text in a non-JSON format.
• The consumer of the content is not Filament — a generic server-side renderer with broader framework support is a better fit.
• You require guaranteed long-term API stability or vendor support/SLA. This is a small, single-maintainer-style package; treat it as a convenience dependency with an exit path.
• Strict dependency-minimization or security-review policies would make an unpinned micro-dependency more expensive than a ~100-line in-house renderer.

Release-specific note (v1.0.6): the published notes contain no functional detail beyond a changelog link (v1.0.5→v1.0.6). Treat this as a maintenance/patch release with no declared breaking changes, new features, or deprecations. No migration or re-evaluation is triggered; verify by diffing the changelog before upgrading in a locked environment.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost addition that lets our admin panel display rich-text content safely without us building and maintaining custom rendering code. The strategic value is in the storage choice it implies — content lives as structured data rather than finished HTML, so we can republish it to new surfaces (site, email, app) later without re-authoring. Risk is low: it is a narrow, single-purpose library, the latest release is a routine patch with no breaking changes, and replacing it with in-house code later would be a contained effort.

For engineering: Single-responsibility formatter for Filament — it converts editor JSON into renderable output, keeping the persistence layer free of HTML. Low surface area, no framework lock-in beyond Filament, no schema changes required. Pin the version, add a rendering test covering the node types we actually use (headings, lists, links, embeds, unknown-node fallback), and review the v1.0.5→v1.0.6 diff before bumping. If the package stalls, the fallback is a small internal renderer mapped to our own node set — a few days of work, not a re-architecture.

Bottom line: approve as a tactical dependency, not a strategic platform bet. It buys speed now and preserves content portability later, with a clear and inexpensive exit path.