Deeply Laravel Package

Technical Evaluation

Architecture fit. Deeply is a single-purpose, framework-agnostic utility rather than a Laravel-integrated package. That is actually a favorable architectural posture for a TPM scoping it: it has no service provider, no config surface, no middleware, and no opinion about the application layer. It fits cleanly as a leaf dependency inside domain services, action classes, or value-object factories. The relevant architectural question is not "does it fit Laravel" but "which object graphs in our codebase are safe to deep-copy." It is a good fit for DTOs, plain value objects, template/instance clone flows (e.g., cloning a project template into a new project), audit-diff snapshotting, and test fixtures. It is a poor fit for Eloquent model graphs with loaded relations, because a model's loaded relations carry query builders, connection objects, and event-related state that a naive deep clone can corrupt or fail on.

Integration feasibility. High. Composer install, a small public API for copying arbitrary PHP values, MIT license, no infrastructure. Nothing needs to be registered in the container and nothing needs to be bootstrapped. The realistic effort is not the install but the guardrails: defining which classes are copy-safe, wrapping the library behind a domain interface, and writing contract tests. A TPM should budget for the wrapper and tests, not the dependency.

Technical risk. Moderate but contained.

• Staleness / bus factor: single-maintainer package, last release July 2023, 229 stars. Low activity is the primary risk, but the MIT license and ~small code surface make fork-and-vendor a viable mitigation.
• Uncloneable objects: PHP has objects that cannot be cloned (e.g., Closure, PDO/resource-backed handles). A recursive cloner must either skip them or it will throw. This is the highest-severity unknown and needs a spike before adoption in any graph containing Laravel services, collections with callbacks, or event dispatchers.
• Eloquent leakage: deep-copying models risks duplicating connection/query-builder state and producing objects that look like models but behave incorrectly. Eloquent already has replicate() for row duplication; Deeply should not be positioned as a replacement.
• Graph size: cloning is O(n) over the full object graph with reflection; large relation graphs can cause memory spikes.
• Maturity signals: the composite score (~3.3) and low opportunity score (~0.38) suggest a utility that is useful but not strategically differentiating — treat it as plumbing, not a platform bet.

Key questions.

1. Does it handle uncloneable objects (Closure, PDO, resources) by skipping, throwing, or failing silently?
2. Does it clone private/protected properties via reflection, and does it reset object identity (e.g., SplObjectStorage keyed by original)?
3. What PHP versions are declared, and is there a CI matrix? Will it survive PHP 8.4/8.5?
4. How does it treat already-immutable objects (DateTimeImmutable, enums, readonly properties)?
5. What is the measured memory/time cost on our largest realistic graph?
6. Is there a maintained fork or is vendoring expected?

Integration Approach

Stack fit. Compatible with a standard Laravel stack (PHP 8.1+, Composer 2). It lives in the domain/service layer, not the framework layer, so it does not constrain the Laravel version. The only coupling is PHP language semantics, which is the most stable surface available.

Migration path. There is nothing to migrate from if we use it for a new capability. If replacing ad-hoc approaches (manual clone, serialization round-trips via serialize/unserialize, or json_decode(json_encode())), the path is: introduce Deeply behind an ObjectCopier interface, port one call site, and run both implementations against a fixture suite before deleting the old path. A serialization round-trip is the closest existing behavior and the easiest benchmark for equivalence — with the caveat that serialization loses type fidelity and cannot handle closures at all, so Deeply should compare favorably.

Compatibility. Two axes to verify in a spike, not in production:

• Language: declared PHP constraint vs. our runtime; reflection behavior across 8.x minors.
• Tooling: reflection-heavy libraries often produce PHPStan/Larastan noise. Budget for a baseline or ignore rule rather than discovering it in CI.
• Domain: catalog which classes are copy-safe. Anything holding a service, connection, closure, or singleton should be explicitly excluded.

Sequencing.

1. Spike (days, not weeks): clone a representative DTO, a value object with nested arrays, a circular structure, and a deliberately uncloneable object. Record pass/fail behavior.
2. Wrapper + contract tests: define the interface, implement with Deeply, write fixtures covering circular refs, visibility, and uncloneable members.
3. Pilot one bounded use case — ideally template-to-instance cloning of DTOs or audit snapshotting — behind a feature flag.
4. Measure memory and latency on the largest realistic graph; establish a size ceiling and refuse copies above it.
5. Expand to additional call sites only after the pilot's guardrails are proven.
6. Exit strategy: vendor the source (MIT permits it) if upstream goes dormant; the wrapper makes this a one-file swap.

Operational Impact

Maintenance. Low ongoing effort for the dependency — there is nothing to configure. The real maintenance is ownership of the copy-safety contract: as new classes are added to the domain, someone must know whether they are safe to deep-copy. Assign that to the owning team and encode it as a marker interface or test, otherwise correctness erodes silently over months.

Support. Community-only, no SLA, no vendor. Given the single-maintainer profile and the 2023 last release, plan for the possibility of no upstream fixes. Mitigate by vendoring or maintaining a thin internal fork; the code surface is small enough that this is realistic for one engineer.

Scaling. Scaling is the sharpest operational concern. Deep copy is a full traversal with reflection: cost scales linearly with graph size but with a large constant, and memory roughly doubles at the moment of copy. It is appropriate for per-request, per-entity operations and inappropriate for bulk jobs over thousands of models, hot loops, or queue workers processing large batches. Set explicit guidance: copy DTOs and value objects, not hydrated model graphs; cap graph depth/size; prefer replicate() for Eloquent rows and plain clone for flat objects.

Failure modes. Ranked by expected impact:

• Uncloneable member encountered mid-graph — exception or partial copy depending on implementation; highest likelihood.
• Eloquent/service object leakage — a copied object retains connection or service references and "works" in tests but behaves incorrectly in production.
• Memory exhaustion on large or accidentally cyclic-but-huge graphs (cycles are reported handled; breadth is not).
• Silent stale state — the copy snapshots transient properties (caches, loaded flags) that the original would have recomputed, producing inconsistent behavior downstream.
• Dormant upstream — no fix for a future PHP incompatibility; discovered at upgrade time.
• Reflection restrictions — internal or readonly-heavy classes behave differently than expected.

Ramp-up. Very low for developers (the API is a single call), which is itself a risk: the low barrier invites misuse on graphs that are not copy-safe. Ramp-up effort should be spent on education, not API training — a short internal note on "what we deep-copy and what we never deep-copy," plus the wrapper, is sufficient. Expect roughly a half-day per engineer to become productive and a single owner-day to establish the safety contract.