- Is jdeniau/api-platform-filter-validator a Laravel package?
- No. It targets API Platform, the Symfony-first framework for building hypermedia and Hydra APIs, and hooks into API Platform's filter pipeline. On a standard Laravel stack there is no filter pipeline to hook into, so the integration surface is effectively zero. If you are on Laravel, solve query-string filter validation with a FormRequest or a native query-parameter validator instead.
- How do I install jdeniau/api-platform-filter-validator?
- Install it with Composer using composer require jdeniau/api-platform-filter-validator, then register the validator against your API Platform filter collection. Because the package is a temporary shim with zero dependents, pin an exact version and record an exit plan before it reaches production. Check the package's Composer constraints against the API Platform version you have pinned.
- Which API Platform and Symfony versions does this package support?
- The repository's Composer constraints are the only reliable answer, so read composer.json and the README before pinning anything. The upstream PR it references dates to the API Platform 2.x era, so do not assume compatibility with newer API Platform releases. Confirm that current API Platform versions do not already validate filter values natively before adopting the shim.
- What does jdeniau/api-platform-filter-validator actually do?
- It adds Symfony Validator constraint support to API Platform filters so query parameter values are validated before they reach the data provider. Invalid filter values then return clean validation errors instead of failing deep inside queries as 500s. The package is explicitly a holding pattern until the related api-platform/core pull request is merged.
- Is jdeniau/api-platform-filter-validator safe to use in production?
- Treat it as a vendor-and-pin shim, not a long-term dependency. It has zero stars, zero dependents and a single maintainer, and its stated reason to exist disappears once the upstream PR resolves. Any adoption plan must include a removal plan from day one, and you should be comfortable owning a fork if the maintainer stops responding.
- How can I validate API Platform filter query parameters without this package?
- Modern API Platform has grown query-parameter validation and filter-level validation support, so check your pinned version first. If the gap still exists, a small custom validator or a filter decorator is usually cheaper to own than a zero-star shim. For Laravel applications, use a FormRequest or a dedicated query-parameter validator instead.
- What is API Platform PR #1723 and does it make this package obsolete?
- It is the api-platform/core pull request the package is waiting on to be merged. PR numbers in the 1,700s date to the API Platform 2.x era, so it is likely merged, closed as stale, or superseded by a different mechanism. Check its current state and your target API Platform version before spending more evaluation time.
- Can I use this package with API Platform's Laravel bridge?
- No, it is not a supported target. The Laravel bridge's extension points and versioning assumptions differ enough that adoption would be exploratory engineering rather than a Composer install. Confirm whether your stack is Laravel or Symfony plus API Platform before evaluating further.
- How do I test that invalid API Platform filter values return clean errors?
- Write functional tests that send malformed query parameters and assert a 400-level validation response rather than a 500. Also unit test the constraint configuration against representative filter values. Because the package touches non-public API Platform internals, run these tests on every minor upstream upgrade to catch silent filter resolution changes.
- What are the alternatives to jdeniau/api-platform-filter-validator?
- Use native API Platform validation if your version supports it, or write a roughly 100-line custom query-parameter validator that you fully own. Forking the package is also an option if you need its exact behavior, but budget for maintenance. On Laravel, the correct alternative is a FormRequest or Laravel-native query-parameter validation.