Nova Package Discovery Laravel Package

Technical Evaluation

Architecture fit. Nova Package Discovery is a leaf-node dashboard card in the admin plane: it owns no schema, no domain logic, no queues, and no multi-tenancy, so its blast radius is small and it is trivially removable. It only "fits" a Laravel + Nova shop where in-admin package discovery is a genuine workflow rather than a curated link to novapackages.com or Packagist search. For a TPM the important framing is that the code is negligible and the idea is the asset — a cached ecosystem-discovery surface inside the admin UI. The repository is also internally ambiguous: the product description claims automatic Nova tool/card auto-discovery, while the release history, single v1.0.0 tag, and peer assessments describe a read-only discovery card. That inconsistency itself is a maturity signal and must be resolved by reading source before any decision.

Integration feasibility. Mechanically a Composer require, a card registration in NovaServiceProvider, and asset publishing. Practically constrained: the only release (v1.0.0, 2020-09-12) targets Laravel 7+ and the Nova 2/3 era (PHP 7.2–7.4). On a current Nova 4/5 and modern PHP/Laravel stack, expect Composer constraint conflicts and stale published assets needing an old Node toolchain to rebuild. Feasibility is high on a legacy stack and low on a current one; either way the value is a temporary awareness widget, so treat any use as a fork or reimplementation rather than a dependency add.

Technical risk. High, concentrated in abandonment rather than complexity. Archived with no upstream means no security patches, compatibility bumps, or issue triage. Fifteen stars and zero dependents means effectively no community validation or crowd-sourced fixes. A runtime call to a third-party index is the classic silent-failure pattern — endpoint changes, rate limits, or retirement leave a stale or empty card with no owner. The highest-severity risk is supply-chain upgrade drag: an abandoned package can pin transitive constraints and block a Laravel/Nova platform upgrade later. Treat any persistence or outbound HTTP surface as unreviewed until read.

Key questions.

1. Is package discovery a real admin workflow, or does a curated link to an official index satisfy it for a fraction of the cost?
2. Which Nova major, Laravel, and PHP versions are we on, and does the 2020 constraint set resolve against our lockfile at all?
3. Is this a discovery card or an auto-registration tool? The description and the release history disagree — which behavior are we actually evaluating?
4. Does the card hit a third-party endpoint on every render, and is that endpoint still live and stable?
5. Does it cache, persist, or log anything that creates a data-handling or freshness obligation?
6. Are we prepared to own a fork indefinitely, or is a ~200-line in-house card cheaper than adopting unfamiliar, abandoned code?

Integration Approach

Stack fit. Laravel + Nova 2/3-era applications only. It has no role in headless Laravel, API-only services, or non-Nova admin panels, and should be assumed incompatible with Nova 4/5 until proven otherwise. If the stack is current, the correct TPM move is to treat the repo as a design reference and build the card in-house.

Migration path. Plan for replaceability from day one; there is no upstream upgrade path. Three credible options in ascending strategic cost:

• (a) Fork into our namespace, pin composer.json to the fork with an explicit version alias, and accept compatibility work at every Laravel/Nova upgrade.
• (b) Reimplement as a small in-house Nova card calling Packagist's search API with a cache, timeout, and kill switch — usually cheaper than owning a fork of unfamiliar code, and it removes the abandoned-dependency liability entirely.
• (c) Decline and record the decision in the tech radar as "avoid — archived" so it does not resurface as a suggested dependency.

For most teams, (b) is the right recommendation: it preserves the product idea while eliminating maintenance and supply-chain risk.

Compatibility. Validate against the real lockfile in a throwaway branch — PHP constraint, laravel/framework, laravel/nova, and Guzzle versions — before committing. Expect conflicts, and expect published frontend assets to be stale relative to current Nova asset conventions; a rebuild may require an old Node toolchain, which is itself a cost. Confirm the card registers cleanly under our Nova version and does not collide with existing dashboard cards.

Sequencing.

1. Confirm the business need and Nova generation; if either fails, stop and record the rationale.
2. Timebox a spike in a disposable branch with outbound egress permitted; observe the network calls the tool actually makes.
3. Read the source for data source, caching behavior, and any persistence — the go/no-go gate, and the point where the card-vs-auto-discovery ambiguity is resolved.
4. Security and license review of any fork, plus an explicit ownership decision.
5. If approved: internal fork or reimplementation, mandatory caching layer, feature flag/kill switch, and a documented sunset trigger.
6. If declined: log it in the tech radar as "avoid — archived" and move on.

Operational Impact

Maintenance. Zero upstream maintenance — the full burden transfers to us on install. A fork means recurring compatibility work at every Laravel/Nova upgrade even though the feature never changes; a reimplementation bounds that maintenance and makes it legible to the team, which is the TPM's preferred end state.

Support. No vendor, no maintainer, and no dependent community to lean on. Every incident routes to our on-call with no escalation path upstream. The absence of a support owner — not the code — is the defining operational cost and should drive the build-vs-buy call.

Scaling. Compute is irrelevant: admin-only, low concurrency, no write path. The real scaling concern is external — per-render calls to a third-party API make latency and rate limits user-visible on the Nova dashboard. Require an hours-scale cache TTL and a graceful degradation path so the dashboard never blocks on a dead endpoint.

Failure modes.

• Upstream index changes, rate-limits, or retires → empty or stale card with no fix available.
• Egress blocked or DNS/TLS failure in a locked-down environment → card errors or times out on the dashboard.
• Stale cached data presented as current, misleading admins about package recency and popularity.
• Nova/Laravel upgrade blocked by an unresolvable Composer constraint — highest impact, because it degrades the whole platform rather than one card.
• Asset registration breaks on a Nova major bump with no upstream patch.

Ramp-up. Technically shallow: standard Nova card conventions, readable end-to-end by a mid-level Laravel developer in an afternoon. The real ramp-up is governance — deciding ownership, cache policy, data-freshness rules, and a sunset trigger, and socializing why an abandoned package is being introduced at all. That decision overhead exceeds the engineering effort and should be resolved before any code is written. The TPM's recommendation is to frame this as a reference artifact and tech-radar entry, not a dependency, and to revisit the idea with a small in-house build only if an admin discovery workflow is validated by actual usage or user research.