Nova Linkable Metrics Laravel Package

Technical Evaluation

Architecture fit. Purely presentational. The package extends Nova's built-in Value, Trend, and Partition metric classes and ships a small Vue card wrapper that turns the card into an anchor. No migrations, no service provider doing anything clever, no request-path cost beyond rendering an <a href>. It composes cleanly into an existing Nova 4 admin panel that already ships metric cards. It does not fit if the drill-down answer lives in a custom page, an external BI tool, or a third-party system — the mechanism assumes a destination route, typically a Nova resource index with a filter query string.

Integration feasibility. Mechanically cheap: composer require plus php artisan nova:assets. The real cost is discovery and filter design, not installation. There is no documentation beyond README feature bullets and a 5.0.1 release note — the source is the API reference. A Nova-fluent developer needs roughly half a day to read src/, identify the fluent setter (the description never names it), and wire one card end-to-end. The capability is a trait plus a Vue wrapper; a parallel in-house build is half a day to a day. That makes this a genuine build-vs-buy tiebreaker rather than an obvious buy.

Technical risk. Concentrated in one place: Nova major-version coupling. Nova is paid and closed-source; the card-render override is coupled to Nova 4 internals, so "4.x" is not a sufficient compatibility claim — validation must be against the exact Nova patch version. Nova 5 exists and is unaddressed in the release notes. Nova upgrades are typically mandatory (security, PHP version), so this becomes a hard decision at the next major, not a hypothetical. Secondary risk: 21 stars, 0 tracked dependents, small-agency maintainer. Nova packages are overwhelmingly consumed in private repos, so dependents is a weak proxy for real usage — but there is no public battle-testing evidence, and MIT licensing plus a September 2025 release only mitigates this, it doesn't resolve it.

Key questions to answer before committing.

• Does the package's composer.json permit the exact Nova patch and illuminate/* versions we run, and is there a stated Nova 5 position?
• What is the actual API surface — is linking opt-in per metric (trait/property), what is the fluent setter called, and does it accept a resource class + params, a raw URL, or a closure?
• Which metric types are covered — Value, Trend, Partition, and Progress?
• Are there authorizedToSee / authorization hooks, or is hiding the card on us to implement?
• Is there target-window control and open-in-new-tab behavior, as the description implies?
• What does test coverage look like? For a package this size, the tests are the documentation.

Integration Approach

Stack fit. Laravel + Nova 4.x + a Vue asset build. No infrastructure, no database, no vendor relationship. Precondition: a deploy pipeline that runs nova:assets and correctly cache-busts published JS. If assets are CDN-served, hash verification on deploy is mandatory, not optional.

Migration path. None required — everything is additive. Adoption is annotations on metric classes plus publishing assets; rollback is annotations out, composer remove, clear published assets. Write that revert procedure down before rollout so an upgrade breakage has a five-minute mitigation. Mirror the repo internally at adoption time so a fork is always available.

Compatibility. Pin the exact version in composer.json — no ^ floating across Nova minors. Validate against the installed Nova patch, not the major. Note that CI needs Nova credentials (paid, closed-source), which affects where smoke tests can actually run.

Sequencing.

1. Confirm constraints — open the package's composer.json and match against installed Nova patch and PHP/Laravel versions. This is the walk-away checkpoint.
2. Read src/ to map the real API surface against the key questions above.
3. Pick one Value metric that maps cleanly to a filterable resource index and wire it to a single destination.
4. Apply the filter in the Nova UI, copy the resulting URL verbatim as the link target — do not hand-construct the filter query string. Nova's filter encoding has changed across versions and this is the top source of "link works but shows the unfiltered list."
5. Non-prod proof as a non-admin user: land on the right filtered index, and confirm the destination is something that user is allowed to see.
6. Add a CI smoke test asserting a known metric's generated URL resolves.
7. One dashboard → verify → sweep the rest, one metric class per link.

Operational Impact

Maintenance. We are the maintainer of last resort. Mitigations are cheap and non-optional: pin the version, mirror the repo, document the revert, and add a line to the Nova-upgrade checklist — verify or fork linkable-metrics. Budget a fork-ownership line item at the next Nova major. Under MIT, for a few hundred lines, this is an acceptable conscious decision rather than a hidden liability.

Support. No documentation, no issue SLA, small maintainer. Whoever implements this becomes the internal SME by default. An internal runbook covering the API surface found in src/, the link/filter conventions used, and the revert steps is the real deliverable — the package itself is small.

Scaling. Technically trivial (it's an anchor href). It scales poorly in scope: one metric class per link, and filter definitions should live in PHP as named Nova filters rather than in URL strings, or they rot silently when the schema changes. The bigger scaling risk is stakeholder expectation — this adds navigation, not data, segmentation, cohorts, or history. Position it honestly as "click the number to see the list," not "let me pivot on that list." If the ask escalates to exploration, exports, or non-Nova consumers, that's a different product decision (Metabase/Looker/Power BI or a Nova tool), and this package will hit a wall within a sprint.

Failure modes. All quiet, which is the worst kind for a dashboard — none throw an exception at render time:

1. Link disappears after a Nova patch — published assets didn't make it through the build pipeline or the CDN cache-busted wrong.
2. 404 on click — route or filter key changed; the metric still renders.
3. Filter drift — link resolves but shows an unfiltered or differently filtered list because the query-string encoding diverged from the app's filter conventions.
4. 403 on click — the card advertises access the viewer lacks. A clickable number that 403s is worse than a plain number.

Mitigations: authorizedToSee on the card plus a real authorizedToViewAny policy on the destination; a CI smoke test asserting a known metric URL resolves; asset hash verification inside the deploy pipeline, not just locally; one browser click-through in staging per rollout.

Ramp-up. Half a day for a Nova-fluent developer to reach a working single card; a day-plus for someone new to Nova. Most of the implementation time is the filter — deciding what list the number means — not the metric wiring. Scope discovery to real clicks: if no stakeholder has asked "can I click this?", park it. If the answer lives outside a filterable Nova resource, this is the wrong layer.