Laravel Computed Properties Laravel Package

Technical Evaluation

Architecture fit

• The package is a thin trait layered onto Eloquent models that memoizes derived attributes and resolves inter-property dependencies. Conceptually it fits any Laravel codebase already using accessors and $appends, and it introduces no new infrastructure, service provider surface, or storage.
• Fit is best where models carry several chained derivations (e.g., full_name → display_name → sort_key) that currently recompute repeatedly during serialization, exports, or search indexing.
• Fit is poor for teams already on Laravel 9+ that use native Attribute objects with shouldCache(), or that treat models as thin persistence objects. The package's differentiator is dependency ordering, not caching alone, so the value proposition must be proven against a concrete model.

Integration feasibility

• Low code volume and a single trait make a proof of concept cheap: one model, two or three chained properties, exercised through toArray(), API Resources, and a queued export.
• The real work is not installation but verifying behavioral edges: fill/setAttribute invalidation, refresh(), replicate(), dirty tracking, $hidden/$appends interaction, and whether computed values participate in toJson consistently across resources.
• Composer constraints are the gating factor. A 2018 release almost certainly pins Laravel 5.5–5.7 and PHP 7.x, so feasibility on a modern stack collapses to "fork or replace," not "install."

Technical risk

• Abandonment (high): last release October 2018, no upstream security or compatibility patching. Any adoption is a permanent internal ownership commitment.
• Framework coupling (high): the trait necessarily hooks Eloquent internals (getAttribute, mutators, serialization). These are the parts of Eloquent that shift most between major versions.
• Correctness risk (medium): per-instance memoization can serve stale values after attribute mutation or relationship changes unless invalidation is verified precisely. Silent wrong values in derived fields are worse than slow ones.
• Dependency graph risk (medium): cycles or accidental self-reference can produce recursion rather than a clear error. Needs guardrails and tests.
• Latent N+1 (medium): computed properties that touch relations will lazy-load during serialization, turning a cheap toArray() into a query storm.
• Low security surface: no network, auth, or storage — the risk is reliability and maintenance, not exploitability.

Key questions

1. Which concrete accessors are we replacing, and does native shouldCache() plus explicit invalidation already solve 80% of it?
2. Do we actually need dependency-graph resolution, or just caching?
3. What is the target Laravel/PHP matrix, and is a maintained fork acceptable?
4. Who owns the fork — team, platform group, or nobody?
5. How many models and computed properties are in scope, and what's the serialization hot path?
6. Are computed properties allowed to touch relations, or is that explicitly forbidden?
7. What is the exit cost if we remove it in 12 months?

Integration Approach

Stack fit

• Suitable only for an Eloquent-centric Laravel app with an existing accessor convention and a clear serialization boundary (API Resources or DTOs). It fits badly alongside CQRS/read-model patterns where derived fields belong in query objects or projections.
• Prerequisite: PHP/Laravel versions the package supports, or an approved fork. No fit on Laravel 10/11 without code changes.

Migration path

• Phase 0 — spike: fork the repo, bump constraints, run the existing test suite, add tests for invalidation, cycles, refresh, replicate, and JSON output.
• Phase 1 — contain: introduce an internal HasComputedProperties abstraction (our own trait/interface) that the fork satisfies. Application models depend on our contract, not the vendor namespace, so replacement is a one-file change.
• Phase 2 — pilot: one non-critical model with chained properties, measured before/after on query count and serialization time.
• Phase 3 — expand or exit: roll out to models with demonstrated repetition; otherwise delete the dependency and use native cached accessors.

Compatibility

• Verify against the exact Laravel minor in production, not just the major. Check composer why-not for conflicts with API Resources, IDE helper, and any package that overrides getAttribute or serialization.
• Confirm behavior under withoutAppends, makeHidden, only, and resource whenLoaded — these are where computed properties most often leak.

Sequencing

1. Fork and license/vendor review.
2. Contract + fork + test harness.
3. Pilot model and benchmark.
4. Serialization audit across API surfaces.
5. Rollout decision gate with explicit exit criteria.
6. Documentation and ownership handoff before any second model adopts it.

Operational Impact

Maintenance

• Effectively a permanent internal fork. Budget a small but non-zero annual cost: dependency bumps, Eloquent compatibility fixes, and test maintenance. The code is small, which caps the effort, but it never reaches zero.
• Add it to the dependency inventory with an owner, a review date, and a "replace with native" trigger tied to Laravel upgrades.

Support

• No upstream support, no CVE feed, no issue triage. Internal engineers become the sole escalation path. Any incident involving wrong derived values will be debugged without vendor help.
• Mitigate with a documented semantics page: when caches invalidate, what is forbidden inside a computed property, and how to debug a stale value.

Scaling

• Runtime cost is per-instance memoization: memory grows with model count in a collection, which matters for large exports and chunked jobs. Measure memory on a 10k-row export before committing.
• No horizontal scaling concerns — no shared cache, no external service. The scaling risk is query amplification from relation-touching properties, best controlled by policy and static analysis rather than code.

Failure modes

• Stale derived values after mutation or refresh() — silent, hardest to detect.
• Infinite recursion from cyclic dependencies — loud but potentially during request serialization.
• N+1 explosions when computed properties touch relations inside toArray().
• Serialization shape drift when Laravel changes append/hidden behavior.
• Hard upgrade blockers when the framework moves and the fork lags — this is the most likely real-world failure.

Ramp-up

• Low for anyone who knows Eloquent accessors; the mental model is "accessor with a cache and an ordering rule." Roughly half a day for a mid-level engineer plus the semantics doc.
• The hidden ramp-up cost is organizational: reviewers must learn when not to use it, or it becomes a dumping ground for business logic in models. Pair adoption with a written rule that computed properties are pure, side-effect-free, and relation-free.
• Given the 2018 last release and a low composite score, the default recommendation is to treat this as a design reference for an internal ~100-line implementation rather than a dependency to adopt.