Nova Tooltip Field Laravel Package

Technical Evaluation

Architecture fit. marshmallow/nova-tooltip-field is a micro-package that does one thing: it registers a Laravel Nova field whose Vue component wraps Nova’s own stock Tooltip component. Architecturally it sits entirely inside the presentation layer of the Nova admin panel — no service provider business logic, no persistence, no queue/event surface, no external I/O. That is the best possible shape for a low-risk dependency: the blast radius is confined to how a single resource renders in Nova’s index/detail/form views. The important caveat is what it depends on. Nova’s internal Vue component library is not a documented public API; it ships inside a commercial, closed-distribution package. The moment this field renders Tooltip directly, it takes a hard coupling to Nova’s internal component names, props, and slot signatures. That coupling, not the package’s own ~100 lines of code, is the real technical characteristic to price in.

Integration feasibility. Straightforward: composer require marshmallow-packages/nova-tooltip-field, confirm the service provider is auto-discovered (or register it), and use the field class in a Nova::resources() field list. No migrations, no config publishing, no schema changes — a tooltip field is presentational and should not persist a column. The main feasibility gate is version alignment: Nova major versions have historically reshuffled the front-end stack (Vue 2 → Vue 3, Mix → Vite), which is exactly the class of change that breaks a component wrapping an internal UI primitive. Feasibility is therefore "yes, today" rather than "yes, durably."

Technical risk. Ranked:

• Internal-API coupling (high). Every Nova upgrade is a potential silent break. Failure is typically a blank field, a missing tooltip, or a JS console error that can take down the whole form render — not a clean PHP exception.
• Maintainer/bus-factor (high). 3 stars, 0 dependents, single-org publishing. There is effectively no community validation and no support path. The recent release date (2026-03-18) suggests the maintainer is alive, but one tag on a zero-adoption package does not establish a track record. Verify the tag actually exists against the repo and read the changelog before trusting the cadence signal.
• Build/distribution (medium). Nova tool packages either ship precompiled assets or require an npm install && npm run build step. If assets are precompiled, you inherit whatever Vue/Nova version they were built against; if not, you inherit a front-end build in your deploy pipeline.
• Render-safety (medium). Confirm tooltip content is escaped, not rendered as raw HTML. If the field accepts arbitrary strings from model data or editor input, an unescaped v-html is a stored-XSS vector inside an authenticated admin surface.
• Misuse risk (low). Since it is non-persisting, the failure mode is cosmetic, but a developer could mistakenly attach it expecting a stored value.

Mitigating factor: MIT license, trivial code surface. If the maintainer disappears or a Nova upgrade breaks it, forking and fixing is a same-day task, not a re-platforming.

Key questions.

1. Which Nova major versions are declared in composer.json, and does that cover our pinned Nova version — including the next one we plan to adopt?
2. Are compiled assets committed, and against which Nova/Vue version were they built?
3. Does the field declare a persistence column? Confirm it is display-only and safe on index/detail but not form-submit.
4. Is tooltip content escaped, or does it accept raw HTML?
5. What does this give us that Nova’s native helpText / ->help() does not? If the delta is "tooltip on index columns" only, that is a very small delta.
6. Who owns the fork if upstream goes stale — is there a named engineer and an internal fork path in the repo policy?

Integration Approach

Stack fit. Native fit for any Laravel + Nova application. Requires a licensed Nova install (which means a private Composer repository credential in composer.json and in CI). If our CI cannot resolve Nova’s private repo, this package’s test path is blocked before we start — that is a prerequisite to validate, not an afterthought. PHP and Laravel constraints should be checked against our supported matrix; a package this small often pins loosely and needs an explicit compatibility assertion.

Migration path. Effectively zero-cost and fully reversible, which is the strongest argument in its favor. Nothing to migrate: no tables, no data, no config, no stored state. Adoption means adding a field to one or two resource definitions; removal means deleting those lines and running composer remove. That reversibility lowers the cost of a pilot and makes a "try it, fork it, or drop it" decision cheap. The realistic migration is from ad-hoc inline HTML, helpText, or custom Blade partials to this field — a consistency and maintainability win, not a functional one.

