Filament Carve Laravel Package

Product Decisions This Supports

• Build vs. buy for rich-text/markup authoring. This package is the Laravel-side integration for the Carve markup renderer. Adopting it means we buy the parsing/rendering engine and the framework glue (Blade components, form fields, config-driven render profiles) instead of maintaining our own sanitizer and converter pipeline. The relevant PM decision is whether markup authoring/rendering is core to our product or incidental — if incidental, buying is the default answer.
• Feature scope for editor surfaces. CarveEditor, CarveEntry, and CarveColumn map to three distinct UI surfaces (authoring, single-item display, tabular/list display). That's a usable checklist when scoping an "editable content" epic: we get a consistent authoring and display path across list and detail views rather than three bespoke implementations.
• Roadmap risk: dependency provenance. The 3.1.0 switch from the abandoned jeffersongoncalves/laravel-carve to the official markup-carve/laravel-carve ^0.1.7 is a genuine supply-chain improvement — but note the official bridge is still pre-1.0. This is a schedule input: we should budget for churn on the bridge's API before it stabilizes, and avoid deep coupling to its internals.
• Support-matrix and upgrade budgeting. The fix was backported to 1.x and 2.x, meaning three maintained lines. That's good for us (we can stay on 2.x and still get fixes) but it also means we must decide and document a supported version explicitly, or we'll accumulate drift across squads.
• Content-model decisions. Config-driven render profiles (now under the converters key) imply a product decision about how many rendering contexts we expose — e.g. "compact in lists, full in detail views, plain-text in emails/notifications." Choosing profiles is a product/design decision that this package makes cheap to implement.

When to Consider This Package

Adopt when:

• We are on a supported Laravel version and need markup authoring and rendering inside the framework, not as a separate service.
• We want a consistent editor/display component pair rather than hand-rolling sanitization, escaping, and HTML output per surface.
• We have (or expect) multiple rendering contexts — list, detail, notification — and want them configured centrally rather than encoded in Blade templates.
• We are willing to own a small, well-bounded upgrade tax: the 3.1.0 notes require both a namespace rename (JeffersonGoncalves\Carve\ → MarkupCarve\LaravelCarve\) and a config republish (profiles → converters). This is a mechanical but mandatory migration; it is cheap on a greenfield branch and materially more expensive mid-sprint on a live feature.

Look elsewhere when:

• We need a full WYSIWYG experience with collaborative editing, mentions, or paste-from-Word fidelity — this is a markup renderer bridge, not an editor platform.
• We require a stable, post-1.0 dependency with a long-term support commitment. The official bridge is ^0.1.7; its pre-1.0 status is the single biggest adoption caveat and should be recorded as such.
• Content is user-generated at scale and untrusted: we still need to own the sanitization policy and threat model. Do not treat a renderer as a security boundary.
• We have already standardized on a different markup dialect or a headless CMS that renders server-side; adding a second rendering path creates two sources of truth for output.

Upgrade guidance for teams already on the abandoned dependency: treat 3.1.0 as a breaking change, not a patch. Pin it, schedule the import rename and config republish as a discrete ticket, and verify rendering output before and after — a config key move is exactly the class of change that silently falls back to defaults and produces visually wrong-but-not-erroring output.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated the Laravel integration for Carve, our markup rendering library. The release we reviewed (3.1.0) moves the package off an abandoned third-party dependency onto the official vendor-maintained bridge and fixes a correctness bug in how annotated model values are treated as source. Both are risk reductions, not feature additions. The trade-off is a required migration — a namespace rename and a config file republish — plus the fact that the official bridge is still pre-1.0. Recommendation: proceed on new work, treat the dependency as version-pinned and owned by a named engineer, and do not adopt it as a platform standard until the bridge reaches 1.0.

For engineering: 3.1.0 is a breaking release in practice despite the minor version. Two required actions: (1) rename imports from JeffersonGoncalves\Carve\ to MarkupCarve\LaravelCarve\; (2) if config/carve.php was published, republish it and move render profiles from the profiles key to converters. The AsCarve source-handling fix lands in CarveEditor, CarveEntry, and CarveColumn and is backported to 1.x and 2.x — so we can defer the dependency swap without losing the bug fix, if we need to decouple those two changes. Verify rendered output across every configured profile as part of the upgrade, since the config restructure can fail silently.

Ask: one engineer-day to scope, one to execute and verify for a typical app; confirm which major line (1.x, 2.x, 3.x) we standardize on and record it so future upgrades aren't a per-team judgement call.