Product Decisions This Supports
- Build-vs-buy for an admin "Duplicate" action. The only durable product value here is the UX pattern: a Nova action that clones a record (and optionally its relations) so ops/content teams can spawn variants without re-keying data. That's a real, recurring request in CMS, catalog, and template-driven products — but it is also a 1–2 day engineering task, not a dependency worth owning.
- Roadmap input for internal admin tooling. Use it as a reference implementation when scoping an "internal tooling" epic: duplicate record, duplicate-with-relations, clone-as-draft, and bulk-clone. The existence of a package at this scope is evidence the need is common; the package's state is evidence it isn't a market anyone maintains.
- Staging/test data strategy. If the intent is cloning database data across environments (prod → staging), that is a data-governance and security decision, not a Composer dependency. Decide this explicitly: seeded fixtures and anonymized dumps are the defensible path; ad-hoc clone tooling in an admin panel is not.
- Multi-tenant / template record features. If "clone from template" is a customer-facing feature (tenant onboarding, campaign duplication, listing relisting), the product decision is about which fields and relations carry over, permissions, and auditability — none of which this package can inform. It only covers the internal-admin slice.
- Not a decision it supports: pricing, packaging, or customer-facing differentiation. There is no ecosystem signal here — 7 stars and 0 dependents means no adoption evidence either way.
When to Consider This Package
Consider it only under a narrow set of conditions:
- You are on Laravel Nova 3 (or can verify compatibility against your Nova major — Nova 4 shipped in 2022 and Nova 5 in 2024, and this package's last release was October 2021, so assume breakage until proven otherwise).
- The need is internal-only, low-stakes admin convenience, with no audit, permission, or data-residency requirements attached.
- You are willing to vendor/fork it into your codebase rather than depend on it — treat it as sample code, not as a maintained library.
- Someone has actually read the source and confirmed what "copy clone database data" means. The description is ambiguous between clone a record in the Nova UI and replicate database contents between connections. Those are wildly different risk profiles, and the ambiguity itself is a red flag.
Look elsewhere (or build in-house) when:
- You are on Nova 4/5, or plan to upgrade. A single-maintainer package with no releases since 2021 and zero dependents will not track Nova's breaking changes.
- You need deep relational cloning (polymorphic relations, media/file duplication, nested children, unique-constraint handling). Naive clone logic silently corrupts slugs, SKUs, and foreign keys.
- Cloning touches customer-facing data, PII, or production. An unvetted package is not an acceptable control point for that.
- You need RBAC, audit logging, or approval flow around duplication — Nova actions compose well with your own authorization; a package that owns the action makes that harder, not easier.
- You want a supported dependency. Zero dependents and a stale release mean you are the only QA. Prefer a maintained alternative in the Nova action ecosystem or ~150 lines of your own code you can test.
How to Pitch It (Stakeholders)
To executives: There is a small, free (MIT) add-on that adds a "duplicate this record" button to our admin panel. The capability is worth having — it saves ops and content teams real time on repetitive data entry. This specific package is not: it was last updated in 2021, has essentially no users, and was built for an older version of the admin framework we'd need to run it on. Recommendation: treat it as a design reference, not a dependency. Budget a small in-house build (1–2 days) if the capability makes the roadmap.
To engineering: Do not composer require this. Last release Oct 2021 predates Nova 4; 7 stars and 0 dependents means no downstream bug discovery. If we want the pattern, read the source, then implement a Nova Action ourselves — it's a handle() method that replicates the model, nulls/regenerates unique fields, and optionally walks declared relations. That gives us test coverage, upgrade safety, and control over the parts that actually bite: unique constraints, file/media duplication, and authorization. If we must use third-party code here, fork it with a pinned commit and own the maintenance.
Risk statement to attach to any decision record: single maintainer, stale by 3+ years, no adoption signal, ambiguous scope, and it operates inside a commercial closed-source admin panel with its own upgrade cadence. Low blast radius if internal-only; unacceptable if it ever touches production or customer data.