Serializer Expression Laravel Package

Product Decisions This Supports

• Where field-level visibility logic lives. This package's core idea — excluding serialized fields at runtime via a declarative expression (@Exclude(if="...")) rather than hardcoding per-endpoint DTOs — is a real architectural fork in the road. It informs whether your team standardizes on declarative, annotation-driven payload shaping or explicit resource classes (Laravel API Resources, Fractal transformers).
• Data minimization and compliance work. Conditional field exclusion is the mechanism behind PII redaction, internal-only fields, and "minimum necessary" API responses for GDPR/CCPA/HIPAA-adjacent products. Any roadmap item touching data subject rights, enterprise security review, or SOC 2 evidence benefits from a concrete answer to "how do we guarantee field X never leaves the boundary for role Y?"
• Entitlement- and plan-based payload shaping. The expression model maps cleanly onto "Pro users see analytics_summary, Free users don't" and "support agents see last_login_ip, customers don't" — a repeated product ask that otherwise turns into a proliferation of near-duplicate serializers.
• API contract evolution and deprecation. Expressions let you keep a field in the schema but suppress it by flag or date, enabling staged rollouts of breaking payload changes and feature-flagged response expansion.
• Build vs. buy vs. reuse. This is the package's most decisive contribution: it is a reference implementation, not an adoption candidate. Archived, 2 stars, 0 dependents, diligence score 0.02 — the decision it supports is "do we spend 2–5 engineer-days building a small internal equivalent?", and the answer is almost certainly yes if the capability is on the roadmap. It also supplies a design sketch (expression context shape, field metadata hook) you can crib without inheriting the maintenance burden.

When to Consider This Package

Consider studying it (not installing it) when:

• You are evaluating a declarative field-exclusion design and want a worked example of wiring Symfony ExpressionLanguage into a serializer's exclusion strategy.
• You are on an older stack already using jlm/serializer or JMS Serializer and need to understand the pattern before reimplementing it.
• You need to write an internal ADR and want a concrete prior-art citation.

Look elsewhere — in practice, always — when:

• You would take a runtime dependency. Archived means no security patches, no PHP-version compatibility work, no CVE response. For a component that sits on the serialization path and often is the PII control, that is a disqualifying risk, not a tradeoff.
• You are on modern Laravel/PHP. Laravel 10/11/12 and PHP 8.2+ are unsupported by an archived package; the integration cost will exceed the write-it-yourself cost almost immediately.
• You need a support contract, SLAs, or a name on a vendor questionnaire. 0 dependents means no production corpus, no battle-testing, and no peer answers when it breaks.
• Your expression needs anything beyond trivial predicates. Runtime expressions are executable logic in configuration. Without an owner, active tests, and a review process, they become an unauditable side channel around your authorization layer.

Preferred alternatives: Laravel's native JsonResource conditionals (when(), whenHas(), whenNotNull()) for most cases; $hidden/$visible plus selective makeHidden() for coarse control; spatie/laravel-fractal or league/fractal if you want transformer-level includes; and a ~150-line internal VisibleWhen policy class wrapping symfony/expression-language if you genuinely need declarative predicates. If you are already on jms/serializer, use its built-in expression-based exclusion rather than adding a second layer.

How to Pitch It (Stakeholders)

To executives — one paragraph: We evaluated a package that solves a real and recurring product problem: hiding fields in API responses at runtime based on who is asking, instead of maintaining separate response classes per role or plan. The capability is worth having — it directly supports data-minimization commitments, enterprise security reviews, and plan-based feature gating in payloads. The package is not viable: it is archived, has two stars and zero known dependents, and would put unmaintained code on the path that protects customer data. Recommendation: fund a small internal capability (roughly 2–5 engineer-days) modeled on the same idea, with tests and an owner. Expected payoff is reduced duplication in our API layer and a defensible answer in security questionnaires. Risk of the alternative — adopting it — is an unpatched component in a PII-adjacent code path with no one to call.

To engineering — the ask: Don't add jlm/serializer-expression to composer.json. Two options: (1) if our needs are simple, use Laravel JsonResource::when() conditionals and a policy call — ship this week, no new dependency; (2) if we truly need declarative predicates in field metadata, build a thin symfony/expression-language wrapper with a whitelisted variable context (user, tenant, plan, flags), fail-closed on expression errors, and 100% test coverage on the exclusion path. Treat the archived package as design input only. Two non-negotiables for option 2: expressions must never be able to reach the container or the database (no arbitrary method calls on user objects), and an exclusion failure must return fewer fields, never more.

Framing to avoid: don't present this as "we found a package and rejected it." Present it as "we validated the pattern, rejected the artifact, and are proposing a smaller, owned implementation" — that is a stronger story and it keeps the roadmap decision (declarative payload shaping, yes/no) visible rather than buried in a dependency review.