- Can I use monterhealth/api-filter-bundle in a Laravel application?
- No, not as a normal dependency. It is a Symfony bundle built around a Bundle subclass, a DependencyInjection extension, and Symfony container service definitions, none of which Laravel's service providers or HTTP kernel can consume. Installing it via Composer into Laravel gives you inert source files rather than a working integration. For a Laravel app, a native package such as spatie/laravel-query-builder is the lower-risk route.
- How do I install monterhealth/api-filter-bundle?
- Install it with Composer and register the bundle in a Symfony application's bundle configuration, then wire any required services through the bundle's DI extension. There is no Laravel service provider and no bootstrapping path outside Symfony. Before installing, confirm the PHP and Symfony version constraints in its composer.json against your runtime. Pin to a specific commit rather than a floating constraint on a single-maintainer package.
- Does this package support Laravel 10, 11, or 12?
- There are no Laravel version claims or Laravel-specific code in this package; it targets Symfony's HTTP and container layers. Laravel support is not merely untested, it is unclaimed territory. Treat any assumption of Laravel 10, 11, or 12 compatibility as false until you have verified it in a spike. PHP constraints also need explicit checking against your supported runtimes.
- How does the filtering and ordering actually work?
- The bundle parses query-string filter and order parameters into a structured criteria representation, inspired by API Platform's filter system but scoped for use inside a controller. The key unknown is how tightly that criteria is bound to Doctrine's QueryBuilder and DQL. If the grammar and parser sit behind a driver-agnostic interface, an Eloquent adapter is a bounded piece of work; if filters compile straight into DQL, the extractable value drops sharply. Read the source before planning any reuse.
- Is there a field allowlist to prevent SQL injection or full-table scans?
- This is the highest-severity functional question and must be verified before any adoption. Mapping unvalidated user input to column names or operators is a classic vector for query errors, full-table scans, and in the worst case SQL injection. Check whether a filterable and sortable field allowlist exists, and whether it is mandatory by default or opt-in. If it is opt-in, assume every endpoint is exposed until you prove otherwise.
- Which Symfony and PHP versions does this bundle support?
- The repository metadata does not state supported Symfony or PHP versions, so you need to read the composer.json constraints directly. Do not infer support from the bundle structure or from the description. Also verify any framework-bundle major version constraints, since Symfony's Bundle and DI APIs have changed across majors. Confirm this in the same pass as your other source review.
- Can I extract the filter grammar and use it with Eloquent?
- It is feasible but conditional. Fork or vendor a pinned copy, isolate the filter grammar and criteria objects, strip the Symfony DI wiring and Doctrine compilation, then implement an Eloquent criteria-to-builder adapter and cover it with conformance tests derived from the original behavior. Only pursue this if the operator syntax — nested filters, comparators, composite ordering — is genuinely differentiated from what Laravel already offers. Otherwise you are paying migration cost for parity.
- What are the alternatives for API filtering in Laravel?
- spatie/laravel-query-builder is the obvious Laravel-native equivalent and carries near-zero ownership cost. Using monterhealth/api-filter-bundle purely as a feature benchmark is a reasonable way to check whether your current package is missing filter semantics such as nested filters or composite ordering. Compare the operator grammars side by side before deciding to fork anything. Adoption risk is much lower when you stay inside the Laravel ecosystem.
- Is this package actively maintained and production-ready?
- Provenance is the dominant risk here, not code quality. Nine stars and zero dependents means no community validation, no third-party integration tests, and no evidence of production use, with a likely bus factor of one. Test coverage is unverified, and the listed release date of 2026-05-15 is a provenance anomaly worth confirming against the actual release history. Do not treat it as a safe dependency without a source review.
- How should I evaluate this bundle before committing to it?
- Run a short spike of roughly three to five days: read the source, answer whether the parser is Doctrine-bound, confirm the field allowlist behavior, check what the test suite covers and whether it runs in CI, and verify PHP and Symfony constraints. Produce a written go or no-go decision rather than letting it drift into the codebase. Ordering and filter operator extensibility should be part of that same assessment, since fixed operators limit long-term value.