- How do I install daveismyname/laravel-filters in a Laravel app?
- Install it with Composer using composer require daveismyname/laravel-filters. There is no build step, published configuration file, or database migration introduced by the package, so installation is a single dependency change. After that you define your filters and apply them from request query strings.
- Which Laravel and PHP versions does laravel-filters support?
- The v2.0.3 release adds a forward-compatibility claim for Laravel 13, contributed by the maintainer. However, the dev dependency constraint in that release only bumps laravel/framework to 10.48.29, so check composer.json for the real constraint instead of relying on the release title. Also confirm the minimum PHP version and whether a CI matrix covering Laravel 11, 12, and 13 with PHP 8.2 to 8.4 is published.
- How do I define a reusable filter and apply it to an Eloquent query?
- Filters are defined once and then applied to an Eloquent query using values from the request query string. The package is a thin layer over Laravel's query builder, so your filters ultimately add where clauses and similar constraints to the model query. Keep controllers thin by resolving filters in a dedicated place and passing the filtered query to your view or resource.
- How are query string parameters mapped to database columns?
- The mapping between query string keys and database columns is a convention you design, not something the package dictates. Decide which model attributes are filterable, what parameter names map to them, and how multiple values or ranges are handled before you expose the endpoint. Document that mapping so front-end and API consumers use the same names.
- Is laravel-filters safe from SQL injection?
- The package does not enforce an allowlist of filterable columns, so SQL injection and data-exposure protection is the integrating team's responsibility. Never derive column names or operators directly from user input; map request parameters to an explicit allowlist of columns and operators. With that constraint in place, filtering is read-path only, so a defect degrades results rather than data integrity.
- Do I need to publish a config file or run migrations after installing laravel-filters?
- No. The package is Composer-only and does not publish configuration that needs reconciliation, nor does it ship database migrations. You configure it through your own filter definitions and application conventions.
- How does laravel-filters compare to spatie/laravel-query-builder or plain Eloquent scopes?
- Plain Eloquent scopes are enough for a handful of fixed filters, while larger packages offer richer, more opinionated query grammars. laravel-filters sits in between: it is a single-concern utility that turns request-driven filters into reusable query constraints. Choose it when you want small blast radius and easy removal; choose a heavier package when you need a fully specified filter syntax.
- Can I use laravel-filters to build API filters or JSON:API filter queries?
- It is a reasonable fit for admin panels, reporting views, and search endpoints where query parameter names are yours to define. It is a poor fit for APIs that require a strictly specified, versioned query grammar such as JSON:API filter semantics unless you wrap it in a translation layer. For those APIs, treat the package as an internal implementation detail behind your own request parser.
- How should I test filters in my Laravel application?
- Because the package sits on Eloquent and the request lifecycle, feature tests that call your route with query strings and assert the returned records cover most behavior. Add tests for each allowlisted column, invalid parameter names, and empty or malformed values. Keep filters behind an interface so you can unit test the mapping independently of HTTP.
- Is daveismyname/laravel-filters actively maintained and safe for production?
- The release history is mostly Dependabot updates plus a maintainer-authored Laravel 13 compatibility change, which signals continued engagement but also a single-maintainer project. Runtime risk is low because filtering is read-path only and the package is easy to remove. Before production, audit a --no-dev install so dev dependencies like league/commonmark and psy/psysh do not ship, and confirm your Laravel version against composer.json.