Nova Tooltip Field Laravel Package

Technical Evaluation

Architecture fit. This package is a leaf dependency that extends Laravel Nova's field API — a PHP Field subclass paired with a compiled Vue component that renders an info icon with hover copy beside an admin form input or detail value. It has no persistence, no HTTP surface, no queues, no migrations, and no server-side data handling. For a TPM, that means the integration risk is confined to one surface: an internal, authenticated admin panel. The binding constraint is environmental rather than architectural. The package only exists inside Nova, a commercial closed-source dependency whose custom-field API has broken at every major release (1.x → 2 → 3 → 4 → 5). A field first and last shipped on 2018-11-14 was authored against the Nova 1.x generation — almost certainly pre-Vue 3 and pre-Tailwind. Architecturally it is a tiny, well-bounded artifact sitting on top of a surface that has since been rebuilt underneath it.

Integration feasibility. Cheap to describe, awkward to land. The nominal path is composer require plus one line in a fields() method. The realistic path is resolving Composer constraints against a modern Laravel/PHP/Nova stack, then discovering the shipped asset is a prebuilt 2018 JavaScript bundle with no recoverable build step — which converts "install a package" into "fork and rebuild front-end assets" or "read the source and reimplement." Either outcome is roughly a developer-day. That is not a large absolute cost, but it is engineering time spent to acquire a maintenance liability for a capability the platform now provides natively via Field::help().

Technical risk, ranked by expected impact.

1. Abandonment — high likelihood, low severity. One release, 10 stars, zero dependents, no maintenance signal in six-plus years, no upstream to escalate to. The code is small enough to read, so severity stays contained, but there is no supported path.
2. Version lock — high likelihood, medium severity. The only validated target is a Nova generation we no longer run. Every future Nova upgrade becomes an internal port rather than a dependency bump, and custom fields are consistently among the first things to break.
3. Asset trust — low likelihood, medium severity. A compiled JavaScript blob of unknown provenance loading into an authenticated admin surface is unverifiable without source review and rebuild. There is no server-side data handling, so the problem is disproportionate supply-chain review cost rather than a live exploit.
4. Accessibility and touch — medium likelihood, medium severity. Hover-only affordances fail keyboard and screen-reader users and degrade on tablets. Where internal tools carry accessibility obligations, this is a compliance question, not polish.
5. Silent degradation — medium likelihood, medium severity. After a Nova upgrade this field is more likely to render blank or unstyled than to throw, so the failure is discovered by an operator misconfiguring a record rather than by a deploy.

Key questions to close before any commitment.

• Which Nova major is the actual production target, and does the repo's composer.json install against it at all?
• Does native Field::help() already satisfy the requirement? Answer first — cheapest possible resolution and may close the ticket outright.
• If native help text is insufficient, what concretely is missing: formatted text, links, examples, conditional visibility per record? A written gap statement decides fork vs. rewrite.
• Is the Vue source present and buildable, or is only a compiled bundle shipped? This is the fork/reimplement decision point.
• Is tooltip copy static meta, or must it vary per record or user?
• Who owns the field when the next Nova upgrade lands, and is that named in the upgrade plan?

Verdict. The underlying need — contextual guidance on complex or risky admin fields such as billing rules, status transitions, regional settings, or deprecated flags — is real and recurring. This artifact is not the vehicle for meeting it. Treat it as a reference implementation for a capability Nova now approximates natively.

Integration Approach

Stack fit. Laravel + Nova + Composer, nothing exotic, no transitive weight, no service dependencies. That lightness cuts both ways: trivial to remove and equally trivial to replace. Because there is no lock-in benefit, the usual "adopt to save build time" argument doesn't apply — the build is the smaller cost.

Recommended path: reimplement rather than adopt. Two defensible options, neither of which puts the published package into composer.json:

