Eloquent Search Map Laravel Package

Technical Evaluation

Architecture fit. aviator/eloquent-search-map addresses a narrow but common concern: turning request query parameters into Eloquent where/scope constraints via a declarative map rather than hand-written conditionals in controllers. Architecturally that places it in the presentation-to-persistence seam of a Laravel app — a filter/search layer sitting between a controller (or FormRequest) and a query builder. It does not introduce new infrastructure, services, or storage, so it is trivially removable if it disappoints. That is the package's main structural virtue: low blast radius.

The cost is that search/filtering is one of the most domain-specific parts of any application. A generic constraint generator almost always needs per-model customization (allowed fields, operator selection, relation traversal, authorization per filter), which pushes logic back into the app anyway. Expect to wrap it rather than use it directly.

Integration feasibility. Straightforward in principle — a Composer require plus a service provider, assuming Laravel package auto-discovery or manual registration. The real friction is version drift: the last release is November 2017, which corresponds to the Laravel 5.5 era. The repository is archived, has one star and zero dependents, so there is no evidence of anyone running it against Laravel 9/10/11, PHP 8.1+, or the modern query builder. Feasibility for a greenfield modern Laravel app is therefore low without a compatibility audit; feasibility as a reference implementation to copy into app/ is high.

Technical risk. Concentrated in four areas:

1. Abandonment. Archived, no maintainer, no issue triage. Any bug is yours.
2. Framework coupling. Likely depends on older Illuminate\Database and Illuminate\Support APIs. Laravel has changed service provider registration, string helpers, and query builder internals since 5.5; deprecation notices at minimum, hard failures plausibly.
3. Security surface. A package whose entire purpose is mapping user-supplied input to SQL constraints is exactly where you must verify: is there an allowlist of filterable columns, or can a crafted parameter reach an unwhitelisted column? Are operators (LIKE, >=, IN) selected by the caller or declared server-side? Can it traverse relations unintentionally? With one star and no dependents, there is no community review, no CVE history, and no one else's production traffic to have found the sharp edges. Do not assume sanitization.
4. Test coverage unknown. No signal on CI, coverage, or edge-case handling (empty arrays, nested params, null semantics).

Key questions for the maintainer/sponsor.

• What is the precise DSL — column-to-operator mapping, or free-form parameter names?
• Is there a strict allowlist mechanism, and is it enforced by default or opt-in?
• Does it support relationship filters, or only base-table columns?
• How are LIKE wildcards, IN arrays, and range (BETWEEN) operators expressed?
• Where does authorization live — does the package delegate to policies/gates, or is that entirely the caller's job?
• What Laravel and PHP versions were targeted at the 2017 release, and is there a fork or successor the author recommends?
• Is the intent to extract the pattern rather than the dependency?

Integration Approach

Stack fit. Poor as a runtime dependency for any current Laravel codebase (8+). Acceptable — arguably useful — as a pattern source: a small, self-contained search-map implementation is 150–300 lines including tests, and owning it removes every version, security, and abandonment risk above. The package's best contribution is the idea, not the artifact.

Migration path. Recommended: vendor the concept, not the package. Concretely — read the source, extract the mapping contract (parameter name → column, operator, transformation), reimplement it as an application-level SearchMap value object or a Filterable trait on your base model, and back it with your own tests. This is a half-day to two-day effort for a mid-level engineer and yields something you can extend for relations, full-text search, and per-tenant field restrictions.

If a spike is genuinely warranted, do it on a throwaway branch: composer require aviator/eloquent-search-map, run one model and one endpoint, and time-box to a day. Expect to patch the service provider and possibly the query-building calls. If it survives, it still needs a fork-and-maintain decision — an archived dependency in production is a standing liability regardless of how well the spike went.

Compatibility. Verify against your actual matrix before anything else: PHP version (8.1/8.2/8.3), Laravel major, and whether package discovery is used. Old packages frequently fail on typed properties, str_* helper migration, or Illuminate\Support\Arr signature changes. Also check whether it pins illuminate/* constraints in composer.json — an old pin will block upgrades and force a replace/fork.

Sequencing.

1. Confirm the need: audit existing controllers for repeated filter boilerplate. If it's fewer than ~5 endpoints, a generic library is overkill.
2. Read the package source (it is small) and document its DSL and any whitelisting behavior.
3. Decide build-vs-fork-vs-vendor; default to vendor.
4. Implement the search map with an explicit, default-deny allowlist of filterable columns and operators.
5. Add tests for injection-shaped inputs (unknown keys, array-where-array, operator smuggling) and for null/empty-parameter handling.
6. Roll out to one endpoint behind a feature flag, then standardize.

Operational Impact

Maintenance. This is the decisive factor. Zero dependents and an archived repo mean the effective maintainer is whoever installs it. Under a vendor-and-own approach, maintenance is a small, well-bounded internal module inside your normal test and upgrade cadence. Under a dependency approach, every Laravel major upgrade becomes a fork-and-patch exercise, and there is no upstream to send fixes to.

Support. None. No issue responses, no security advisories, no release process. For a component that touches SQL generation, the absence of a security contact is a meaningful governance gap — most orgs' dependency policies will flag it outright.

Scaling. The package itself is stateless and runs in-process, so it does not constrain throughput; any query it builds is as fast or slow as the index behind it. The scaling risk is organizational — filter logic spread across many controllers with inconsistent semantics is harder to govern than a centralized search layer, and that is precisely the problem worth solving. Also watch for unbounded filters (unindexed columns, leading-wildcard LIKE, deep relation traversal) producing full scans under load; enforce operator restrictions and index review in the search map rather than trusting callers.

Failure modes.

• Hard break on upgrade: pinned/obsolete illuminate constraints block a Laravel bump mid-quarter.
• Silent under-filtering: an unrecognized parameter is ignored, so a search returns broader results than the user expects — a correctness and data-exposure concern if filters double as access controls.
• Over-permissive filtering: an unexpected parameter reaches an unwhitelisted column, exposing data or enabling expensive scans.
• Operator confusion: LIKE applied to numeric/date columns, or array inputs serialized incorrectly, yielding wrong result sets that pass code review.
• Bus factor: no one in the org understands the DSL in six months because it was adopted as a black box.

Ramp-up. Low technically — the surface is small and the concept is familiar to any Laravel developer. The cost is investigative, not educational: someone must read the source to establish what it actually does with untrusted input, because there is no documentation trail, no community usage, and no changelog reliability. Budget a day for that audit, and treat "we couldn't determine the whitelisting behavior" as a no-go rather than a maybe.

Recommendation. Do not take a production dependency on this package. Its signal — one star, zero dependents, archived since 2017, last release in the Laravel 5.5 era — is unambiguous, and the value it offers is a small, easily reimplemented pattern. Adopt the idea, own the code, and keep the SQL-generation surface inside your own reviewed and tested boundary.