Search Laravel Package

Product Decisions This Supports

• Build vs. buy for the "index screen" layer. Nearly every admin, support, and internal-ops surface needs the same four things: filtered queries, sorting, pagination, and — the part teams forget — results scoped to what the viewer is allowed to see. This package treats that as one primitive. The decision it informs is whether that primitive lives in a shared internal package or gets re-implemented per controller.
• Where authorization belongs in search. By baking authorization into query construction rather than post-filtering results, it forces a useful product question: is "users never see rows they can't access" a platform guarantee or a per-feature courtesy? For multi-tenant or compliance-adjacent products, this pushes you toward the former, which is the right call and much cheaper to decide early.
• Replaceable model configuration → white-labeling and entity flexibility. A swappable model binding means the same search surface can point at different entities per tenant, plan, or product line. That supports roadmap decisions about whether search is a per-entity feature or a reusable platform capability, and whether renames/merges of core entities require UI rewrites.
• Roadmap sequencing for search quality. This is SQL-level filtering, not relevance search. Adopting it is an explicit decision to defer investing in ranking, typo tolerance, and faceted aggregation (Scout + Meilisearch/Typesense, or Elasticsearch) until a concrete user need proves it. That's usually the correct sequencing, but it should be a recorded decision, not a default.
• Reference implementation, not a dependency. At 0 stars and 0 dependents, its highest-value use to a PM is as a design prior: a one-afternoon read that tells you how someone else structured authorized search in Laravel before you write your own. MIT licensing makes that legitimate.
• Does not support: consumer-facing search relevance work, search analytics, or any roadmap item where ranking quality is the differentiator. Don't let a utility like this anchor those conversations.

When to Consider This Package

Consider it when:

• You're on Laravel, shipping index/list screens faster than you can write consistent filter + pagination + authorization code, and you've already had (or narrowly avoided) a data-leak bug from a missing scope.
• You want something small enough to read end-to-end and vendor into your own codebase — the MIT license and minimal surface area make forking practical.
• You're already standardized on the liberusoftware module ecosystem and value internal consistency over external adoption evidence.
• You need a stopgap while a proper search infrastructure decision is pending, and the stopgap is cheap to throw away.

Look elsewhere when:

• Adoption evidence matters. Zero stars, zero dependents, single vendor. There is no second production user to learn from, no issue history to mine for edge cases, and no incidental security scrutiny.
• You need to trust the maintenance signal. The listed last release (2026-10-27) is dated in the future relative to normal release cadence — verify in the repo whether that's a scheduled/unpublished tag or a metadata error before citing it as "actively maintained."
• You need real search. Relevance ranking, fuzzy matching, facets, synonyms, cross-entity search, or anything beyond indexed WHERE clauses → Laravel Scout with Meilisearch/Typesense/Algolia, or Elasticsearch/OpenSearch.
• Your authorization model is non-trivial. Nested relations, soft deletes, per-tenant scoping, field-level visibility, and policy inheritance are exactly where third-party query builders leak. Centralize this in first-party code you own and test.
• You need support, an SLA, or a long-lived dependency. Bus factor is one, and a dependency you can't get fixes for is a liability on a multi-year product.
• Supply-chain review is mandatory. No dependents means no downstream pressure has ever been applied to this code.

If you do proceed: read the full source, pin the version, fork rather than consume upstream, and add your own tests specifically around authorization edge cases (nested relations, soft deletes, tenant boundaries, empty/absent policy). Treat it as internal code with an external origin.

How to Pitch It (Stakeholders)

To executives: "There's a small MIT-licensed Laravel module that packages the search/filter/pagination logic we rewrite on every admin screen, with permission checks built into the query itself. It has effectively no adoption — zero stars, zero downstream users, one maintainer — so I don't recommend taking it as a runtime dependency. I recommend one engineer-day to read it and borrow the design for our own internal package. That keeps our dependency count flat and closes a class of permission-leak bugs. The alternative — standing up Scout plus a search service — is two to three weeks plus infrastructure, and we don't have the user need to justify it yet."

To engineering: "It solves a real annoyance: authorized filtering, filters, pagination, and a swappable model binding in one place instead of scattered per-controller code. The surface looks small enough to audit in an afternoon, and MIT lets us vendor the relevant classes into app/Support/Search and own the tests. Risks are the usual for a zero-adoption package: single maintainer, no community, an unverified release date, no security history. Proposal: vendor and own it now; reconsider a composer dependency only if we get a second consumer or see genuine upstream activity. Treat the composite score as 'immature but conceptually on-target' — worth reading, not worth trusting."