Weave Code
Eloquent Mutators Laravel Package
awobaz/eloquent-mutators
Add get and set mutators to Eloquent attributes without boilerplate accessor methods. Define reusable mutator classes and attach them to model attributes at runtime, keeping models clean and mutator logic reusable across your Laravel projects.
awobaz/eloquent-mutators provides a cleaner way to define and organize Eloquent attribute mutators in Laravel models. It helps centralize formatting, normalization, and derived-value logic so models stay readable while attributes are transformed consistently.
- Trait-based integration with Eloquent models
- Concise, reusable mutator definitions
- Keeps transformation logic out of bloated model methods
- Works alongside Laravel’s existing attribute handling
- Simple setup for common formatting and normalization needs
Frequently asked questions about Eloquent Mutators
- What is awobaz/eloquent-mutators used for?
- It is a small Laravel package that lets you define reusable getter and setter transformations for Eloquent attributes and register them through a trait on your models, instead of writing the same getFooAttribute and setFooAttribute methods in every model. The goal is less boilerplate and cleaner model classes when several models share the same formatting or normalization logic. It is a leaf-level utility consisting of one trait plus an attribute-to-method mapping, with no service provider, config file or migrations.
- How do I install awobaz/eloquent-mutators?
- Install it with Composer using composer require awobaz/eloquent-mutators, then add the package trait to any Eloquent model that needs the reusable mutators and declare the mapping between attributes and your getter or setter methods. There is no service provider to register, no config to publish and no migration to run. Pin the exact version in composer.json so a future constraint bump cannot change behavior unexpectedly.
- Which Laravel and PHP versions does awobaz/eloquent-mutators support?
- The package describes itself as targeting Laravel 5, which reached end of life in 2020, so confirm the exact supported matrix with the maintainer before relying on it. Laravel 9 reworked mutator resolution and introduced native Attribute objects, and anything that hooks Eloquent internals is version-fragile. Verify against PHP 8.x explicitly, because Laravel 5-era packages often declare constraints that mask runtime deprecations.
- Is awobaz/eloquent-mutators still maintained?
- It is a single-maintainer, single-package project with roughly 45 GitHub stars and no dependents, which means very little ecosystem validation. A release in October 2025 is a positive maintenance signal, but it may only be a constraint bump rather than active feature work. Treat it as a bus-factor risk, pin the version and add it to your dependency-review list.
- Should I use awobaz/eloquent-mutators on Laravel 9, 10, 11 or 12?
- Generally no. Laravel 9 and later ship native Attribute casting classes that already give you reusable, testable, injectable accessors and mutators, so adding a third-party package is a net negative on modern versions. The package makes sense mainly for a Laravel 5.5 to 8.x application that is not planning a framework upgrade within the planning horizon.
- Does awobaz/eloquent-mutators conflict with $casts?
- The package plugs into Eloquent's attribute pipeline, so it interacts with $casts, $appends, $hidden, dirty tracking, getOriginal() and JSON serialization. Precedence when both the package mapping and $casts target the same attribute is not clearly documented, so test it before relying on it. Avoid declaring the same attribute in both places until you have confirmed the behavior in your own test suite.
- How do I test that the mutators behave like native accessors?
- Write conformance tests that port a few existing accessors to the package and diff the output against native getFooAttribute and setFooAttribute behavior. Cover serialization through toArray and toJson, dirty state, getOriginal(), mass assignment and null handling, since subtle divergence from native semantics is the most likely defect class. Run these tests inside your existing Testbench and PHPUnit matrix.
- Is it safe to use awobaz/eloquent-mutators with user input and mass assignment?
- Attribute transformation can imply implicit side effects, so review how the trait dispatches to the declared methods before trusting it with user-influenced data. If the mapping permits dynamic dispatch of declared methods, make sure the attribute-to-method map is a fixed allowlist and never built from request input. Keep validation and normalization of untrusted data in form requests or casts rather than in mutators.
- What are the alternatives to awobaz/eloquent-mutators?
- On Laravel 9 and later, use native Attribute casts, custom cast classes or value objects, which deliver the same reusable-accessor value without an extra dependency. On older versions you can keep plain accessors in a shared trait or a base model. If you adopt this package anyway, wrap it in your own trait or base model so call sites depend on your abstraction rather than the Awobaz\Mutator namespace.
- How do I remove awobaz/eloquent-mutators later?
- Treat it as a bridge, not a destination. Introduce an internal trait or base model that wraps the package so the mapping lives behind your own seam, then swap that seam for native Attribute casts on Laravel 9+ or explicit getX and setX methods. Budget the removal as part of the framework-upgrade epic rather than as a separate initiative.
Weaver
How can I help you explore Laravel packages today?