Elinoi Search Bundle Laravel Package

Product Decisions This Supports

• Correcting the input before it becomes a plan: this is a Symfony bundle, not a Laravel package. It registers through Symfony's kernel/DI container and has no service provider, facade, or config-publishing path. If the roadmap assumes "drop into Laravel," the estimate is wrong before work starts. The Laravel-equivalent decision is algolia/scout-extended, not this repo.
• Search as a differentiator vs. search as plumbing. This is the framing decision every search ticket hangs off. Differentiator (commerce catalog, marketplace inventory, docs, support KB) justifies funding relevance tuning, faceted navigation, instant-search UX, and click analytics as ongoing roadmap items. Plumbing (admin lookups, <50k rows) means Postgres full-text + trigram is the cheaper, defensible answer and this package is unnecessary weight.
• Build vs. buy at the infrastructure layer. Algolia is a managed, usage-priced service: you buy latency SLOs, typo tolerance, and relevance tooling; you still own index schema design, record shaping, incremental sync, and ranking config. The alternatives are Meilisearch/Typesense (self-hostable, cheaper at scale, more ops) or Elasticsearch (max flexibility, max ownership). This decision belongs in the roadmap, not a ticket comment.
• Cost envelope as a capacity-planning input. Algolia pricing scales with records × replicas × operations. Model the bill at 2–3× projected corpus growth and place it beside infra spend in the quarterly plan. Search cost surprises are almost always a record-count surprise.
• Vendor exit assumption. Index schemas, ranking formulas, and analytics are Algolia-shaped. Adopting without a documented re-index path to a self-hostable engine is an unhedged bet. Budget an abstraction boundary at the service/repository layer so the swap is a quarter, not a rewrite.
• Data residency and compliance scoping. Index hosting region constrains which integration you can wrap and is a product commitment for EU/regulated customers — decide it before engineering picks a library.
• Sizing signal for this specific artifact: 0 stars, 0 dependents, single release 2023-07-26, and it appears to be a rename/fork of algolia/search-bundle (badges, CI, Packagist links all point upstream). Treat it as a reference implementation of the integration pattern — config-driven index definitions, indexing console commands, Doctrine entity hooks — not as a dependency to standardize on. The pattern is the reusable asset; the fork is not.

When to Consider This Package

Consider the pattern (not necessarily this fork) when:

• The stack is Symfony and you want declarative YAML index definitions, populate/clear console commands, and Doctrine entity subscribers instead of hand-wiring the Algolia PHP client.
• Search UX is a surface the product team will iterate on (synonyms, ranking, facets) and you want that iteration to live in configuration rather than application code.
• You already have an Algolia contract, or have a specific reason to prefer managed search: no ops headcount, tight latency SLO, built-in analytics.
• You want a fast spike scaffold to prove out index modeling and relevance before committing to a vendor.

Look elsewhere — or reject outright — when:

• The stack is Laravel. Use algolia/scout-extended; adopting a Symfony bundle here is a category error that costs a sprint. Any use would need manual container bridging or bypassing the bundle and calling the PHP client directly (at which point the bundle adds nothing).
• You need a maintained dependency. Zero dependents plus a stale 2023 release means no signal on security patches, PHP 8.3+/Symfony 7 compatibility, or tracking upstream Algolia API changes. Prefer the upstream algolia/search-bundle and verify its current support matrix first.
• You need a supported SLA. A single-maintainer fork cannot back a customer-facing commitment. That risk must sit with a vendor or an internal team, never a transitive composer line.
• Cost or self-hosting is a hard constraint. Meilisearch/Typesense drivers deliver most of the product surface for a fraction of the bill, at the cost of owning uptime.
• Search is table-stakes and the corpus is small. A zero-vendor Postgres answer is defensible and removes a renewal negotiation from your calendar.

How to Pitch It (Stakeholders)

To executives: Search quality is a revenue lever — users who find things convert; users who don't, churn silently and don't file tickets. Buying managed search trades engineering months for a usage-based bill; the strategic question isn't this repository, it's whether we fund search as a product surface with named relevance ownership or treat it as plumbing to be minimized. Recommendation: choose the vendor path deliberately, model the bill at 2–3× projected record growth, write down the exit assumption, and never let a 0-dependent fork become load-bearing infrastructure.

To engineering: The wrapper is trivial — the vendor SDK does the work. Real effort lives in index schema design, record shaping, incremental indexing (queues, idempotency, delete propagation), and relevance iteration. Proposed two-week spike: index 10k and 100k records, measure p95 query latency, time a full and an atomic re-index, and prototype two ranking variants against a labeled query set. Two constraints up front: confirm the framework target (Symfony bundle vs. Laravel Scout — this package is the former) and pin a maintained distribution, not the fork.

Decision record: Approved pattern, unapproved artifact. Adopt a maintained Symfony integration (upstream bundle) or Laravel Scout's official driver depending on stack; gate merge on a documented fallback path to a self-hostable engine and a cost model reviewed at each renewal. Revisit if search-attributed conversion underperforms or the vendor bill exceeds 3× model.