Detective Laravel Package

Product Decisions This Supports

Feature scoping for search and filtering UX. Filtering is the invisible backbone of admin panels, internal dashboards, reporting screens, and list APIs. This package exists to answer one narrow question — "how do we turn a query string into safe, composable Eloquent constraints?" — which makes it useful as a reference design when scoping that feature, even if you never install it.

Build vs. buy vs. borrow. A 13-star package with a last release in October 2016 tells you the "buy" option is effectively off the table for anything long-lived. The productive decision it supports is borrow the pattern, build the implementation: a filter-to-query-scope contract is typically 1–3 days of work for a mid-level Laravel engineer, and owning it removes the dependency risk entirely.

Roadmap and dependency-risk calls. If this appears in a legacy codebase audit, it's a flag: an unmaintained, Laravel 5.x-era dependency that likely blocks PHP 8 / modern Laravel upgrades via Composer constraints. That's a concrete line item in a modernization plan, not a theoretical concern.

Use-case triage. Filtering requirements differ enormously by surface, and the package's scope only fits some of them:

The key PM framing: filtering is a security-adjacent surface, not a convenience feature. Anything that lets a client influence a query needs an explicit allow-list of filterable fields and scopes. A small package can hide that risk; a deliberate internal contract surfaces it.

When to Consider This Package

Consider it only when all of these hold:

• The application is pinned to Laravel 5.x (roughly 5.1–5.4 era) and upgrade work is genuinely out of scope.
• The consumer is internal, low-traffic, and low-sensitivity — back-office search, an ops console, a demo environment.
• The feature has a short expected lifespan, or the code is disposable by design.
• Someone on the team can read the source in an afternoon and fork it if needed — the entire package is small enough that "vendoring" is a realistic fallback.
• You need it as a specification: reading how it maps request parameters to scopes is cheaper than designing that contract from scratch.

Look elsewhere when any of these hold:

• Modern Laravel or PHP 8+. Composer constraints and framework internals from 2016 will almost certainly block installation; assume it does not work until proven otherwise in a spike.
• You need support, security patches, or a CVE response path. There is none. Thirteen stars and a nine-year-old release means no maintainer community to lean on.
• Filtering is customer-facing or compliance-relevant. Query-string-driven filtering without a hardened allow-list is a data-exposure vector; do this in-house with explicit, tested rules.
• Requirements exceed simple scope mapping — full-text search, faceting, relevance ranking, saved filters, or cross-entity search. That's a search-infrastructure decision (Scout plus Meilisearch/Elasticsearch/Algolia), not an Eloquent trait decision.
• Maintained alternatives fit. Mature, actively maintained Laravel query-filtering packages exist and should be the default comparison point; evaluate at least one before writing your own.

Practical next step: timebox a half-day spike. Attempt install on your actual Laravel/PHP version. If it fails — the likely outcome — the decision is made, and you reuse the package's parameter-to-scope idea in a first-party trait with validation and tests.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated a small open-source library for building search and filter screens. It solves a real, recurring need, but it was last released in 2016 and has almost no community behind it, so it carries maintenance and upgrade risk disproportionate to the ~2–3 days of engineering it would save. Recommendation: do not take it as a dependency. Instead, adopt its approach in a small in-house utility we control — same speed to market, no long-term liability, and it keeps our upgrade path to current Laravel and PHP clear.

To engineering (the substance):

• What it is: a thin Eloquent extension that maps request parameters onto query scopes for advanced filtering. Small surface area; readable in an afternoon.
• Why we're not installing it: released October 2016, 13 stars, no release cadence. Expect incompatibility with PHP 8 and Laravel 9+ through Composer constraints and framework API drift. No security response channel.
• What we'll do instead: implement a first-party filter trait — an explicit allow-list mapping request keys to scopes, with per-filter validation, an authorization hook so filtering can never widen a user's data visibility, and a test suite covering the "unknown filter" and "unauthorized filter" paths.
• Effort: ~2–3 engineer-days including tests, versus 1 day of integration plus unbounded upgrade friction later. The build option wins on total cost of ownership at almost any horizon past one quarter.
• Where it does earn a look: if any service is still on Laravel 5.x and needs internal-only filtering fast, a half-day spike is justified. Treat any adoption as a fork-and-own decision, not a dependency decision.
• Success criteria if we build: filters are declarative and discoverable, injected parameters cannot reach unlisted columns, and adding a new filter is a one-line change plus a test.