Cloner Laravel Package

Technical Evaluation

Architecture fit

• Trait-based extension of Eloquent (use \Bkwld\Cloner\Cloneable) that layers on top of Model::replicate(), so it inherits the framework's own attribute-copying semantics rather than introducing a parallel persistence layer. Low architectural intrusion: no base model to inherit, no new query builder, no schema changes.
• Opt-in per model is the right granularity for a TPM: blast radius is bounded to models that explicitly declare the trait and their $cloneable_relations / $cloneable_files configuration.
• Auto-discovered service provider on Laravel 5.5+, so there is no bootstrap wiring to maintain.
• The cross-database capability (duplicateTo('connection')) is the architecturally interesting piece — it turns the package from a convenience into a data-seeding/tenant-provisioning primitive, but it implicitly assumes schema parity between connections.

Integration feasibility

• composer require bkwld/cloner is the entire install. Realistic effort for a first working clone: under a day for one model.
• Feasibility is gated almost entirely by one unknown: the supported Laravel/PHP matrix. The package predates Laravel 10/11/12, and a trait that overrides replicate() behaviour is sensitive to framework internals. Verify composer.json constraints against the target app version before committing.
• Files support means the package touches the filesystem abstraction; confirm whether it uses the Storage facade and disks (S3/Spaces compatible) or raw local paths, since that determines whether cloud storage and CDN-backed assets are safe to clone.

Technical risk

• Graph correctness is the primary risk: cyclic/self-referencing relations, polymorphic (morphMany/morphTo) relations, belongsToMany pivot data, and deep nested graphs. Any gap here produces silently incomplete clones — the worst failure class, because it looks like success.
• Atomicity: file duplication happens outside the DB transaction. A failure mid-clone can leave copied objects in storage with no owning row, or a partially populated relation graph.
• Observer side effects: cloned models fire normal Eloquent events, so anything listening (audit logs, search indexing, mailers, webhooks) will trigger as if a user created the record. This is frequently the source of post-rollout incidents.
• Column collisions: naive attribute copying carries over unique-constrained values (slugs, emails, external IDs, UUIDs) and will throw on save.
• Low ecosystem footprint (0 dependents, ~488 stars) means fewer battle-tested edge cases than a mainstream package — you are closer to the frontier.

Key questions

1. Which Laravel and PHP versions are actually supported, and is the support declarative (CI matrix) or aspirational?
2. Is the clone wrapped in a DB transaction, and can file copying be deferred to a queued job?
3. Does it handle morphMany, belongsToMany with pivot attributes, and self-referencing/cyclic relations — and does it guard against infinite recursion?
4. Are model events intentionally fired on clones, and is there a hook to suppress them?
5. For duplicateTo, is schema parity validated, or does it fail opaquely at insert time?
6. Who maintains it — an agency's internal OSS with a release cadence, or a single occasional contributor?

Integration Approach

Stack fit

• Any Laravel application already on Eloquent. No opinion on database engine, queue driver, or frontend. Compatible in principle with multi-tenant and multi-connection setups.
• Fits cleanly alongside standard packages (Nova, Spatie Permission) for attribute-based data, but not for packages that store relations in their own tables (e.g., Spatie Media Library, translatable packages) — those need custom clone handling via model hooks.

Migration path

• Purely additive: no schema migration, no data backfill, no backfill risk. Rollback is removing the trait from a model.
• Adopt per model, starting with the lowest-risk candidate (simple hasMany, no unique constraints on copied columns).

Compatibility

• Two checks gate the go/no-go: (a) composer.json framework constraints vs. the app's Laravel version; (b) trait/method collisions with existing traits or overrides on replicate(), save(), and model events.
• Confirm behaviour for UUID/ULID primary keys, SoftDeletes, and global scopes — global scopes in particular can silently truncate a relation graph during cloning.

Sequencing

1. Spike branch: install, apply trait to one model, clone in a local/staging DB, inspect the resulting graph row-by-row (not just "no exception thrown").
2. Write a regression test asserting child counts, pivot rows, file existence, and uniqueness handling for that model.
3. Wrap the package behind an internal CloneService so application code never calls duplicate() directly — this is the single highest-leverage decision, as it lets you fork, queue, or replace the package later without touching call sites.
4. Expand model-by-model, adding a checkbox to the model review checklist ("does this model need clone config?").
5. Only then expose cross-database cloning, and only with connection names resolved from config rather than hardcoded.

Operational Impact

Maintenance

• Small code surface (a trait plus a service provider), MIT licensed — which makes the standard abandonment mitigation genuinely viable: if upstream stalls, vendoring or forking is a days-not-months exercise.
• Pin to an exact version in composer.lock; treat upgrades as requiring a test run, since the package overrides framework behaviour.

Support

• No SLA, agency-backed community OSS. Internal ownership must be assigned explicitly — one engineer accountable for version bumps and issue triage. Without that, this becomes a silent liability discovered during a framework upgrade.

Scaling

• Cloning is synchronous and in-request. Deep relation graphs become N+1 inserts, and file duplication is I/O-bound — large clones will hit request timeouts and PHP memory limits before they hit database limits.
• For anything beyond modest graphs, force cloning into a queued job with an explicit size cap and progress reporting. Cross-database cloning doubles connection pressure and must not run against production without a guardrail.

Failure modes to instrument

• Partial clone (DB rollback but files persisted, or vice versa) — needs a reconciliation/cleanup job.
• Retry duplication creating orphaned storage objects — cloning is not idempotent by default; add a request/correlation ID and dedupe.
• Foreign-key violations when cloning across connections where referenced parents are absent.
• Unique constraint collisions on copied columns — require an explicit transform hook per model.
• Unintended observer fan-out (emails, webhooks, index writes) at clone time.
• Infinite recursion on cyclic relations — hard timeout, not a graceful error.
• Storage cost creep from unbounded file duplication; add a metric.
• Cross-connection misconfiguration writing a clone into production — enforce allow-lists in config.

Ramp-up

• Individual: ~1 hour to first successful clone; ~1 sprint to understand relation-graph configuration well enough to trust it.
• Team: the durable cost is conventions, not learning — document $cloneable_relations/$cloneable_files expectations, the CloneService wrapper, queue requirements, and the model checklist. Without that documentation, new models will be added inconsistently and produce silently incomplete clones.