- What is speakeasy/serializer and why would I use it instead of jms/serializer?
- speakeasy/serializer is described as a temporary fork of jms/serializer, kept around while changes are merged upstream. It provides the same metadata-driven serialization model for converting objects and DTOs to arrays or JSON. You should only choose it if a Speakeasy-generated SDK or toolchain pins the fork, or if your codebase already standardizes on JMS metadata. Otherwise, prefer upstream jms/serializer or Laravel's native resources.
- How do I install speakeasy/serializer in a Laravel application?
- Run composer require speakeasy/serializer and pin it to an exact version or commit rather than a floating constraint. There is no idiomatic Laravel service provider shipped for it, so register a serializer singleton in your own service provider if needed. After installation, inspect composer.lock to confirm it did not unexpectedly replace or conflict with jms/serializer. Treat the install as a codebase-wide dependency decision, not a local package choice.
- Can I use speakeasy/serializer to serialize Eloquent models directly?
- You can serialize objects technically, but the recommended approach is to keep Eloquent out of the serializer and map rows to explicit DTOs. Eloquent's toArray(), JsonResource, and API resources already cover most Laravel payload shaping. Let this package own only the wire format and contract metadata if you adopt it at all. This keeps database model changes from silently changing API output.
- Which Laravel and PHP versions does speakeasy/serializer support?
- The package is a fork of a framework-agnostic PHP serializer, not a Laravel package with Laravel-specific version constraints. Check its composer.json for PHP, doctrine/annotations, and other dependency constraints before installing. Laravel compatibility is indirect and depends on whether your application's PHP version satisfies those constraints. Do not assume support for a given Laravel release without verifying Composer resolution in your project.
- How do I configure metadata drivers and register the serializer in Laravel?
- Instantiate SerializerBuilder in a service provider and configure an explicit metadata driver such as attributes or XML, rather than relying on defaults. Register the resulting serializer as a singleton so the metadata and handler configuration are reused consistently. Keep naming strategies, exclusion policies, and date formats explicit because they form part of your API contract. If you use annotations, confirm the required doctrine/annotations version is compatible with your Laravel stack.
- Will speakeasy/serializer conflict with jms/serializer in Composer?
- Potentially yes. A fork of this kind often declares replace or provide for jms/serializer, or carries a distinctive version constraint, and either can collide with transitive requirements on upstream JMS elsewhere in your dependency graph. Inspect the fork's composer.json and run composer why jms/serializer before adopting it. Pin the fork to an exact version or commit and be prepared to resolve future conflicts under time pressure. If another package requires upstream jms/serializer, test resolution in a branch first.
- Is speakeasy/serializer safe to use in production?
- Treat it as higher risk because its stated purpose is temporary and its stewardship is the concern, not the upstream code lineage. Serialization is a contract surface, so behavioral drift in type coercion, null handling, date formats, or naming could break API consumers without compile-time errors. Security fixes in upstream jms/serializer do not automatically flow to the fork. Use it in production only with an exact pin, explicit ownership, and a documented migration path back to upstream.
- How should I test serialization output when using speakeasy/serializer?
- Write contract tests that assert the exact array or JSON shape for representative DTOs, including nulls, dates, nested objects, and naming strategy cases. Snapshot or golden-file tests are useful because they catch silent drift after dependency updates. Test the serializer through the same service-provider configuration used in production, not with ad hoc builder settings. Add a Composer resolution check so a transitive dependency change cannot swap the serializer implementation unnoticed.
- Do I need speakeasy/serializer if I use Speakeasy-generated PHP SDKs?
- The assessment suggests that is the main legitimate reason to adopt it: consuming Speakeasy-generated PHP SDKs or tooling that pins this fork. In that case the fork is effectively vendor infrastructure rather than a design choice you made. Confirm with Speakeasy how long the fork will be published for the lifetime of those SDKs and what migration notice they provide. If no generated artifact requires it, use upstream jms/serializer or Laravel-native serialization instead.
- What should I use instead of speakeasy/serializer, and how do I migrate later?
- For Laravel API responses, start with Eloquent resources, JsonResource, and toArray() before adding a serializer dependency. For richer DTO contracts, upstream jms/serializer or symfony/serializer are more established choices. If you adopt the fork now, isolate it behind your own serialization service or interface so you can swap implementations later. Plan migration for when the upstream changes merge and verify that output stays byte-for-byte compatible.