Nova Text Copy Field Laravel Package

Product Decisions This Supports

• Build vs. buy for a recurring admin-panel micro-interaction. Any operator-facing Nova resource that shows a read-only value worth reusing — API keys, tokens, invite codes, account IDs, tracking numbers, generated URLs — has the same usability gap: the value is visible but not one-click retrievable. This package closes that gap with a single Nova field (TextCopy) that inherits the native Text surface. The PM decision is whether to standardize on a tiny third-party field versus spending sprint capacity re-implementing a copy affordance per resource. For something this small, "buy" is usually the lower total-cost answer — provided it first passes the native-alternative check below.
• Roadmap gating for the Nova 4 → Nova 5 upgrade. v3.0.0 is explicitly a compatibility cut, not a feature release: "Laravel Nova 5 Support" plus a refactor to the Nova 5 field API. It is a direct input to the roadmap question "can we move the admin panel to Nova 5 this quarter?" Any migration plan that lists this field as a dependency is unblocked here — but only in lockstep with the Nova upgrade, never ahead of it. Treating v3.0.0 as a standalone upgrade is a mis-scoped ticket.
• Native-alternative evaluation window. Nova 5 forces every field definition to be touched anyway, making it the natural moment to ask whether Nova 5's own copyable-text capability already covers the need. If it does, the correct decision is remove, not adopt — retiring a dependency that duplicates a platform primitive is a genuine product win (one fewer maintenance surface, one fewer vendor to track).
• Error reduction as a measurable outcome. Every value an operator copies by hand is a transcription-error surface ("I mistyped the account ID") that converts into support tickets and re-issued credentials. Standardizing on one-click copy is a cheap, attributable reduction in a recurring operational-friction class — defensible in an admin-UX epic even at low per-instance impact.
• Feature-scoping discipline. Text-copy is a field-level interaction, not a justification for a custom page, a bespoke component library, or a new admin screen. It keeps an operator convenience from being over-scoped into a feature.
• Dependency-risk triage. 1 star, 0 dependents, two contributors, single-institution ownership, and a cadence that tracks Nova majors rather than shipping independently. That profile decides whether the field belongs on a critical path (it does not) or should be classified as a nice-to-have with a documented, low-cost replacement held in reserve.

When to Consider This Package

Adopt when:

• You are running Laravel Nova 5. v3.0.0 targets Nova 5 only; it is not intended for Nova 4 and must never be bumped opportunistically on a Nova 4 install.
• The need is small and bounded: display a value on a Nova detail or index view with a one-click copy control.
• Your team already standardizes on community Nova fields rather than hand-rolled field packages, so this is consistent with existing policy.
• You want consistent operator behavior across resources — one implementation of the copy interaction instead of per-model reinventions.
• You are mid-Nova-migration and can fold this bump into the same change window rather than create a separate deploy.
• A native Nova 5 copyable-text capability does not already satisfy the requirement — check this first; if it passes, adopt.

Look elsewhere / avoid when:

• You are on Nova 4 or earlier — pin ^2.0, treat v3.0.0 as blocked on the framework upgrade, and do not float the constraint.
• Nova 5's native copyable text already covers the use case — then the dependency is redundant and the correct action is to retire the field definition in favor of the platform primitive.
• You need copy behavior outside Nova (public app, Filament, Livewire admin, Inertia SPA). This is Nova-specific and will not transfer.
• You need richer clipboard semantics — copy-with-formatting, multi-field or bulk copy, copy audit logging, permission-gated visibility of secrets, or toast/telemetry. Those are product requirements requiring custom work, not configuration of this field.
• Governance or vendor-risk policy applies: single institution, low contributor count, sparse changelog, no security SLA, and no published compatibility matrix (PHP / Laravel / Nova / Vue). If policy requires multi-maintainer support, fork into an internal namespace or replace with a small in-house field.
• A native Nova Text field plus a tiny inline copy component is acceptable to your team — then the dependency buys very little, and the cheapest moment to drop it is during the Nova 5 upgrade when field definitions are already being touched.

How to Pitch It (Stakeholders)

For executives (one paragraph): We're evaluating a small, free, open-source add-on for our admin panel. It puts a "click to copy" button next to values like account IDs, access codes, and API tokens, which removes a routine source of operator error and the support tickets that follow ("I mistyped the ID"). The v3.0.0 release adds no product capability — it does one thing: makes the add-on work with the newest version of our admin framework, Nova 5. It is a breaking release and will not work on our current Nova 4 setup. Our recommendation is to carry it forward only as part of the Nova 5 migration, not as a standalone upgrade, and to use that migration as the moment to check whether Nova 5 already gives us this capability natively — if it does, we drop the dependency instead of upgrading it.

For engineering (summary): Treat v3.0.0 as a compatibility cut, not a feature release — Nova 5 support plus a refactor to the Nova 5 field API. It must ship in lockstep with the Nova upgrade, on a branch, with staging validation of every resource that uses the field; do not bump it opportunistically on Nova 4. Integration effort is trivial (composer require, swap Text::make(...) for TextCopy::make(...); no migrations, queues, or config), and because the field extends Nova's native Text, the usual chainables — resolveUsing, displayUsing, canSee, onlyOnDetail/onlyOnIndex, sortable, textAlign — continue to work, so authorization and computed values behave as expected. Risk profile is external and unchanged: a two-contributor, single-institution package with an undocumented breaking change to the field API, unclear CI coverage, and no published PHP/Laravel/Nova/Vue compatibility matrix. Mitigations are cheap and should be planned now: pin exact versions on both Nova and this field, inventory usage sites in app/Nova to decide "upgrade" versus "delete," add a smoke test that loads a resource using the field (failures are silent and client-side — a Vue mount failure renders blank with no server-side signal), name a platform/admin-tooling owner, and keep a live fallback — either a vendored fork or a ~30–100 line in-house field. Replacement cost is low; do not let this become a ceiling on future Nova upgrades.