Eloquent Search Map Laravel Package

Product Decisions This Supports

• Build vs. buy on search/filtering plumbing. This package is a thin pattern for mapping request parameters to Eloquent query constraints. It informs the decision to build a small internal trait or adopt an actively maintained query-builder library rather than vendor this one.
• Filtering and faceted-search UX. It clarifies the underlying mechanism needed for admin tables, list endpoints, and marketplace-style filtering—parameter-to-constraint mapping—which is a prerequisite for saved filters, shareable query URLs, and faceted browse.
• API query-parameter contract. Supports roadmap work on public API filtering (e.g., ?status=active&created_after=...) where a consistent, declarative map from query string to query constraints reduces per-endpoint boilerplate.
• Internal tooling velocity. Relevant to internal admin/dashboard roadmaps where engineers repeatedly hand-write when($request->has(...)) chains; a shared mapping layer is a small but real velocity and consistency win.
• Vendor-risk register. Serves as a data point in dependency governance: archived, zero dependents, single star, last release 2017 — a candidate for the "reference only, do not depend" list rather than the approved-dependency list.
• Roadmap input for a search platform. If filtering requirements are growing (multi-tenant filters, permissions-aware constraints), this flags the need to standardize on a maintained solution (e.g., Spatie Query Builder, Eloquent Filter, or Scout for full-text) before ad-hoc filtering spreads across services.

When to Consider This Package

Consider it only as a design reference or short-lived spike:

• You are on a legacy Laravel 5.x application and need a quick, throwaway way to map search parameters to constraints.
• You want a compact, readable example of declarative parameter-to-constraint mapping to inform an internal implementation.
• You are prototyping and accept that the code will be rewritten before production.

Look elsewhere — which is the default recommendation — when any of the following hold:

• You are on a supported Laravel version (8+). The 2017 release predates modern framework conventions and is unlikely to be compatible without patching.
• You need security patching, PHP version support, or any maintenance commitment. The repository is archived, so there is none.
• You need community validation or a support path: 1 star, 0 dependents, and no recent releases mean effectively zero signal and no ecosystem to lean on.
• Your filtering needs include authorization-aware constraints, relationship filtering, or nested boolean logic — a maintained library or a purpose-built internal trait will serve better.
• You are making a long-lived architectural choice. Archived dependencies are a liability, not an asset, regardless of how small the code surface is.

Recommended alternatives to evaluate in its place: Spatie Laravel Query Builder (declarative filter/sort/include mapping, actively maintained), Eloquent Filter (filter classes per model), or a ~50-line internal trait if requirements are simple.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated aviator/eloquent-search-map, a small MIT-licensed Laravel package that turns search parameters into database query filters. It solves a real, recurring problem — consistent filtering across admin panels and APIs — but the package is archived, last released in 2017, has one star and zero dependent projects, and receives no maintenance or security updates. Adopting it would create dependency risk for negligible savings. Recommendation: do not adopt as a dependency; treat it as a reference pattern and either build a small internal equivalent (roughly one to two engineer-days) or adopt an actively maintained alternative. This keeps our filtering roadmap moving without adding unmaintained code to our stack.

For engineering: The concept is sound and small — a declarative map from request parameters to Eloquent constraints, eliminating repetitive when($request->has(...)) chains. But the 2017 code predates current Laravel conventions, will need patching for supported PHP/Laravel versions, and carries no upstream fixes. Proposal: build an internal trait covering our actual filter needs (typical scope: typed constraints, allow-listed parameters, relationship filters), or adopt Spatie Query Builder for broader features. Either path gives us the same ergonomics with tests, ownership, and upgrade support. Keep this repo bookmarked as a design reference only.