- What is theofidry/eloquent-serializer used for?
- It is a small Symfony Serializer bridge for the Eloquent ORM. It converts Eloquent models and their loaded relationships into clean arrays or JSON, with configurable depth and reusable serialization rules. It is aimed at services that use Eloquent as their ORM but want symfony/serializer normalization instead of Laravel's built-in output. It is an adapter, not a full serialization framework.
- Does eloquent-serializer work in a standard Laravel application?
- It can be installed in Laravel, but it is architecturally redundant there. Laravel already ships toArray and toJson, API Resources, and model casts, which cover most of the same ground with first-party support. Treat this package as a bridge for Symfony-plus-Eloquent or standalone PHP stacks, not as a general-purpose Laravel serialization layer.
- Is eloquent-serializer still maintained?
- No. The repository is archived, the last release was December 2017, and there are no dependents or active maintainers. The code surface is small, but every upstream Symfony or Eloquent change is an unpatched potential fatal error. Plan for adoption by fork or reimplementation rather than as a long-term dependency.
- Which Laravel, PHP, and Symfony Serializer versions does eloquent-serializer support?
- Its releases land in the PHP 7.x, Symfony Serializer 2.x/3.x, and Eloquent 5.x/6.x era. Modern Symfony Serializer 5.4, 6.x, and 7.x changed normalizer interfaces and context handling, and Eloquent 10/11/12 differ in casting, attribute access, and relation APIs. Expect breakage at the normalizer interface level first, so build a compatibility matrix and validate with a spike before committing.
- How do I install and configure eloquent-serializer?
- Installation is a Composer require followed by container wiring. You register the package's normalizer or denormalizer and a serializer service definition in your Symfony or standalone service container. The mechanical setup is simple; the real effort is pinning PHP, Symfony Serializer, and Eloquent constraints that actually run together. Since the package is archived, prefer vendoring the code under your own namespace with an explicit owner.
- How do I serialize model relationships without N+1 queries or circular references?
- The normalizer recurses into loaded relations up to a configurable depth, so always eager load the relations you intend to output. Lazy-loaded relations normalized recursively will trigger N+1 queries, and bidirectional relations can produce circular references. Constrain depth and relation sets explicitly, and verify query counts in tests before using it as an API boundary.
- Can eloquent-serializer denormalize JSON back into Eloquent models?
- Yes, it bridges both normalization and denormalization through symfony/serializer contracts. That means incoming payloads can be hydrated into models, which is a mass-assignment and deserialization surface you must constrain explicitly. If your boundary is read-only output, skip denormalization entirely and reduce risk.
- How do I control which model attributes get serialized?
- The normalizer walks the model's attributes, casts, and hidden or visible fields, and it accepts Serializer context and groups for reusable rules. Use hidden and visible on the model plus Serializer groups for per-endpoint shaping. Be aware that date and cast semantics may not match Laravel's native output exactly, so lock the contract with assertions to avoid API drift.
- What are the alternatives to eloquent-serializer for Laravel APIs?
- In Laravel, use API Resources or Resource collections, or lean on toArray and toJson with casts for simpler cases. In a Symfony-plus-Eloquent service, a custom ObjectNormalizer or AbstractNormalizer subclass is usually the better trade: a few hundred lines, but fully owned and aligned with current interfaces. Both alternatives beat a stale dependency for a code surface this small.
- Should I use eloquent-serializer in a Doctrine-based Symfony app?
- No. It bridges Eloquent models specifically and adds nothing for Doctrine entities, which Symfony Serializer already handles. It fits only a Symfony service that genuinely uses illuminate/database as its ORM, or a standalone PHP microservice standardized on Serializer contracts. If you are not already on Eloquent, this is a solution in search of a problem.