Nova Cards Laravel Package

Technical Evaluation

Architecture fit. Nova-cards is a strictly additive presentation-layer dependency for Laravel Nova: a Card subclass, a Vue component, optional published assets, registered through NovaServiceProvider::cards() or a per-dashboard Dashboard::cards(). It has no reach into authentication, routing, persistence, queues, or model layer. That is the decisive architectural fact for a TPM — the blast radius of this package is "a dashboard panel renders wrong," not "data is corrupted" or "requests fail." It also means there is zero partial fit: outside a Nova installation the package has no value, and it should be rejected at triage rather than evaluated.

Integration feasibility. The install is composer require plus a handful of lines in a service provider. Total source surface is a few hundred lines of PHP and Vue — small enough that a single engineer can read all of it in half an hour and hold the whole thing in their head. That is unusual and it is the main reason this clears a feasibility bar at all. The gate is not effort; it is Nova major version compatibility, which must be read from composer.json constraints and the source, not inferred from the README. Nova 4 versus Nova 5 is the single biggest adoption blocker for small card packages, and a lagging card is a blank panel on the first screen operators see each morning.

Technical risk. Four risks, in descending order of severity:

1. Static-versus-computed ambiguity. The package is positioned as info cards (static text, links, notices), but the surrounding integration guidance drifts toward value cards rendering computed numbers. These are different product bets. If it is purely static, it cannot substitute for Nova's first-party Value/Metric/Partition/Trend cards and the scope narrows to informational surfaces only. This must be settled by reading the class before anything is promised to a stakeholder.
2. Unescaped rendering. The realistic security failure class for an info-card package is {!! !!} rendering of operator- or config-authored content inside the admin panel. One grep is the whole audit; do it before merge, not after.
3. canSee() gates rendering, not computation. If anything is computed eagerly in cards() — a count, a scoped query, a drill-down link — it runs for every user regardless of the gate. This is a genuine finding class, not a theoretical one.
4. Bus factor 1. 33 stars, zero dependents, single maintainer, no SLA. Assume you may own this code outright after the next Nova major.

Key questions to answer before committing:

• Which Nova major are we on, and does the package's constraint cover it? (Read composer.json, do not assume.)
• Does the card render a Blade view we supply, or ship its own configurable Vue component? This determines whether content lives where developers look for it.
• Is content escaped? Is any HTML rendered raw, and can anyone below "trusted engineer" influence it?
• Does it compute anything, or is it purely static?
• What is the maintainer's release cadence relative to Nova majors?
• Who owns the fork decision if it breaks, and what is the pre-agreed trigger?

Integration Approach

Stack fit. Laravel + Nova, nothing else. The package consumes no services, adds no middleware, publishes at most assets and views. It fits any Nova app and fits no non-Nova app. If the target environment is not already on Nova, this evaluation ends here.

Migration path. There is none, in the good sense — this is greenfield-additive. No schema changes, no backfill, no dual-write, no cutover, no rollback plan beyond composer remove and deleting the card registration. That is what makes it a low-ceremony decision and also why it should not occupy a roadmap slot: the reversibility is total, so the cost of being wrong is measured in hours.

Compatibility. Three constraints to verify, in order: Nova major (the blocker), Laravel and PHP versions via the package's Composer constraints, and the asset pipeline era of the compiled Vue (Nova's Mix-to-Vite transition means a card built for one generation may not publish cleanly into the other). Confirm all three against source before the spike, not during it.

Sequencing.

