Nova Tooltip Field Laravel Package

Product Decisions This Supports

• Admin-panel usability, not product strategy. This is a small MIT-licensed Laravel Nova add-on that renders a hover tooltip beside an internal admin form field. It informs exactly one narrow decision: whether to invest in making back-office forms self-explanatory for ops, support, and content teams who don't hold the underlying domain model in their heads. It has no customer-facing, revenue, conversion, or retention implications and should never appear on a customer roadmap.

• Reducing training and support load — the real requirement to scope. The valuable framing is field-level guidance on complex or risky inputs: billing rules, status transitions, regional settings, deprecated flags, tax treatment. A one-line hint at the point of entry prevents misconfiguration and the downstream support ticket. Treat that as the requirement to solve; the package is only one possible vehicle, and a weak one.

• Build vs. buy resolves toward build (or use what Nova already ships). Modern Nova provides native Field::help() help text that covers the majority of this need. Any remaining gap — formatted copy, links out to policy docs, worked examples, conditional guidance per record — is roughly a one-day custom field. Adopting a 10-star, zero-dependent, last-released-2018 add-on trades a day of engineering for indefinite governance and upgrade overhead: negative ROI on the buy side.

• Roadmap impact: none. At most this is a backlog polish item inside an admin-panel cleanup, prioritized below anything revenue-adjacent. The low opportunity score (~35) is accurate: the need is real but small, and this artifact is the wrong vehicle for meeting it.

• When to revisit the capability (not the package). Legacy Nova 1.x/2.x panels mid-migration, or a documented design requirement for richer hover content than native help text where a custom field isn't yet scheduled. Frame that as a UX backlog item with a defined trigger, not a dependency to evaluate on its own.

When to Consider This Package

Consider adoption only if all of the following hold:

• You are on a legacy Laravel Nova 1.x-era install — the generation contemporary with the package's 2018 release. The last release predates Nova 2 and is very likely incompatible with Nova 4/5's Vue 3 / Tailwind field architecture.
• The target is an internal admin screen with no near-term upgrade path for that panel, and the need is genuinely urgent (e.g., an active misconfiguration problem costing support hours).
• Your dependency policy tolerates unmaintained packages for non-customer-facing tooling, with the version pinned in composer.json and a named internal owner for the fork.
• You explicitly accept ownership of the code: no releases in six-plus years, zero dependents, no ecosystem validation, no guaranteed PHP/Laravel/Nova compatibility.

Look elsewhere — or build in-house — if:

• You run Nova 3 or later (the overwhelmingly likely case). Try native field help text first; if insufficient, write a small custom field against the current toolchain. Both routes avoid abandoned-dependency and supply-chain review.
• You need accessibility (screen-reader-friendly, keyboard-navigable hints), localization, mobile/touch behavior, or test coverage for admin UI. A six-year-old hover-only widget is unlikely to meet modern a11y expectations, and hover fails on tablets and for keyboard users — a compliance question, not polish.
• Your team has a "no abandoned dependencies" policy, or you can't absorb the cost of vendoring and forking later.
• The requirement is customer-facing — that warrants a maintained, tested UI component, not an admin add-on.
• You require asset trust: a compiled 2018 JavaScript bundle loading into an authenticated admin surface is unverifiable without source review and rebuild.

Default path: reimplement the field in-house (~100 lines against Nova's field API, plus a small Vue component) or fork-and-vendor the MIT source into an internal field package. Either way, the published package does not enter composer.json.

How to Pitch It (Stakeholders)

Executive summary: This is a free (MIT) Laravel Nova add-on that shows hover hints next to fields on internal admin forms. It's a usability nicety for back-office tooling with no customer-facing or revenue impact. It has 10 GitHub stars, zero dependent projects, and no release since November 2018 — treat it as unmaintained reference code, not a supported product.

Recommendation: Do not adopt it as a dependency. The capability is largely built into modern Nova via native field help text, and any remaining gap is a small in-house build (~one day) owned by the team and testable. If a legacy Nova panel genuinely needs it before an upgrade, treat it as a time-boxed, version-pinned exception with a removal date tied to the next admin upgrade — do not roadmap it, and record it in the dependency register so it surfaces at the next upgrade review.

For engineering: It's a thin field wrapper — a PHP Field subclass plus a compiled Vue component — with no backend logic, persistence, or data handling, so the blast radius is small. The code is small enough to read, vendor, or reimplement. The realistic cost isn't the package; it's the review, pinning, and recurring migration work at every Nova major upgrade, where custom fields are among the first things to break — and this one fails silently, rendering blank or unstyled without throwing, which surfaces as a support agent misconfiguring a record rather than as a deploy failure. The valuable takeaway is the requirement — contextual guidance on complex or risky admin fields — which should be solved with native Nova help text or a small, internally owned, tested field. The low opportunity score reflects exactly that: the need is real but small, and this artifact is not how we meet it.