Laravel Custom Casts Laravel Package

Product Decisions This Supports

• Domain modeling fidelity (typed attributes vs. primitives): Decide whether money, email addresses, phone numbers, dates, statuses, and IDs live on models as rich value objects or as raw string/int. This package makes the typed option cheap — one cast class per concept, registered in $casts, converting DB values ↔ domain objects on hydrate/save.
• Build vs. buy vs. native: A three-way call every team with domain-heavy models faces — (1) hand-write CastsAttributes classes, (2) adopt a base-class package like this, (3) keep primitives and format at the edges. Package wins only when you want ready-made boilerplate and are on a Laravel version without native custom casts.
• Centralizing business rules: Formatting/validation/normalization (currency display, phone E.164 normalization, email domain extraction) becomes a one-file change instead of a grep across controllers, Blade, and jobs. This directly supports roadmap items like multi-currency pricing, internationalization, or stricter KYC/contact validation.
• Representative use cases: multi-currency price columns, contact/KYC data, billing identifiers, address/geo values, status enums (pre-PHP 8.1), encrypted-at-rest fields via a wrapping cast.
• Roadmap / standards signal: If the platform is Laravel 7+, this should appear on the "do not adopt — use native" list. If the platform is pinned to Laravel 5.x/6.x, it's a low-cost quality lever with a documented owner.

When to Consider This Package

Consider adopting when:

• You're on Laravel 6 or earlier, where the native CastsAttributes interface doesn't exist.
• You already have (or plan) a handful of domain value objects and want uniform get/set conventions with less boilerplate.
• You're a small team that values low ceremony and are comfortable running a ~200-star, MIT-licensed dependency.
• You want an exit-friendly choice: the package is thin and permissively licensed, so vendoring or replacing it is a matter of days, not quarters.

Look elsewhere / skip when:

• You're on Laravel 7+ — native custom casts do this without a dependency; on Laravel 9+ native enum casts cover the most common case outright.
• You need active maintenance, security response, or PHP 8.1+ support — last release was 2020-12-24.
• You need cast behavior on query-builder writes (update(), bulk where()); model-cast packages don't intercept those.
• Your dependency policy forbids unmaintained packages, or you require strict static-analysis cleanliness.
• You're standardizing on a DDD framework with its own hydrators/mapping layer.

How to Pitch It (Stakeholders)

Executives: It's a small, free, MIT-licensed utility that lets us treat things like money, email, and phone numbers as first-class types in code rather than loose strings — fewer formatting/validation bugs and cheaper changes when rules shift (adding a currency, changing phone format). Cost is near zero. The caveat: it's a 2020 package with ~200 stars and no recent releases. So my recommendation is conditional — use it only if we're on an older Laravel version; on current versions the same capability ships with the framework. Exit cost is low: the code is thin and permissively licensed, so we can vendor or replace it quickly.

Engineering: It provides a base class for custom attribute casts — define one class per domain type, register it in $casts, and get consistent hydration/serialization. It cuts boilerplate versus hand-rolled casts, keeps transformation logic in exactly one place, and is straightforward to unit test. Trade-offs: implicit behavior at the model boundary, no coverage for query-builder/bulk writes, and the package is unmaintained. Plan: use native CastsAttributes on Laravel 7+, and treat this as a legacy-compatible stopgap otherwise. Recommendation: adopt only as a documented internal pattern with a named owner — or re-implement the equivalent handful of classes in-house to remove the dependency entirely.