Custom Table Laravel Package

Technical Evaluation

Architecture fit. dytechltd/custom-table is a Laravel Nova dashboard card, not general-purpose infrastructure. It plugs into Nova's card extension point (a PHP Card subclass plus a compiled Vue component) and renders a configurable model query — orders, posts, users — as a table on the Nova dashboard. For a team already running Nova, that is an idiomatic fit: cards are the sanctioned customization surface, registration is a one-liner in NovaServiceProvider::cards(), and the package's scope is deliberately narrow (pick a model, pick columns, pick a limit/order). It carries no migrations, no service provider side effects on application data, and no runtime coupling outside the Nova request path. Architecturally it is low-risk; chronologically it is high-risk.

Integration feasibility. The mechanical integration is trivial: composer require, register the card, publish and tune its config. Realistic effort is under a day for a Laravel developer with Nova experience. The gate is not effort, it is eligibility — Nova is a paid, licensed product, and the package's release date (2020-11-18) places it in the Nova 3.x / Laravel 7–8 / Vue 2 era. Nova 4 moved to Vue 3 with reworked asset and card APIs. Any team on Nova 4 or 5 should assume the shipped JS bundle will not load and the PHP card contract may not match.

Technical risk. The dominant risk is abandonment, not design. Four stars, zero dependents, and no release in roughly five years means no security patching, no compatibility fixes, and no issue triage. Secondary risks: the model query is likely unscoped, so a card surfacing "latest orders" may leak records to Nova users who lack permission to view them; unbounded or poorly indexed queries could slow the dashboard; and the compiled asset pipeline makes breakage silent — the card renders empty rather than erroring after a Nova upgrade. Treat this as a reference implementation to fork, not a dependency to trust.

Key questions.

• Which Nova major version are we on, and does the card's PHP contract and Vue bundle still match it?
• What is the license, and does it permit vendoring into our codebase?
• Does the card apply Nova authorization/policy scoping to its query, or does it bypass it?
• Can a first-party Nova metric (value/trend/partition) satisfy the same requirement with zero custom code?
• What are the actual composer constraints, and do they resolve alongside our Laravel/PHP versions?
• Is the "opportunity" signal (10.77) driven by real search demand, or is this a stale artifact?

Integration Approach

Stack fit. Assumes Laravel with Nova installed, PHP 7.x-era constraints, Vue 2 toolchain. Verify the composer lock resolves before committing to anything; on Laravel 9+ this is the first thing that will fail.

Migration path. Three options, in order of preference:

1. Reimplement natively (~1–2 engineer-days): a custom Nova card generated via php artisan nova:card, with a scoped query and explicit column config. Removes the dependency entirely and inherits Nova's supported extension surface.
2. Fork and vendor (~1 day plus ongoing ownership): copy the source into our repo, upgrade the Vue component to our Nova version, add authorization scoping and tests, publish as an internal package. Preserves the look and feel with no external dependency.
3. Use as-is (not recommended): only defensible for a throwaway internal dashboard on Nova 3 with a hard sunset date.

Compatibility. Confirm Nova major version, Laravel version, PHP constraint, and whether the card's published assets conflict with our Tailwind/Vite build. If any mismatch exists, options 1 or 2 are the only viable routes.

Sequencing. (a) Spike: install in a branch, confirm the card renders under our Nova version. (b) Decide build-vs-fork based on how much of the component survives. (c) Harden: authorization scoping, query limits, caching, index review. (d) Ship as an internal package with a test and a documented owner. (e) If the spike fails on compatibility, close it out and go straight to a native card — the feature is small enough that the fallback cost is measured in hours, not weeks.

Operational Impact

Maintenance. Effectively 100% ours from day one. Budget a small recurring line item for Nova major upgrades (roughly every 18–24 months) plus ad-hoc fixes. There is no upstream to absorb that work.

Support. Community repository, no SLA, no maintainer responsiveness expectation, and a small enough user base that issues are unlikely to be triaged at all. Internal ownership must be assigned explicitly; unowned dashboard widgets rot quietly.

Scaling. Cards execute on dashboard load, per user, on every visit. Unbounded "latest N" queries against large tables are the predictable failure: add a hard limit, cache the result with a short TTL, and verify indexes cover the ordering column. At modest user counts this is fine; on a busy admin panel it becomes a measurable latency contributor.

Failure modes.

• Silent blank card after a Nova upgrade — asset or component API drift; no error surfaced to the user.
• Composer resolution failure on modern Laravel/PHP — blocks the whole install, discovered early.
• Unauthorized data exposure — card query bypasses Nova policies, showing records to users who shouldn't see them.
• Dashboard latency / query timeout on large tables without limits or indexes.
• Orphaned code — no owner, no tests, breaks during an upgrade nobody connects to it.

Ramp-up. Low. A Laravel developer familiar with Nova can read the whole package in under an hour. Fixing the front-end after a Nova major upgrade requires Vue competency, which is the one skill worth confirming on the team before choosing fork-and-own over reimplementation.

Assessment. The capability is worth having; this package is not worth depending on. Its value is as a working reference for a small, well-understood feature. Recommend a one-day spike, then almost certainly reimplement as a native Nova card with explicit authorization scoping and a named owner — capturing the requirement while eliminating the abandonment, compatibility, and data-exposure risks that come with a five-year-stale, zero-dependent dependency.