- Does jlm/serializer-expression-bundle work in a Laravel application?
- No. It is a Symfony bundle built around a DI Extension and compiler pass that registers a custom exclusion strategy with JMS Serializer, and Laravel has no mechanism to consume Symfony bundle wiring. Package discovery, config publishing and the service container are different abstractions, so even with the package installed the bundle layer is inert. The reusable part is the pattern — declarative, context-aware field exclusion evaluated at serialization time — plus a small amount of glue code, not the package itself.
- Is this package still maintained and safe to use in production?
- Treat it as unmaintained: the repository is archived with roughly four stars, no dependents, and a single author. Adopting it means forking and owning it indefinitely, including any security or compatibility fixes. Combined with a pinned older Symfony generation and an older JMS metadata API, the practical answer for a production Laravel API is no.
- Can I use jms/serializer standalone in Laravel and still get @excludeIf?
- You can use jms/serializer in Laravel standalone — it is a legitimate choice for DTO-heavy codebases — and both jms/serializer and symfony/expression-language resolve fine on Laravel 10 and 11 with PHP 8.1 or newer. But the bundle wrapper does nothing outside Symfony, so the @excludeIf annotation it registers will not be wired up. You would need to re-implement the exclusion strategy as a Laravel service provider, or rely on JMS 3.x native attribute support instead.
- What is the Laravel-native alternative for conditional field exposure?
- Eloquent API Resources already provide $this->when($condition, $value), whenHas(), whenNotNull(), whenLoaded(), whenCounted() and mergeWhen(). Those cover the overwhelming majority of real @excludeIf use cases, such as hiding internal_notes unless the user is staff or omitting email unless the requester is the owner or an admin. They are declarative, testable and require no extra dependency.
- What are the performance risks of evaluating expressions during serialization?
- Expression evaluation runs per property, per object, per request, so on large collections it is measurable CPU unless compiled expressions are cached. Expressions that touch relational state can also trigger lazy loading, producing N+1 queries or LazyLoadingViolation errors under strict mode that are invisible in code review. Cache compiled expressions and keep predicates away from relationship traversal.
- How do I port the expression-exclusion pattern to a Laravel service provider?
- Re-implement the primitive rather than the bundle: register a custom exclusion strategy or a resource-level guard from a Laravel service provider and evaluate predicates against a small, well-defined context object. Budget roughly 100 to 300 lines of glue, compile and cache expressions, and write tests before wiring it into controllers. In most applications the simpler answer is to skip the port and use API Resource conditionals.
- What alternatives exist for conditional field exclusion in PHP serializers?
- If you stay in Laravel, API Resource conditionals are the default. If you standardise on JMS Serializer 3.x, use its native @Exclude(if=...) attribute support. If you are on Symfony Serializer, use serialization groups plus #[Ignore]. All three avoid pulling a Symfony bundle into a Laravel application.
- Does it support PHP 8 attributes or only legacy docblock annotations?
- The bundle targets an older JMS metadata API from the docblock-annotation era, before JMS 3.x moved to PHP attributes. Legacy annotation code will not run unchanged on modern JMS, and a silently ignored annotation means exclusions stop applying while tests can still pass. Any port should target attributes explicitly and assert on the serialized output.
- How do I test that expression-based exclusions never leak fields?
- Assert on the actual serialized payload, not on metadata, for both the included and excluded branches of every predicate. Add tests for the failure path: if an expression throws or references an unknown property, the field must be omitted rather than exposed, because fail-open semantics in an API payload are a data-exposure defect. Also test with loaded and unloaded relations to catch lazy-loading surprises.
- Is symfony/expression-language safe to evaluate in the request path?
- It is an eval-like surface, so treat it as a deliberate design decision rather than a convenience: cache compiled expressions, restrict the variable surface passed in, and never let user input reach the expression string. If your conditional logic is a small set of known rules, a closed enum of predicate types is safer, cacheable and reviewable. Reserve full expressions for cases where the flexibility genuinely earns its cost.