Nova Package Discovery Laravel Package

Product Decisions This Supports

• Build vs. buy vs. skip — and the answer here is "build a little or skip." The artifact is not a purchasing candidate: archived, 15 stars, zero dependents, one release (v1.0.0, Sept 2020) pinned to Laravel 7+/Nova 2–3. Its value to a PM is as a reference implementation that shortens the "should we build in-admin package discovery?" conversation from weeks of debate to a timeboxed spike.
• Validating the discovery UX before funding it. It gives design and engineering a concrete, already-built sketch of what an in-dashboard discovery surface looks like — card placement, package metadata, freshness cues — so we can test the hypothesis "do admins benefit from in-product package discovery, or is a curated link to an official index enough?" with real usage rather than opinion.
• Roadmap input on ecosystem momentum — with heavy caveats. The premise (surface newest/most-popular Nova packages inside the admin) is one weak signal for which add-on categories are gaining traction and whether a first-party feature or partnership is warranted. Treat it as 2020-era, frozen data; never a standalone input to prioritization.
• Admin/internal tooling scoping. A defensible low-stakes use: an internal awareness card listing relevant packages for the team, if we own the code, cache aggressively, and accept that the feed ages.
• Dependency-hygiene policy evidence. Its archival status is a concrete teaching example when setting internal standards — how a trivial admin widget can pin Composer constraints and block a platform-wide Laravel/Nova upgrade. Useful for the tech radar and ADR templates.
• Specification and positioning discipline. This is the sharpest PM lesson in the package: the description claims it auto-discovers and registers installed Nova packages (a NovaServiceProvider boilerplate remover), while the release history and evaluations describe a read-only discovery card surfacing popular packages. Those are entirely different products with different users and success metrics. For us the takeaway is process: a one-line value proposition that two competent readers interpret differently is a scoping failure, and we should catch it in the spec, not in the install.
• What it should not drive: roadmap prioritization from its popularity signals, any customer-facing commitment, pricing or packaging decisions, or any plan that assumes ongoing data freshness.

When to Consider This Package

• As a design reference only. Worth a 30-minute read if we want to see how Nova package discovery was approached in 2020 before designing our own card. That is the primary, safe use.
• When validating the concept, not adopting the dependency. The reusable asset is the idea plus the thin pattern (external index → cache → Nova card), not the code.
• As a disposable internal prototype on a legacy stack. Only if we are explicitly on Nova 2/3 + Laravel 7-ish, the constraints resolve against our lockfile, we accept archival/compatibility/security risk, and we name an owner and a sunset date before writing code.
• Never for anything production-facing or customer-visible. No maintainer, no issue triage, no security patches, no vendor support, and an external data source with no SLA.
• Look elsewhere when reliability, upgrade velocity, or data freshness matter. Prefer official Nova/Packagist/GitHub sources, an actively curated index, or a small in-house card built on public APIs with caching and a kill switch.
• Hard stop signals: we are on Nova 4/5 or current PHP/Laravel (expect Composer conflicts and stale published assets); we cannot name an owner; the behavior we actually need is auto-registration of tools/cards rather than a discovery card; or the only justification is "it's free and quick." A ~200-line internal reimplementation is almost certainly cheaper than owning a fork of unfamiliar, abandoned code across the next major upgrade.

How to Pitch It (Stakeholders)

• To executives: This is a cheap source of inspiration for ecosystem discovery inside the admin experience — not a strategic dependency. It is archived, unmaintained, and has negligible adoption, so do not fund it as a purchase or place it on the dependency roadmap. The only budget implication is a small, timeboxed spike if we want to test the concept; expected cost is hours-to-days, not a project.
• To engineering: Do not add it as a production dependency. If package discovery proves useful, rebuild it as a thin, maintained Nova card against Packagist/GitHub APIs with an hours-scale cache, a timeout, a feature flag/kill switch, and explicit Nova/Laravel version support. Use the original only as a reference for the data contract and card UX — and note the description/behavior mismatch, so nobody wires it up expecting auto-registration.
• To design and product: Use it to answer one question — is in-product discovery a real admin workflow, or is a curated link to an official index sufficient? Pair the prototype with actual usage measurement; do not treat its popularity data as current market signal, since the feed stopped moving in 2020.
• Recommendation: Keep it as a reference-only artifact and log it in the tech radar as "avoid — archived." Revisit the idea with an in-house build only if an admin discovery workflow is validated by usage or user research, and write the one-line value proposition unambiguously before anyone scopes it.