- Is gns/filter-bundle a Laravel package?
- No. It is a Symfony bundle for REST API filtering, registering through Symfony's Kernel, DependencyInjection extension, and Configuration tree. Laravel does not run the Symfony bundle lifecycle, so it is not a drop-in Laravel package. Treat it as Symfony and Doctrine-oriented source material, not a Laravel dependency.
- Can I install gns/filter-bundle in Laravel with Composer?
- Composer may resolve it if PHP constraints allow, but installation does not make it work in Laravel. There is no Laravel service provider, and the Symfony DI and config plumbing will not be consumed by Laravel's container. A direct composer require is therefore low value unless you plan to fork or inspect the code.
- Does gns/filter-bundle work with Eloquent?
- Probably not out of the box. The filtering model likely targets Doctrine ORM query builders rather than Eloquent, and the evaluation flags Doctrine versus Eloquent impedance as a high risk. You would need to verify whether the filter core accepts an abstract query interface or is ORM-bound. If it is ORM-bound, reimplementing for Eloquent is usually cleaner.
- Which Laravel versions does gns/filter-bundle support?
- None are officially supported. It is a Symfony bundle, and its last release was 2020-02-08, so it predates current Laravel and Symfony generations. Its composer.json constraints for php, symfony/*, and doctrine/orm should be checked before any experiment. Do not assume Laravel 10, 11, or 12 compatibility.
- How do I integrate gns/filter-bundle with a Laravel REST API?
- There is no supported direct integration. The realistic path is to fork the repository, remove Symfony DI and configuration plumbing, retain only framework-agnostic filter logic, and write a Laravel adapter that maps request parameters to Eloquent. Budget for the adapter to be larger than the retained core. A native reimplementation is the default recommendation.
- Is gns/filter-bundle maintained?
- The evaluation says no release since 2020-02-08, with 1 star and 0 dependents. There is no evident maintainer response path or community validation. That makes abandoned-upstream risk high. Treat any use as owning a fork rather than consuming a maintained package.
- What are alternatives to gns/filter-bundle for Laravel query filtering?
- For Laravel, spatie/laravel-query-builder is the maintained, Laravel-native comparison with real dependents. Hand-written Eloquent scopes are cheaper if you have fewer than about 10 filterable endpoints. You can also define your own filter contract with allowlisted fields, operators, type coercion, and per-field authorization. Use gns/filter-bundle mainly for DSL naming ideas, not as a runtime dependency.
- How do I test gns/filter-bundle in a Laravel app?
- You cannot meaningfully test it as a Laravel package without an adapter, because Laravel will not boot the Symfony bundle. Start by inspecting composer.json constraints and whether the filter core is coupled to Doctrine. Then write adapter-level tests that exercise request-to-Eloquent filtering, authorization, and edge cases. Also test the fork on your target PHP version before trusting it.
- Is gns/filter-bundle safe for production in Laravel?
- The evaluation rates technical risk high: abandoned upstream, PHP and Symfony version drift, no CVE triage, transitive dependency rot, and zero community validation. For a Laravel production app, using it directly is not advisable. If you fork it, you inherit security triage and maintenance. Prefer a Laravel-native implementation unless a spike proves the fork is small and safe.
- Can I fork gns/filter-bundle and adapt it for Laravel?
- Yes, but only as an engineering project. Check the repository license first to confirm a closed or internal fork is permitted. Then verify whether the filter core is ORM-coupled; that answer decides fork versus reimplement. If you fork, strip Symfony Kernel, DI extension, and Configuration tree code, then build a thin Laravel adapter around the pure filter logic.