Nova Html Card Laravel Package

Product Decisions This Supports

• Clearing the "we need a card for that" backlog item. Announcements, runbook/docs links, changelog summaries, status badges, policy banners, feature-flag notices, and BI embeds (Grafana/Metabase) become a configuration task measured in hours rather than a 1–2 day front-end build. That is a direct trade against engineering capacity in your admin-panel workstream — quantify it as widgets-shipped-per-sprint, not as a library adoption.
• A codified triage rule for dashboard requests. Give the team a default so "do we build a card for this?" leaves grooming: static, trusted content → this package; interactive, filtered, live-data, or charted content → bespoke Vue card. This is the highest-leverage decision here, because it determines whether the dependency gets stretched past its design intent or stays a cheap convenience layer.
• Build vs. buy for "render trusted HTML inside Nova." The micro-buy case is strong only inside an existing Nova estate: MIT license, one Composer line, no migrations, no persistence, no publishable assets, reversible in a single NovaServiceProvider edit. Outside Nova the question is moot — there is nothing to buy.
• Onboarding and internal-comms shippability. A "Getting Started / Help & Docs" card pinned to the top of the main dashboard — runbook, support channel, deploy guide, changelog excerpt — ships without touching the SPA or coordinating a front-end release. Same for quarterly announcements and support-link strips. High perceived value per engineering hour.
• Content-governance policy. Adopting this forces a product-level answer to "who may author admin-panel HTML, and which constructs are permitted?" That is a policy question with a technical consequence, and it decides whether the dependency becomes an asset or an incident. The defensible answer: engineers only, content in version-controlled Blade files or config — never a free-text database field.
• Dashboard information architecture. The $width property lets you compose a legitimate informational header row — three 1/3 cards covering status, links, and an announcement — making a stock Nova dashboard look intentional without touching Vue internals. Small design decision, disproportionate perceived polish, zero ongoing maintenance.
• Portfolio signal, not platform strategy. 68 stars, zero dependents, one maintainer, last release a CI/asset rebuild. Treat it as a widget layer, never as a commitment any roadmap milestone depends on.

When to Consider This Package

Consider it when:

• You already run Laravel Nova and want dashboard content without writing and maintaining a custom Vue card component.
• The HTML is trusted and operator-controlled: config values, translations, seeded content, marketing copy, docs links, status badges, embedded iframes.
• Speed and reversibility beat provenance — MIT, drop-in, no schema changes, no data migration, no lock-in beyond Nova itself.
• You are willing to pin a version (3.4.*), name an internal owner, and accept small-maintainer risk as a conscious trade-off.
• You want a fast spike to validate a dashboard concept before committing engineering effort to a bespoke card.

Look elsewhere when:

• You are not on Nova. Nova is paid, closed-source, and major-version-coupled; this package delivers nothing outside it.
• The HTML is user- or tenant-supplied. Raw rendering into an authenticated admin DOM is a stored-XSS surface on your highest-privilege session — use a sanitizing renderer or a constrained rich-text field that sanitizes on save.
• You need interactivity, live data binding, filters, polling, or charting. Build a custom Nova card; "we want a refresh button" is the triage signal to escalate, not a reason to bend this package.
• You require SLAs, a security-review trail, or active community support — 68 stars and a single maintainer will fail most enterprise procurement bars.
• A Nova major upgrade is on the horizon. These small cards routinely lag breaking changes; budget a fork-and-patch contingency and validate against your exact Nova and PHP versions in CI.
• Your CSP posture blocks inline scripts, styles, or third-party frames. The card fails silently as a blank box with no operator-facing error, which is worse than no card at all.

How to Pitch It (Stakeholders)

To executives: "A small MIT-licensed add-on for our Laravel admin panel that puts announcements, docs links, embedded dashboards, and status information on the dashboard without engineering a new front-end widget each time. It is cheap and reversible — one Composer line in, one line out — and it removes a recurring one-to-two-day front-end task per widget from the roadmap. Risk is contained: internal-only, we control the content, no data migration, and no lock-in beyond the Nova license we already pay for."

To engineering: "It's a one-class card whose only real extension point is content(): string. We subclass it, return view(...)->render(), register it in NovaServiceProvider::cards(), and use Nova's own $width, canSee(), and onlyOnDashboards() for placement and permissions. No config to drift, no routes to secure, no middleware to reason about. Two constraints we enforce in review: content() stays pure and cached — it runs on every dashboard request for every user who sees the card — and every interpolation is escaped, because raw HTML into an authenticated admin DOM is the whole risk surface. Pin to 3.4.*; treat Nova upgrades as an explicit compatibility check, with a local fork as the fallback since the package is forkable in an afternoon."

To security/ops: "Trusted, version-controlled content only, authored by engineers, reviewed like code. No user- or tenant-influenced strings reach the renderer. Each iframe embed is treated as a CSP allowlist change with a review, and every embed is a page-load cost plus an unmonitored external dependency — so we cap it at one per dashboard and size it explicitly."