1. Fork and vendor. Copy the field class and Vue component into app/Nova/Fields/ or an internal acme/nova-fields package, strip stale Composer constraints, rebuild against the current Nova toolchain, and own it. The MIT licence makes this clean from an IP standpoint.
2. Reimplement. Nova's field API turns a tooltip field into roughly a hundred lines of PHP plus a small Vue component. Against a 2018 codebase of unknown quality and unknown build pipeline, rewriting is usually cheaper than porting, and it yields something the team can actually test.

Default to reimplementation unless source review shows the component is clean and its build step is recoverable. Make the call on inspection, not on the README.

Migration path and compatibility validation. Before committing anything, stand up a sandbox Nova install at exact production parity — same Nova major, Laravel, PHP, and Node toolchain — and record every constraint conflict. Specifically check the Vue major version, the asset manifest format, and whether the field depends on removed Nova mixins or obsolete Nova.booting registration patterns. If the team is genuinely on a legacy Nova 1.x panel with no near-term upgrade, the published package can be pinned and used as-is under an explicit exception that carries a removal date tied to the next admin upgrade.

Sequencing.

1. Confirm Field::help() is insufficient and document the gap concretely. If it's sufficient, close the ticket here — highest-value step in the sequence.
2. Source and licence review; confirm MIT and assess whether the Vue source is present and buildable.
3. Sandbox install at production parity; capture conflicts and record a go/no-go.
4. Fork or reimplement; add Pest/PHPUnit coverage for resolve and meta, plus a smoke assertion that the component renders.
5. Ship to a single low-traffic resource behind the normal deploy process and observe for a sprint.
6. Expand only if adoption is real; otherwise remove the field and keep the test.

Scope discipline. Keep this to internal admin tooling. It should not appear on a roadmap or be bundled with customer-facing work. At most it is a backlog polish item inside an admin-panel cleanup, prioritized below anything revenue-adjacent.

Operational Impact

Maintenance. Effective upstream maintenance is zero, so the full burden transfers internally the day it ships. The realistic line item is recurring work at every Nova major upgrade, since custom fields are among the first things to break and there is no vendor to file an issue with. Attach a reminder to the Nova upgrade calendar and name an owner for the internal field. If the field is adopted as published for a legacy panel, pin the version and record the exception in the dependency register so it surfaces during the next upgrade review.

Support. There is effectively no upstream support channel: one release, no issue triage, no community of dependents to lean on. First-line support therefore lands on the internal team. Document where the field lives in the admin panel so support agents know whether a missing tooltip is a bug or an expected post-upgrade degradation. Set expectations with the ops team that these hints are best-effort and not a validated knowledge base.

Scaling. The package itself has no scaling dimension — it's static copy on an admin form with no read/write load beyond the page render. The scaling concern is organisational: every additional Nova panel or field it's applied to is another surface owned by an unmaintained component. Favor an internally controlled field so breadth of adoption is a deliberate choice rather than a spreading liability.

Failure modes. Ranked and pre-triaged: (1) post-upgrade silent blank — field renders nothing and users misconfigure records; mitigate by a render smoke test and a support runbook; (2) Composer conflict blocking an unrelated dependency update; mitigate by forking or reimplementing; (3) accessibility failure discovered in an audit; mitigate by building keyboard-focusable, screen-reader-labeled markup from the start; (4) touch-device invisibility on tablets used on shop floors or in support; mitigate by supporting click/tap as well as hover. The common thread is that these failures are silent, so a small amount of internal test coverage and a named owner is worth more than the package saves.

Ramp-up. Adoption is easy to describe but demands an owner. The ramp is: (1) a TPM confirms the native-help-text gap is real and scopes it to a specific admin screen, (2) engineering chooses fork vs. reimplement on inspection, (3) a short internal package or field ships with tests, (4) a single resource gets it behind the normal deploy process. Total effort is on the order of a day or two — small enough that the business case rests entirely on the clarity of the requirement, not on the package. The correct TPM posture is to treat this as a UX backlog item with a defined trigger, not a dependency to evaluate.