- What does jlm/serializer-expression actually do?
- It provides a runtime, expression-based exclusion strategy for JMS Serializer. Instead of relying only on static exclusion metadata, you can write expressions that decide at serialization time whether a property or object should be excluded. It is an add-on to JMS Serializer, not a standalone serialization layer.
- Is jlm/serializer-expression a Laravel package?
- No. It is an extension for JMS Serializer, a metadata-driven serialization library that originated in the Symfony ecosystem. It ships no Laravel service provider, configuration, or Eloquent integration, and Laravel applications normally use API Resources, Spatie Laravel Data, or Fractal instead. Adding it means introducing a second serialization pipeline alongside Laravel's.
- Does JMS Serializer already support expression-based field exclusion?
- Yes. JMS Serializer core includes ExpressionLanguageExclusionStrategy, exposed through Exclude(if: ...) annotations and the attribute form on version 3.x, with symfony/expression-language as the dependency. That built-in feature covers the same runtime conditional exclusion use case this package was written for. In most projects the package is therefore redundant before you install it.
- Should I install this package in a new Laravel project?
- No. It is archived, has no maintainer, and its Composer constraints likely target older PHP and jms/serializer majors that conflict with PHP 8.2+ and modern Laravel. You would be forking a few classes and owning them permanently just to duplicate a feature already present in JMS core. For a greenfield Laravel app, use API Resources with when(), whenHas(), whenLoaded(), and mergeWhen() instead.
- Which PHP and jms/serializer versions does it support?
- It was built for older jms/serializer releases and almost certainly pins an old major, with PHP constraints from the 5.x and 7.x era. It is not validated against PHP 8.2 or 8.3, jms/serializer 3.x, or symfony/expression-language 6 and 7. Treat compatibility as broken until you prove otherwise with a fork and a full test run.
- Is the package still maintained?
- No. The repository is archived, has two stars, zero dependents, and no issue triage or release cadence. There is nobody to fix bugs, respond to security reports, or update constraints for new PHP and framework versions. Depending on it means taking on maintenance yourself.
- What are the Laravel-native alternatives for conditionally hiding fields?
- Laravel API Resources provide conditional field inclusion through when(), whenHas(), whenLoaded(), and mergeWhen(), which keeps payload shaping explicit and testable. For DTOs, Spatie Laravel Data offers similar conditional and transformation support. For sparse fieldsets, resolve a fields allowlist in a resource collection rather than evaluating expressions during serialization.
- Can I use it for sparse fieldsets or role-based field visibility?
- Technically yes, but it is not the idiomatic answer. Sparse fieldsets are better handled by an allowlist of requested fields resolved in your resource layer, and role-based visibility is clearer as explicit conditions in API Resources or policies. Using serializer expressions for these cases hides API contract decisions in metadata that is harder to test and review.
- Are runtime serializer expressions a security risk?
- Runtime expression evaluation is effectively code execution by another name. Even with ExpressionLanguage's sandbox, enabled functions and object method access widen the attack surface. Expressions must always be developer-authored constants in code, never supplied by users, tenants, or configuration controlled outside the repository.
- How do I migrate away from jlm/serializer-expression?
- If the package is already wired in, replace its exclusions with JMS core Exclude(if: ...) or the attribute form on 3.x, then delete the package and its registration. If the application is Laravel-first, take the larger step and move payload shaping into API Resources so you can drop JMS entirely. Add contract tests that assert excluded fields are absent, because a wrong expression leaks data silently.