Nova Tooltip Field Laravel Package

Technical Evaluation

Architecture fit

• Narrow-fit component: it is only relevant inside a Laravel Nova application, and Nova is a licensed, closed-source first-party admin panel. Adoption is gated on an existing Nova license and a specific Nova major version.
• Functionally it is a presentational field, not a data-bearing one. It renders a tooltip in a resource form/detail view; it does not model persistence, validation, or querying. That means zero coupling to business logic — good for risk containment, bad for leverage (it solves a cosmetic problem, not a product one).
• Overlap with the platform: Nova fields ship a native ->help('…') method that already renders help text. Before treating this as a dependency, verify what it actually adds (icon, placement, rich content, index-column visibility, conditional display). A meaningful chance this package is 80% redundant.
• Front-end architecture is the crux: a Nova custom field is a PHP Field subclass plus a Vue component compiled into Nova's asset pipeline. That couples us to Nova's internal Vue version (Vue 2 on Nova 3, Vue 3 on Nova 4+).

Integration feasibility

• Very low effort: composer require, instantiate in a Resource's fields() method. No migrations, no queues, no external services, no meaningful service-provider config.
• Blast radius is a single render path and reversible in one commit.
• Display-only, so no data migration is implied — but confirm it is not writing to a column before assuming that.

Technical risk

• Maintenance risk is high and dominant: single release (2021-07-08), 4 stars, 0 dependents, no evidence of ongoing stewardship. Effectively an unmaintained artifact.
• Version-drift risk: it predates Nova 4 (Vue 3), so it is very likely incompatible or at minimum untested on Nova 4/5. On Nova 3 the risk is low; on Nova 4+ treat it as broken until proven otherwise.
• Security risk is low but non-zero and concentrated in one question: does it render tooltip content as raw HTML (v-html)? If yes and any content is user- or tenant-supplied, that is an XSS vector. The codebase is small enough to read in full in an hour.
• Supply-chain risk is low-moderate: unknown vendor namespace, single publish. Pinning and auditing covers most of it.
• Abandonment risk is unmitigated by contract — MIT plus an inactive maintainer means we own it the moment we fork.

Key questions

1. Which Nova major are we on, and is it pinned? Does the package's laravel/nova constraint actually match?
2. What does this give us over Nova's native ->help()? Enumerate the delta explicitly.
3. Is tooltip copy developer-authored and static, or does it include user-supplied strings? This determines the XSS surface.
4. Accessibility: is the tooltip keyboard-focusable and screen-reader announced, or hover-only? Hover-only is an a11y regression we would be importing.
5. Localization: is content translatable at the call site via __(), or baked into the component?
6. One resource or a shared field library? This decides vendor vs. fork.

Integration Approach

Stack fit

• Laravel + Nova only. If the product doesn't run Nova, the package has no applicability — it will not help a custom Blade, Livewire, or Inertia admin surface.
• It follows standard Nova conventions exactly (composer require + fields()), so there is no architectural deviation to justify.

Migration path

• On Nova 3: direct install, pin an exact version, done.
• On Nova 4/5: assume breakage. Two options — (a) fork, port the Vue 2 component to Vue 3 (Composition API / defineComponent, emits, mixin removal), and republish internally; or (b) drop it and use native ->help(), accepting a cosmetic delta. Option (b) is usually the correct business call.
• If we fork, move to an internal VCS path/vcs repository, remove the public dependency, and register it as internal so it stops being read as third-party code.

Compatibility

• Check the declared constraints on laravel/nova and php. A 2021 package likely pins ^3.0 — that is the blocker, not the PHP version.
• Asset compatibility is the silent failure mode: Nova compiles field components at build time, and a Vue 2 component in a Vue 3 pipeline can fail at build or fail at render with no useful error.

Sequencing

1. One-day spike in a dev environment: install, render on a single resource, test on our actual Nova version. Cheapest possible falsification.
2. Read the source in full; close out the XSS and accessibility questions.
3. Decide in order of preference: native ->help() → internal fork → public dependency.
4. If adopted, pin the version, commit composer.lock, add a dependency-review/composer audit gate, and record it on the tech radar as hold / vendored.
5. Only then roll out to further resources — through a shared internal field factory, so a future swap is one file.

Operational Impact

Maintenance

• Assume we own it. No upstream commits since mid-2021 means any bug we hit is ours. Budget it as internal code, not as a dependency.
• Real ongoing cost is the Nova upgrade treadmill: every Nova major bump forces a re-check of every third-party field, and this one is at the top of the list because it is unmaintained.
• The absolute burden is small — tens to low hundreds of lines — but it is nonzero and permanent.

Support

• Community / author best-effort only, with no evidence of recent responsiveness. No SLA, no security advisory channel. Security notification becomes our responsibility via dependency scanning.
• Documentation is a README at best; expect to read source to learn behavior.

Scaling

• Runtime cost is negligible: a presentational Vue component with no queries, no large payloads, no per-request backend work beyond field metadata. No impact on horizontal scaling, queue throughput, or DB load.
• The only scaling concern is organizational: N resources × M fields means N×M places to touch when it breaks. Centralize field construction to cap that.

Failure modes

• Silent render failure after a Nova upgrade (component not registered, build error) — degrades to a missing tooltip, not an outage. Low severity, easy to miss in QA.
• Asset pipeline break on Vue version mismatch — in the worst case this breaks the whole Nova build, which is an admin outage. This is the failure mode that justifies the spike.
• XSS if content is rendered as HTML and any part is user-controlled — high severity, low likelihood.
• Accessibility regression: hover-only tooltips exclude keyboard and screen-reader users; a compliance issue in regulated or enterprise contexts.
• Supply chain: package yanked or repo deleted — mitigated by composer.lock plus a vendor mirror.

Ramp-up

• Hours, not days. Any Laravel developer who has written a Nova field is productive immediately; the only learning curve is Nova's field API if the team hasn't used custom fields before.
• Decision cost dominates implementation cost. Spend the effort on the spike and the source read, not on rollout planning.

TPM bottom line: low value, near-zero adoption, near-zero integration cost, and one real open question — whether it is redundant with Nova's built-in ->help(). Run a one-day spike, default to native ->help(), fall back to a pinned internal fork, and do not carry a public dependency for cosmetic tooltip behavior.