Search Bundle Laravel Package

Product Decisions This Supports

• Advanced search UX vs. simple filters: This package is a reference design for "structured search" — letting users compose conditions (status:active AND created:>=2024-01-01) against a whitelisted field set, then translating that into a database query. It informs whether your product needs a query DSL or whether faceted filters and a keyword box are sufficient.
• Build vs. buy for search plumbing: The bundle draws a clean boundary between field definitions (what is searchable, types, aliases), input parsing/validation (turning user text into conditions), and query generation (Doctrine ORM/DBAL). That separation is the reusable insight; it tells you roughly what you'd be signing up to build in-house (2–6 engineer-weeks for a competent team, more for saved-search serialization and edge-case validation).
• Roadmap input for saved searches, alerts, and power-user segments: A condition-based model is the prerequisite for persisted searches, "notify me when new results match," and API-level filtering for integrations. If those are on your 2–3 quarter roadmap, you need this data model regardless of which library you pick.
• Prioritization signal against adoption: At 10 stars, 0 dependents, and a last release of October 2017, this is effectively an archived artifact. Use it as a spec, not a dependency — which is itself a decision worth recording so the question doesn't get re-litigated.

When to Consider This Package

Consider it only as a design reference or a deliberate fork, when:

• You're on a legacy Symfony 2/3 / PHP 5.6–7.x stack that already matches the bundle's era, and you have a maintenance budget to own a vendored copy.
• You need a concrete example of separating field-set definition, input validation, and Doctrine query building — reading the source is cheaper than designing from scratch.
• Your team has already accepted long-term ownership of the code (fork, security patching, PHP/Symfony upgrades).

Look elsewhere when:

• You're on Symfony 5/6/7 or PHP 8+. Dependency constraints will block adoption, and no maintainer is coming to fix that.
• You need active security response, LTS guarantees, or vendor support. Zero dependents means zero informal community triage.
• Your search needs are full-text relevance, faceting, or typo tolerance — that's Elasticsearch/Meilisearch/Postgres FTS territory, not condition-building.
• You'd spend more time resurrecting the package than writing the ~500 lines of field-set + query-builder code it would replace.

Recommended path: mine the field-set/condition model for design, then implement against symfony/form + Doctrine query builders, or evaluate a maintained alternative (API Platform filters, Spatie Query Builder, Eloquent/Doctrine filter libraries).

How to Pitch It (Stakeholders)

For executives: We evaluated a package that solves user-defined advanced search. It's a well-structured design but abandoned since 2017 with no user base — adopting it would create a security and upgrade liability we'd own indefinitely. Recommendation: do not adopt; treat it as a free design reference. If advanced search, saved searches, or alerting are on the roadmap, budget the work as an internal build (~a few engineer-weeks) rather than a dependency.

For engineering: The bundle's value is architectural: a whitelisted field-set definition, a parser/validator that converts user input into typed conditions, and a translator to Doctrine queries. That split is worth copying. The code itself is PHP 5.6/7.x and Symfony 2/3 era — it will not run on a current stack without a fork. If we build, we own: field type registry, input grammar, query translation, saved-search serialization, and authorization on which fields are searchable. Estimate before committing, and confirm no maintained alternative covers our needs first.

Risk statement: Low opportunity (10.93) against a 0.11 score and 10 stars — this is a pattern to learn from, not a bet to place.