1. Confirm Nova major and read the constraint. Ten minutes. Kills or continues the initiative.
2. Read src/ and the Vue component. Thirty minutes. Answers static-vs-computed, view-vs-component, and escaping in one pass. Write the answers down; that note becomes the team's documentation.
3. Grep for {!! !!}. Five minutes. Closes the security question.
4. Spike one card: an environment banner ("Staging — do not trust these numbers"). Lowest-risk, highest-signal, and it exercises registration, rendering, sizing, and authorization end to end in roughly twenty lines.
5. Move to per-dashboard registration via Dashboard::cards() rather than the global cards(), once a second dashboard exists. Global registration puts the card on surfaces you did not design.
6. Expand to at most two or three cards, one class per concern — never a single DashboardInfoCard with a type switch. Separate small classes are cheaper to test, gate, and delete.
7. Document and wire the upgrade checklist entry before the first production deploy, not after the first broken dashboard.
8. Decision gate: at three-plus cards or the first genuine dynamic requirement, stop and build a small internal card component. At that volume the dependency stops paying for itself and you own the logic anyway.

Effort framing. Roughly one to two engineer-days for the first card inclusive of review and staging validation; about half a day per additional card. Against a custom Nova card — service provider, Card subclass, Vue component, composer.json — the package saves scaffolding, not capability. The honest build-vs-buy framing for stakeholders is "half a day of scaffolding per card versus a dependency," and the answer flips to building in-house at three cards or any computed content.

Operational Impact

Maintenance. Operationally you should assume you own this. Single maintainer, zero dependents, no issue corpus. MIT licensing makes an internal fork roughly a day's work for the same engineer who already read the source during the spike. That is a cheap insurance policy — but it must be budgeted, not discovered mid-incident. Pre-commit to a fork trigger now, e.g. "if the card is broken more than two weeks after a Nova major release, we fork."

Support. No SLA, no vendor, no Stack Overflow answers, no one else hitting your problem first. The source is the documentation. The practical mitigation is the spike note: what the base class expects, whether it escapes, which command republishes assets. That note is the entire runbook and it costs thirty minutes to write.

Scaling. Not a load concern — static rendering, no queries, no background work. The scaling risk is organizational: card count and registration discipline. Every additional card is another surface to gate and another thing to check after a Nova upgrade. The canSee()-gates-display-not-computation issue is the one way this package can scale into a real problem, and it scales with eager computation in cards(), not with traffic.

Failure modes. All are contained, and knowing their shape is most of the mitigation:

• Nova major upgrade breaks rendering. Blank panel on the dashboard. Cosmetic, but visible to every operator daily — which is why the upgrade checklist entry matters more than the severity suggests.
• Stale compiled assets after composer update. "Card shows nothing." Looks like a broken package, is actually a cache issue. Fix: hard refresh or re-run nova:publish. Put the command in deploy notes; you will hit this.
• XSS via unescaped content. The only non-cosmetic failure mode. Confined to the admin panel, but the admin panel is where the highest-privilege sessions live. Closed by the grep in step 3.
• Credibility failure from misuse. A static card impersonating a metric — a trial-expiry count, a revenue number — produces a dashboard operators stop trusting. This is a product failure, not a technical one, and it is prevented by scoping the package to informational surfaces in the written decision.
• Maintainer abandonment. Absorbed by the fork budget.
• Layout wrap. Cards that look correct at 1/3 width in a demo wrap badly beside a full-width metric. Validate in staging at the team's standard viewport, not the demo's.

Ramp-up. Low. An engineer who already knows Nova needs one to two hours to be productive; one who does not needs the Nova card model explained first. The TPM-facing ramp-up is smaller still: one line in the deploy runbook ("dashboard card blank after deploy → republish assets, hard refresh") and one line in the upgrade checklist ("run the dashboard in staging after a Nova major").

Governance classification. File this as a replaceable convenience, not a strategic dependency. It should stay off architecture review agendas, stay pinned to an exact version in composer.lock, and stay out of any critical-path inventory. The useful side effect of adopting it deliberately is that it forces a Nova version-strategy conversation — "are we on 4 or 5, and when do we upgrade?" — which is better answered now than discovered during an upgrade. The counterpart discipline is equally important: never let a static info card stand in for a real metric. Use the package for notices, release notes, known-issue banners, escalation paths, onboarding checklists, and ownership contacts, and route anything numeric to Nova's first-party cards.