Cloner Laravel Package

Product Decisions This Supports

• Feature scoping for “Duplicate” / “Save as template” UX. If your roadmap includes admin-side record duplication (copy a CMS page, a product, a campaign, a tenant config), this package answers the build-vs-buy question directly: the “hard part” isn’t inserting a row, it’s walking the relation graph and re-copying files. Cloner does both from a single duplicate() call.
• Tenant and environment onboarding. Cloning a model graph into another database connection (duplicateTo('production')) reframes a typically bespoke ETL/promotion project as a configuration decision: define the connection, call the method. That supports decisions like “should staging→production content promotion be a product feature or an ops script?”
• Template/seeding strategy. Deciding whether demo sandboxes, QA fixtures, or per-market catalog rollouts (localization) are generated by cloning canonical records versus hand-built seeders. Cloning inherits real relational and file structure; seeders don’t.
• Build-vs-buy for a narrow, well-bounded capability. The alternative is 100–300 lines of in-house cloning logic plus permanent ownership of edge cases (polymorphic relations, pivot tables, file disk handling, transaction boundaries). This is a classic “buy the small thing” call.
• Roadmap sequencing. Because integration cost is measured in hours (trait + optional provider registration), it can slot into a sprint as an enabler rather than a standalone initiative — useful when prioritizing a duplicate feature against other backlog work.
• Architecture decision on cross-database flows. Whether your product supports “promote content from staging/authoring to live” as a first-class workflow, and whether that runs synchronously in the app or as a queued job (Cloner is synchronous — this informs the job design, not the other way around).

When to Consider This Package

Adopt when most of these hold:

• The domain is Eloquent-native and the records you need to copy are reachable through declared relations (hasMany, belongsToMany, nested children, media/file relations).
• Files must be copied, not just database rows — this is the differentiator and the main reason to not hand-roll.
• You need cross-connection cloning (staging→prod, tenant→tenant) as a supported path rather than an exception.
• Volumes are per-record and interactive (a user clicks “Duplicate”) or modest and batch-tolerant. Not bulk migration scale.
• You can accept a small, single-maintainer dependency and are prepared to pin the version, vendor it, or fork it.

Look elsewhere when:

• You need versioning, audit trails, or content branching with history and rollback — that’s a versioning package, not a cloner. Cloner produces a new independent record with new IDs; it is not a snapshot/diff system.
• You need merge/conflict semantics on cross-database promotion. duplicateTo inserts; it doesn’t reconcile against existing rows.
• Your relation graph includes exotic or custom relation types, or cloning must be queued, chunked, and idempotent across hundreds of thousands of rows.
• Supply-chain continuity is a hard requirement (regulated environments, long-lived platforms) and a 0-dependent, agency-maintained package can’t clear procurement without a fork-and-own commitment.
• You’re not on a Laravel version the package supports, or your files live on disks whose semantics the package doesn’t handle without custom configuration.

Two adoption notes for the decision record: the “0 dependents” signal is a maintenance/provenance risk, not a functional one — treat it as a reason to add your own integration tests around your specific relation graph, not as a disqualifier. And the README’s Travis/Coveralls badges are legacy signals; verify current test coverage in the repo rather than trusting the badges.

How to Pitch It (Stakeholders)

To executives: We can ship “duplicate record,” “save as template,” and “promote content from staging to production” as product features in days instead of weeks. This is a small MIT-licensed library that already solves the expensive part — copying a record and everything attached to it, including files — including into a second database. It removes a recurring category of custom code we would otherwise build, maintain, and debug ourselves.

To engineering: One trait on the model (use \Bkwld\Cloner\Cloneable;), one call (->duplicate(), or ->duplicateTo('connection')), auto-discovered on modern Laravel. No services, no schema changes, no runtime dependencies. MIT license, so forking is always available. The trade-offs are explicit: it’s synchronous and per-record, cloning is insert-with-new-IDs (no merge or conflict resolution), and it’s maintained by a single agency with no downstream dependents in the index.

Recommended ask: approve a short spike — one model graph, one file-bearing relation, one cross-connection case — covered by integration tests we own. If the spike is clean, adopt with a pinned version and a named internal owner; if it isn’t, we’ve spent a day to learn that and we build the narrow version ourselves.