Nova List Card Laravel Package

Technical Evaluation

Architecture fit. This is a presentation-only artifact: one Laravel\Nova\Card subclass, one Vue component, one service provider. No migrations, no persistence, no events, no queue work, no config surface worth governing. The blast radius of a bad integration is a broken panel, not a data-integrity incident — which is exactly the risk profile a TPM wants for an internal admin feature.

Fit is conditional on a decision already made: you must be a Nova shop. Outside Nova the package is inert. So this is not really a package decision; it is a downstream artifact of the Nova platform commitment, and it should be recorded that way in planning docs.

It fits one primitive precisely: a read-only, small-N (5–20 row), fixed-column table card. The highest-value TPM contribution here is defending that boundary up front. If the requirement includes sorting, filtering, search, pagination, export, or drill-down, the answer is no — that is a Nova resource index page or a maintained data-grid package. Making that call before anyone writes code prevents the "we'll just extend the card" trap that quietly turns a one-day card into a two-sprint grid.

Integration feasibility. Composer only, with no Node required if compiled assets ship in dist/ — that must be verified, not assumed. The whole integration surface is auditable in under an hour. Realistic in-house equivalent is 50–150 lines against Laravel\Nova\Card, so the package's value is roughly 1–3 developer-days saved, and its larger value is as a working reference for Nova card anatomy rather than as a dependency.

Technical risk (ranked).

1. Archived status is the headline risk, not complexity. No Nova 4/5 work, no Vue 3/Vite migration, no PHP 8.3/Laravel 11+ test matrix, no security-response path. Mitigation is structural: vendor the source, never leave an unmaintained Packagist reference in the lockfile.
2. Stored XSS if cells render via v-html. Any user-editable model field then becomes an injection vector with an admin session behind it. This is the single most important line in the source audit and must be resolved before the card touches a real dashboard.
3. Authorization is entirely yours. The card renders whatever the query returns and does not consult Nova policies. For multi-tenant or permission-scoped models, constraints must live in the query. Treat an unscoped query as a ship-blocking defect class, not a code-review nit.
4. Silent failure modes: missing compiled assets produce a blank card with no error; zero rows produce a blank panel that reads as broken.
5. Nova major upgrade can break the Vue component and degrade the surrounding dashboard bundle — a platform-level symptom from a leaf-node feature.
6. No community signal: 7 stars, 0 dependents means no de facto peer review and no CVE attention.

Key questions to answer before committing (one-day timebox).

• Which Nova major does composer.json target, and does the Nova 3-era scaffolding actually render against the installed version?
• Do compiled assets ship in-repo, or is a Node build required?
• Is the payload server-injected via withMeta() or fetched from the cards/{card} endpoint?
• Are cells rendered with v-html?
• Who is the named fork owner, and what is the retirement trigger?
• Does dependency policy tolerate unmaintained code on an internal, admin-only, low-write surface?

Integration Approach

Stack fit. Laravel + Nova, PHP, Eloquent. No new infrastructure, datastore, runtime, or secret. It deploys inside the existing application artifact — there is no separate service to operate, monitor, or page someone for.

Migration path. There is effectively no migration: this is a greenfield card on an existing Nova dashboard. The meaningful path is the exit path, and it is cheap — deleting one registration line. Document that reverse path before writing forward code.

Adopt as a fork, not a dependency: copy into an internal namespace (e.g. App\Nova\Cards\ListCard), commit the compiled assets, and record fork date, upstream commit SHA, and owner next to the code. Do not leave thijssimonis/nova-list-card as a transitive Packagist reference.

Compatibility. Pin to the exact Nova major in play. Verify asset delivery and cell escaping first, since those two answers decide whether this is a ten-minute win or an afternoon of frontend plumbing. Check dark mode and narrow viewports after any Nova or Tailwind bump — the card predates current Nova theming. Pin the column map explicitly rather than inferring from the first row, so dashboard screenshot baselines stay stable between deploys.

Sequencing.

1. Audit (≈1 hour): read src/, resources/js/, composer.json. Answer the five gate questions. Stop immediately on unescapable v-html or a hard Nova major mismatch.
2. Spike (same day): one "latest N" card on a non-critical dashboard — 5–10 rows, explicit columns, rows linking to resource detail pages.
3. Harden: scope the query for tenant/permission constraints, eager-load relationship columns, wrap the backing query in a short-TTL Cache::remember, cap results server-side.
4. Fork and pin: internal namespace, assets committed, owner and retirement trigger recorded in the repo — not in a wiki.
5. Ship behind a feature flag on one dashboard for one internal audience.
6. Expand to two or three focused cards only if step 5 generated no support tickets within a sprint.

Write the explicit non-goal into the ticket: no sorting, filtering, search, pagination, export, or drill-down. Escalation path for any of those is a Nova resource index page.

Operational Impact

Maintenance. Archived means "maintenance" is literally your team — there is no upstream to wait on. Budget a recurring allowance of a few hours per Nova major plus asset rebuilds, and put it in planning as a named line rather than letting it surface later as unplanned work. Set the retirement trigger now: fold into an in-house class at the next Nova major instead of patching the fork indefinitely.

Support. Internal-only audience caps exposure, and the two predictable tickets are "the card is blank" (assets) and "the card is empty" (no empty state). Pre-empt both: publish/build assets as part of the deploy runbook, and add an empty-state branch in the fork. There is no vendor escalation path, so keep the audit notes adjacent to the code for whoever triages first.

Scaling. The load vector is the query firing on every admin dashboard load per user, not the card component. Cap rows server-side at 5–10 — the full result set is fetched regardless of frontend truncation. Eager-load anything resolved across relationships or you have a per-load N+1 on your highest-traffic back-office page. A short-TTL cache around the backing query is cheap insurance on large tables. Card count scales better than card size: three focused cards read better than one tall table.

Failure modes and detection.

• Stored XSS via v-html — highest severity, lowest detectability. Gate at code review, before any dashboard exposure.
• Unauthorized row exposure from an unscoped query — silent, shows plausible data to the wrong people. Gate at code review; test as a low-privilege account.
• Blank card from unpublished/unbuilt assets — no error surface. Check public/vendor/ and the compiled bundle before debugging PHP.
• Nova upgrade breaking the Vue component — symptom appears as a degraded dashboard bundle, misattributed to Nova itself.
• N+1 degradation as the backing table grows — reads as "Nova is slow" rather than "our card is slow." Add a query-count assertion during the spike.
• Silent staleness if caching is added without a key/refresh strategy.

Ramp-up. Low. One PHP class with one-line fluent setters; an engineer new to Nova cards is productive in half a day with the source open. The durable return is the reference value — a working example of Nova card anatomy that shortens the first in-house custom card whether or not the fork survives. Timebox the spike to one day: if the Vue side does not render cleanly against your Nova version, build in-house. Fifty to 150 lines against Laravel\Nova\Card is cheaper than debugging an unmaintained fork, and that in-house build is the default outcome any adoption decision should be justified against.