Nova Html Field Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-tooling micro-features. This is a ~50-line Nova custom field, not a platform. The decision it actually informs is "do we take a dependency for a cosmetic affordance, or write it ourselves in an afternoon?" For anything under ~200 lines with no maintenance signal, the answer is almost always build — and this package is a useful benchmark for where that threshold sits.
• In-form guidance instead of external documentation. The core use case is putting contextual HTML inside a Nova create/edit form: policy notices, field-level help, "what happens when you save this" explanations, approval-workflow banners, links to runbooks. That is a real product decision — moving operator knowledge from Confluence/Notion into the moment of action — and it measurably reduces support tickets and mis-keyed records in internal tools.
• Surfacing computed/derived context in admin forms. Display-only fields let you show a read-only summary alongside editable inputs: calculated totals, resolved pricing, linked-account state, "this record is under legal hold" warnings, deprecation notices on legacy fields. This is a roadmap item for most internal admin surfaces and is cheap to ship.
• Scoping admin polish vs. customer-facing work. A zero-star, single-maintainer, last-released-2020 package is a clear signal that this capability is not a differentiated investment. It supports a decision to timebox admin UX improvements to hours, not sprints, and to keep them off the customer-facing roadmap.
• Use cases where it fits: internal-only Nova panels; static content authored by the team (not end users); terms/consent text display; compliance disclaimers on PII forms; onboarding hints for new ops staff; surfacing API/webhook status strings as formatted text.
• Use cases where it does not fit: anything user-generated, anything requiring interactivity (buttons, links that mutate state), anything customer-facing, anything that must render inside Nova 4/5 without modification.

When to Consider This Package

Consider it if all of the following hold:

• You are on Laravel Nova 2 or 3 and are not planning a Nova 4+ upgrade in the next two quarters. The 2020-10-23 release predates Nova 4's field API changes; assume incompatibility until proven otherwise.
• The HTML is developer-authored or trusted-content only — hardcoded strings, translation files, or admin-curated CMS content. This field renders raw HTML into the Nova DOM; that is an XSS vector against privileged admin sessions if the source is ever user-influenced.
• You need a display-only block with no state, no validation, no persistence, and no interaction with other fields.
• You are willing to vendor or fork it rather than depend on upstream. With 0 stars, 0 dependents, and no releases in ~5 years, there is no support path, no security response, and no upgrade guarantee.
• The cost of it breaking is a cosmetic regression in an internal tool, not a customer-facing outage.

Look elsewhere (or build in-house) if:

• You are on Nova 4 or 5 — plan on a custom field class instead; the pattern is straightforward and Nova's docs cover it.
• You need maintained dependencies for SOC2 / vendor review / supply-chain policy. An unmaintained package with no dependents will fail most third-party risk questionnaires.
• You need rendering guards — sanitization, allowlisted tags, markdown-to-HTML, or a WYSIWYG editor. Reach for a maintained sanitizer plus a custom field.
• You need interactivity, reactivity, or conditional visibility driven by other form fields. Use Nova's native dependsOn with a custom Vue component.
• You need any form of support, CVE patching, or a roadmap commitment. There is none here.

How to Pitch It (Stakeholders)

To executives: This is a tiny, unmaintained open-source helper that lets us drop a formatted informational block into our internal admin forms — think compliance disclaimers or "here's what this button does" guidance right where operators need it. It is not a strategic dependency and carries no customer-facing risk. My recommendation is not to adopt it as a dependency: we should copy the ~50-line pattern into our own codebase as an internal custom field. That gives us the same capability, removes an unmaintained third-party from our supply chain, and costs roughly half a day of engineering. Net: we get the admin UX improvement without the vendor risk, and we avoid spending a sprint on it.

To engineering: The package is a thin Nova field that renders an HTML string in a form. It was last released in October 2020 against the Nova 3 field API, has zero stars and zero dependents, and will not survive a Nova 4/5 upgrade without patching. There is also an XSS consideration: it renders raw HTML into a privileged session, so the content source must be strictly trusted or sanitized. Recommendation: implement as an in-house Html field class (~50 lines, one Blade partial), sanitize on render, and treat the upstream repo as a reference implementation only. If someone insists on the package, vendor it into app/Nova/Fields so we own the code and can patch it.