Nova Html Code Field Laravel Package

Product Decisions This Supports

• Build vs. buy for admin tooling. Replaces a bespoke in-house HTML/source editor inside Laravel Nova with a free, MIT-licensed field. HTML editing is low-differentiation surface area; the decision to record is "we do not build editors." Engineering hours redirected to product-differentiating work is the entire business case, and it holds regardless of how good this specific package turns out to be.
• Defining the authoring persona. The field forces an explicit product call on who writes HTML and how. Raw markup editing implies a technical or semi-technical operator working inside Nova resource forms — not a marketer expecting WYSIWYG. Use this as the anchor decision for landing page fragments, email templates, embed snippets, legal copy, or template partials, and let it settle whether a richer authoring surface is genuinely on the roadmap or just an assumed need.
• Roadmap sequencing on the Nova 4 → 5 admin upgrade. Release 2.2.0 adds Nova 5 support, converting this field from "unknown migration risk" into a routine Composer bump. That keeps the admin-panel upgrade on the current cycle instead of spawning a replacement project, which is the single most schedule-relevant fact in the release.
• Keep-vs-replace call for this cycle. Confirms the package tracks the current Nova major, justifying "keep in place, revisit at Nova 6" rather than prioritizing a richer editor now. This buys a natural re-evaluation checkpoint one major version out — a cheap way to defer a decision without losing it.
• Scope boundaries and ownership. This is a field, not a content pipeline. It does not sanitize, validate, transform, or render HTML. Surfacing that gap is a useful forcing function to define and assign an HTML trust and sanitization policy across the whole admin surface — a decision that would otherwise stay latent and unowned.
• Dependency-risk posture. A single-organization, no-SLA, 10-star package with zero dependents informs the dependency register: pin the version, name an internal owner, pre-approve fork-and-patch as a contingency under MIT. That is a bounded, standard risk treatment — not a reason to block.
• Investment deferral with a cheap reversal. Content stays as plain HTML in the database, so swapping editors later is a UI change, not a data migration. Reversibility is high, which is what makes deferring the richer authoring investment (block editor, live preview, WYSIWYG) a defensible bet rather than a gamble.

When to Consider This Package

Adopt when:

• You are already standardized on Laravel Nova (4 or 5) and need a plain HTML/source-code editing field on a resource.
• Your authors are technical enough to work with markup, or this field is one input among several rather than the primary authoring surface.
• You want a minimal, low-configuration dependency instead of standing up a full rich-text/WYSIWYG stack for a handful of fields.
• You are planning a Nova 5 upgrade and need to confirm custom fields are compatible — 2.2.0 specifically removes this as a migration blocker.
• Integration cost matters: Composer require plus field registration, measured in hours, with no migrations, queues, or service-provider bootstrapping.

Look elsewhere when:

• You are not on Nova, or you are evaluating headless/CMS alternatives. The package is unusable outside Nova — a deliberate scope boundary, not a limitation to design around.
• You need WYSIWYG editing for non-technical authors, live previews, or structured block editing. That is a different product requirement, not a different field.
• You require vendor-backed SLAs, security-review artifacts, or a large maintainer base. Plan for one forced upgrade per Nova major and accept a fork-and-patch contingency.
• HTML safety is a core requirement. The field stores verbatim input, so sanitization and escaping must be enforced at write or render time regardless of which field you choose.
• You need a content pipeline — validation, transformation, templating, publishing workflow. This package only covers the editing surface.

Decision gates before committing: confirm whether 2.2.0 widened the laravel/nova constraint to ^4|^5 or is a hard Nova 5-only bump — this decides the path for any Nova 4 fleets and is the one open question that can change the plan. Second, confirm the editor assets behave under your Content-Security-Policy. Both are answerable in staging in under a day.

How to Pitch It (Stakeholders)

To executives: This is a small, free building block for our Laravel admin panel that lets internal users edit raw HTML without us funding custom UI work. Version 2.2.0 adds compatibility with the current Nova version, so it does not stand in the way of the planned admin-panel upgrade and requires no new spend or headcount. It is easily replaceable later — content stays as plain HTML in the database, so swapping the editor is a UI change, not a data migration. The trade-off is a single-maintainer dependency, which we manage with a version pin, a named internal owner, and a documented exit path. Net: we retire a low-differentiation custom build, absorb the Nova 5 upgrade without a blocker, and defer richer editor investment until we have real evidence it is needed.

To engineering: Version 2.2.0 is a narrow compatibility release — Nova 5 support, no API changes, no breaking changes called out. Integration is a Composer bump plus a smoke test of the field in one Nova resource across form, detail, and index views; Nova 5's Vue 3 layer is the likely breakage point. Treat it as a UI-only dependency: it does not sanitize or validate stored HTML, so output escaping and any CSP/trusted-types handling remain ours — pair it with a sanitization policy at write or render time before any production use. Two things to verify before scheduling: whether 2.2.0 widened the laravel/nova constraint to ^4|^5 or is a hard Nova 5-only bump, and whether the editor assets behave under our CSP. Pin the version, assign an internal owner for release tracking, and note that Nova major upgrades are the recurring maintenance event — not continuous churn. If upstream goes dormant at Nova 6, the MIT license makes an internal fork a realistic contingency; budget that only if it actually happens.