Laravel Two Way Attribute Casting Laravel Package

Technical Evaluation

Architecture fit. The package is a single-purpose extension to Eloquent's $casts mechanism, adding symmetric read/write transformation for a given attribute. Architecturally it is a thin, low-coupling layer that touches only model hydration and persistence — no schema changes, no service provider surface worth adopting, no runtime interception. That is a genuinely good fit for a Laravel-native codebase in the abstract.

The decisive problem is that the abstract no longer applies. The package is archived, has 1 star, 0 dependents, and its last release was 2018-05-29. Laravel 7 (March 2020) shipped the CastsAttributes interface, which already provides a single class implementing both get() and set() — exactly the "bidirectional, symmetric cast" that is this package's entire value proposition. The package predates that capability and is therefore largely functionally superseded by the framework. We would be adopting an abandoned dependency to obtain a behavior the platform now gives us for free.

Integration feasibility. Low effort to write, high effort to own. The public surface is a cast class per attribute; integration is one $casts entry. However, a 2018-era package will carry Composer constraints (php, illuminate/*) that almost certainly conflict with a modern runtime (PHP 8.2+, Laravel 10/11/12). Resolving that means --ignore-platform-reqs or a fork — neither is a production strategy.

Technical risk: high. Archived status means no compatibility fixes, no bug triage, no security response, and no path for the next Laravel major. The supplied documentation itself concedes 0.1.x semantics can change in a patch, that decimal hydration behavior is driver-dependent (SQLite vs MySQL), and that aggregates bypass casts entirely. Those are precisely the edge cases a financial-adjacent cast must get right, and there is no upstream to fix them.

Key questions to resolve before any decision:

1. Which Laravel and PHP versions are in scope, and does native CastsAttributes already satisfy the requirement? (Expected answer: yes.)
2. What specific defect is being solved — float drift on decimal columns, or duplication between accessor and mutator?
3. If the answer is float drift, does the team actually need a cast, or a money value object (moneyphp/money + brick/math) with the cast as a thin transport?
4. Who owns the fork, and is that person funded for every future framework upgrade?
5. Has license and provenance been reviewed for vendoring?

Integration Approach

Stack fit. Laravel + Composer, one cast per precision-sensitive attribute. The intended deployment pattern (per the docs) is: migration stays decimal(10,2), cast parameter :2, validation rule decimal:0,2, arithmetic performed outside the model via bcmath, and API resources emitting strings. Note that none of that discipline comes from the package — it is process and convention we would have to enforce regardless of which library we choose.

Recommended migration path: do not install the dependency. Reimplement. Laravel's native CastsAttributes reproduces this package's behavior in roughly 30–60 lines: a get() that normalizes the driver's returned value to a canonical string at fixed scale, and a set() that normalizes assignment input the same way. That gives us the symmetric contract, modern framework compatibility, a first-party support surface, and zero abandonment risk. It also preserves the exit path — a custom cast behind a consistent attribute contract is replaceable in an afternoon.

If adoption is mandated, the only defensible form is vendor-and-fork: copy the source into the application (or an internal package), pin it explicitly, verify the license, rewrite the Composer constraints for the current framework, and treat the upstream repo as read-only reference. Do not reference it as a live VCS or Packagist dependency in a production composer.json. Never float the constraint across 0.1.x.

Compatibility checks for either route. Confirm cast class signatures match CastsAttributes::get()/set(); confirm Laravel 11's casts() method form vs the legacy $casts property; confirm behavior against both the CI driver and the production driver, since decimal typing differs between SQLite and MySQL; and confirm no legacy accessor or Attribute mutator exists on the same attribute, because the accessor wins and will silently mask the cast.

Sequencing.

1. Spike (1–2 days): implement the native CastsAttributes version against one model attribute in a non-critical domain (order line items or an internal reporting field).
2. Characterization tests: round-trip assertions on create, update, fill, refresh, and first() for representative values — negatives, zero, null, and high-scale — using assertSame on normalized strings rather than assertEquals on floats.
3. Measure: defect rate on the target monetary fields before and after.
4. Decide: promote to other attributes only if the defect signal improves; revisit at the point currency conversion or locale formatting enters scope, which is a value-object problem, not a cast problem.

Operational Impact

Maintenance. This is the dominant cost and it is infinite tail, zero upstream. Archived means every future Laravel or PHP upgrade is an internal ticket. The package does not save us maintenance — it converts a one-time 30-line implementation into a permanent upgrade obligation.

Support. No issue triage, no CVE response, no maintainer to ask. With 1 star and 0 dependents there is no community to fall back on and no signal that anyone else has run this in production. Any defect we hit, we own entirely, including in the cast path the 0.1.2 release was still actively fixing.

Scaling. Runtime cost is negligible — casts are per-attribute and evaluated at hydration and persistence. The scaling risk is analytical, not computational: aggregate queries bypass casts, so ->sum('unit_price') returns whatever the driver hands back, and reporting built on raw aggregates can disagree with model-level values. That is a data-correctness scaling problem that grows with the number of reports and dashboards touching the field.

Failure modes to instrument for:

• Silent scale truncation vs rounding (19.999 → 19.99 or 20.00) — must match invoicing expectations.
• Float leakage on assignment, which is lossy before the cast sees the value; treat float input as a caller bug.
• Null coerced to 0.00 (or vice versa), breaking whereNull filters and form prefill.
• Driver divergence between CI and production for decimal typing.
• Accessor/mutator silently overriding the cast.
• Composer resolution failure at the next framework upgrade — the most likely first symptom of abandonment.
• Canonical-scale string inequality ('10.0' !== '10.00') destabilizing equality checks and cache keys.

Ramp-up. Engineer-level ramp is trivial: one $casts entry and a test. Organizational ramp is the real cost — deciding to own a fork, establishing the three-place scale convention (migration, cast parameter, validation rule), enforcing string-only assignment at the request boundary, and adding the regression suite that would fail if typing or rounding shifts.

TPM recommendation. Treat this as a reference implementation, not a dependency. The 0.1.2 decimal fix is a legitimate maintenance signal, but it is also evidence that the cast path was still maturing in 2018 and then stopped. Adopt the pattern on Laravel's native CastsAttributes; pair it with a dedicated money/bignum library if currency semantics are on the roadmap. If a stakeholder insists on the package itself, scope it as a bounded, time-boxed pilot in one domain, budget for the fork, and set an explicit review gate at the next Laravel upgrade — not at 1.0, which will never arrive.