Search Laravel Package

Product Decisions This Supports

• Search backend choice (build vs. buy vs. plug-in): Lunar Search now ships a Meilisearch engine alongside its existing driver(s), so the decision shifts from "do we build search?" to "which engine do we point it at?" That is a configuration-level decision rather than an engineering project.
• Roadmap sequencing for storefront search: Adding a second engine in an alpha signals the package is intentionally driver-agnostic. It de-risks committing to the package now, because swapping engines later is a config change rather than a rewrite.
• Vendor lock-in posture: Teams that standardised on Meilisearch elsewhere in the stack (or that already run it for docs/site search) can consolidate infrastructure instead of operating a second search system purely for the storefront.
• Relevance and merchandising experiments: A dedicated engine unlocks typo tolerance, faceting, and ranking-rule tuning that are impractical on naive database LIKE queries — directly supporting conversion and search-abandonment OKRs.
• Feature scoping conversations: Because search is a separate package from Lunar core, it can be adopted, deferred, or replaced independently of the commerce core. Useful when negotiating scope with stakeholders who want "search that just works" without expanding the core platform commitment.

When to Consider This Package

Consider it when:

• You are already on Lunar for commerce and need product search that goes beyond basic attribute filtering.
• You want an engine-agnostic abstraction so the search vendor is a deployment detail, not an architectural commitment.
• Your catalogue or traffic profile is approaching the point where database-backed search degrades — large SKU counts, high query volume, or expectations of typo tolerance and instant faceted filtering.
• Your team already operates Meilisearch (or is willing to), making the new engine a low-marginal-cost win.
• You can absorb alpha-stage risk: this is 0.1.0-alpha.16, pre-1.0, with a thin release history and a changelog measured in single pull requests.

Look elsewhere when:

• You need production-grade stability guarantees, SLAs, or a support contract — pre-1.0 alpha is not that, regardless of engine coverage.
• You are not on Lunar; the value is tightly coupled to the Lunar data model.
• You need advanced search capabilities now — semantic/vector search, sophisticated merchandising rules, A/B-testable ranking, or a managed relevance console. A dedicated search platform is the honest answer.
• You require multiple engines supported at maturity — right now the abstraction exists but the engine matrix is small and unevenly battle-tested.
• Your search needs are genuinely simple and a database query is sufficient; adding an engine adds an operational dependency for no user-visible gain.

How to Pitch It (Stakeholders)

For executives: Lunar's search package just added Meilisearch support. The strategic point is not "one more integration" — it's that search has become a swappable component. We can pick a search engine on cost and performance grounds today and change our minds later without re-platforming the storefront. That materially lowers the risk of investing in the search roadmap now.

For engineering: The package now exposes a driver abstraction with Meilisearch as an implementation. Adoption is configuration plus an operational dependency (running Meilisearch), not a bespoke integration. Caveats to be explicit about: this is 0.1.0-alpha.16, the release is a single PR, and there is no stated deprecation or breaking-change surface yet — but at pre-1.0, breaking changes should be assumed rather than ruled out. Recommend a time-boxed spike against a representative catalogue before any production commitment, and pin the version.

Bottom line: A small release with a disproportionate strategic signal — it converts "which search engine?" from an architecture decision into a deployment decision. Worth a spike; not yet worth a production dependency without validation.