Compatibility. The load-bearing constraint is the Nova major version, not PHP or Laravel. Treat Nova upgrades as a required regression test for this field specifically: render an index, a detail, and a form containing it, and check the browser console. Nova tool packages also frequently depend on the host app’s Vite/Mix configuration; confirm whether assets are published and whether they collide with our existing nova-components build.

Sequencing.

1. Audit (hours). Read composer.json, the field class, and the Vue component. Confirm escaped rendering, no persistence, and declared Nova constraints. Check the 2026-03-18 tag and changelog.
2. Sandbox proof (half a day). Install in a throwaway Nova app pinned to our exact version; verify render in index/detail/form and check console.
3. Pilot (1 sprint). Use it in one low-traffic internal resource. Measure: does it actually reduce code versus helpText, and does it survive a nova:assets rebuild and a deploy?
4. Decide (build vs. buy). If the pilot shows the delta over native helpText is small, replicate in-house instead — a custom Nova field wrapping the same internal component is roughly 50–100 lines and gives us ownership of the coupling without the third-party dependency.
5. Rollout or drop. If adopted, standardize across resource definitions and record the internal owner in the dependency register.

The honest TPM framing: this is a convenience micro-package. Adopt it only where it demonstrably removes duplicated markup, and treat in-house replication as a live alternative rather than a fallback.

Operational Impact

Maintenance. Near-zero routine code maintenance, but non-zero coupling maintenance. The package’s health is a function of a maintainer we have no relationship with and an upstream we do not control (Nova). Because it is MIT and tiny, the correct operational posture is "fork-ready, not support-dependent": register it in the dependency inventory, assign a named internal owner, and pre-agree that a Nova-upgrade break triggers a fork-and-patch rather than a vendor escalation. Budget roughly a day of engineering per Nova major upgrade for regression testing and potential patching.

Support. The weakest dimension. Three stars and zero dependents means there is no issue-trail ecosystem to lean on — every problem is either self-solved or forked. No SLA, no security advisory channel, no guaranteed response. For an admin-panel-only, non-customer-facing field inside an already-licensed commercial product, that is tolerable; for anything on a revenue path it would not be. The compensating control is that the code is small enough to fully review in under an hour — do that review as a gate, and re-review on each version bump.

Scaling. Negligible. Rendering a tooltip is a client-side concern with no query cost, no N+1 exposure, no cache or queue involvement, and no effect on API response sizes. The only scale-adjacent concern is front-end asset weight — a duplicate bundled Vue component adds kilobytes, not a scaling problem. Ten tooltips on an index or one makes no measurable difference to page performance.

Failure modes. Ranked by likelihood and impact:

• Nova upgrade breaks the internal component contract. Most likely over a 12–24 month horizon. Symptom: tooltip fails to render, or a JS error degrades the surrounding form. Detection is manual unless we have a smoke test that loads an index/detail page in CI. Mitigation: pin Nova, add a rendering smoke test, keep the fork path warm.
• Stale or unmaintained upstream. Package falls behind Nova, install still "succeeds" but behavior drifts. Mitigation: annual dependency review; fork on first miss.
• Build/asset mismatch. Published assets built against a different Nova version, or nova:assets overwrites them on deploy. Mitigation: verify asset behavior in the sandbox proof and after a full deploy rehearsal.
• Unescaped tooltip content (XSS). Only if the field renders raw HTML from model or user data. Admin-surface-only reduces severity; it does not eliminate it. Mitigation: code review gate; prefer plain-text tooltip content by policy.
• Misuse as a data field. A developer attaches it expecting a stored value on a form. Mitigation: short internal usage note; it is a presentational field.

Ramp-up. Minimal — under an hour for a Nova-fluent developer, mostly reading the field class. Two things need to be documented internally because they are non-obvious: (1) the field is display-only and must not be treated as a form input, and (2) it tracks Nova’s internal component API, so Nova upgrades require a render check. Overall operational profile: low ongoing cost, low-to-moderate tail risk concentrated almost entirely in Nova upgrade events, and a cheap, well-understood exit (fork or remove) that keeps the downside bounded.